Usability glitches in default browser selection

Bug #111032 reported by Hagy Hag
6
Affects Status Importance Assigned to Milestone
KDE-Admin
Fix Released
High
kdebase-workspace (Ubuntu)
Won't Fix
Wishlist
Rich Johnson

Bug Description

In the Kubuntu system settings module, component standard programs, selection Webbrowser.

I would expect a choice between installed Browsers which are Konqueror and Firefox as the KDE default browser.

In stead it says: standard component
above a text "description of component"

---> obviously two times a different meaning of component

Open address, which starts with http or https

---> You have to understand what "http" and "https" is. In fact "open address" is misleading as this is not the action executed by the dialogue but rather a setting

first selection "in a program that is based on the content of the address"
second selection : with the following webbrowser and file selection dialog

--> does not really make sense

the whole dialog is pretty confusing, screenshot attached.

Tags: upstream
Revision history for this message
In , Richard-bos (richard-bos) wrote :

Version: kde-3.4 (using KDE KDE 3.3.92)
Installed from: SuSE RPMs
OS: Linux

What is exactly meant with the text 'in an application based on the contents
of the url' on the tab: kcontrol -> kde-components -> component > chooser -> webbrowser

It is confusion because this tab specifies the default browser => that would
be konqueror, but not 'an application'. The later could be kedit, kxmleditor, kpdf, etc. That are no browsers.

Revision history for this message
Hagy Hag (elektroschock) wrote :

Screenshot in German attached, the remarks above are rough translations of the german screen

Rich Johnson (nixternal)
Changed in kde-systemsettings:
assignee: nobody → nixternal
importance: Undecided → Wishlist
status: New → Confirmed
Changed in kdeadmin:
status: Unknown → Confirmed
Revision history for this message
Christian González (droetker) wrote :

I support that.
It should be changed. AFAIK In KDE 4.1 it is the same - this is quite unreadable for the average user.

description: updated
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Yeah, this affects KDE 4.1.

Changed in kdebase-workspace:
status: Confirmed → Triaged
Changed in kdeadmin:
status: Confirmed → Invalid
Changed in kdeadmin:
status: Invalid → Unknown
Revision history for this message
In , FiNeX (finex) wrote :

*** Bug 115636 has been marked as a duplicate of this bug. ***

Revision history for this message
In , FiNeX (finex) wrote :

*** Bug 158992 has been marked as a duplicate of this bug. ***

Revision history for this message
In , FiNeX (finex) wrote :

I paste here the description of bug #158992:

In System Settings -> Default Applications -> Web Browser it has been brought
to my attention that the text under the "Default Component" section is
confusing.

Open http and https URLs (some users may not know what these are)

 * in an application based on the contents of the URL (some users may not
understand which application this is referring to)

 * in the following browser (this should be fine)

Further information on this can be located in a bugged filed in Launchpad at
https://launchpad.net/bugs/111032

Thanks!

Changed in kdeadmin:
status: Unknown → Confirmed
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Hi there,
We are in the process of closing wishlist items that have already been reported at KDE. Don't worry, your issue still is being tracked at KDE's bug tracker at: http://bugs.kde.org/show_bug.cgi?id=100016 . It's just that Kubuntu currently does not have the manpower necessary to take this feature on ourselves. We will receive this functionality once KDE implements it in one of their releases.

Thanks for understanding, and have a nice day.

Changed in kdebase-workspace (Ubuntu):
status: Triaged → Won't Fix
Changed in kdeadmin:
importance: Unknown → Medium
Revision history for this message
In , Nate-b (nate-b) wrote :

*** Bug 347870 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Nate-b (nate-b) wrote :

Lots of good info in Bug 347870.

It's not real clear to me what value this feature even provides in this day and age...

Revision history for this message
In , Nate-b (nate-b) wrote :

*** Bug 380133 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Kde-bugs-f (kde-bugs-f) wrote :

In KDE systemsettings > Personalization > Applications > Default applications > Web browser,
there are two settings:
A) "in an application based on the contents of the URL".
B) "in the following browser".

There are two problems with the interface:
1- if A) is selected, then the name of the default browser is not visible.

2- It is not possible to change the default browser and keep A) selected.
To do so, the workaround is to select B), type in the browser name, save, then select A) again, save again. When coming back later to the same screen, the first problem occurs again.

http://linux.overshoot.tv/wiki/default_browser_kde

Revision history for this message
In , Kde-bugs-f (kde-bugs-f) wrote :

Logically, the settings should be split into two different settings:

- One setting to select the default browser.
- One setting to select default action, with A) as above and B) reading: "in the default browser".

Where are the relevant settings saved?
I checked ~/.config/systemsettingsrc but it does not appear to be there.

Revision history for this message
In , mrvanes (mrvanes) wrote :

And please, let it be clear that the 'in an application based on the contents
of the url' option is broken. It destroys any link while inspecting the content as reported here: https://bugs.kde.org/show_bug.cgi?id=354822

Changed in kdeadmin:
importance: Medium → High
status: Confirmed → Unknown
Revision history for this message
In , Nate-b (nate-b) wrote :

Following supportive comments on the mailing list, I'm preparing a patch to remove the "in an application based on the contents of the url" feature, which is confusing, imposes a speed penalty, and apparently doesn't work for certain URLs. The patch is fairly simple but there's a conceptual issue: what's a good default setting now?

Right now the default setting is "let KIO figure it out", and presumably this should move to "default to browser X". But what is Browser X? Should we really be in the business of picking preference orders for 3rd-party software? What about if 1st-party software is also installed, like Falkon or Konqueror? Should we leave it up to distros to populate ~/.config/kdeglobals with a sensible default for BrowserApplication[$e]?

Any ideas or guidance would be appreciated.

Revision history for this message
In , Nate-b (nate-b) wrote :

Ok, what I think makes sense is to fall back on KIO when there are no web browsers installed (unlikely). When one is manually installed, it will usually set itself as the default--but in ~/.config/mimeapps.list, not ~/.config/kdeglobals. Which is fine, since changing the browser setting in componentchooser updates mimeapps.list too so that don't get out of sync.

It will be up to distros to pre-populate these files with their desired default browsers, but that's already the case, so no regressions should be introduced. I'll also change the componentchooser KCM so that the default browser shown in the combobox is identical to what's listed in ~/.config/mimeapps.list if there's nothing in kdeglobals.

Here are the patches:
- KIO: https://phabricator.kde.org/D17371
- Plasma: https://phabricator.kde.org/D17372

Revision history for this message
In , Nate-b (nate-b) wrote :

Git commit 7bd7f38400b953a988a2cc942a518339e0b094a8 by Nate Graham.
Committed on 23/12/2018 at 04:14.
Pushed by ngraham into branch 'master'.

[KRun] when asked to open link in external browser, fall back to mimeapps.list if nothing is set in kdeglobals

Summary:
Right now, when KRun is invoked to open an `http` or `https` link in a browser, it checks the `BrowserApplication` key in `~/.config/kdeglobals`. If nothing is set there (which is the default), then it introspects the link and figures out for itself what app to open, which is slow and can cause problems with certain links (see CCBUGs below).

This patch improves the browser discovery logic by additionally looking for a default browser in `~/.config/mimeapps.list`, which is the XDG file and it's where browsers set themselves as the default. So if there is a default browser set in there, KRun will consume that information immediately instead of doing the time-consuming and possibly error-inducing link introspection round-trip.
Related: bug 347870

Test Plan:
1. Open System Settings > Applications > Default Applications > Browser and click "In an application based on the contents of the url" (which is the default setting, but you might have changed it)
2. Set `BrowserApplication[$e]=` in `~/.config/kdeglobals`
3. Ensure that `~/.config/mimeapps/list` has a default browser set
4. Open any KDE app > Help menu > About KDE > Click on one of the links in the dialog

Without this patch, a KRun job is spawned that shows up in the notification widget and the link may take a second or two to open in your default browser.

With this patch, the link instantly opens in the browser.

Reviewers: #frameworks, broulik, cfeck, elvisangelaccio, dfaure

Reviewed By: dfaure

Subscribers: dfaure, rdieter, achauvel, kde-frameworks-devel

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D17371

M +13 -0 src/widgets/krun.cpp

https://commits.kde.org/kio/7bd7f38400b953a988a2cc942a518339e0b094a8

Revision history for this message
In , Nate-b (nate-b) wrote :

*** Bug 405359 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Nate-b (nate-b) wrote :

*** Bug 411941 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Nate-b (nate-b) wrote :

The confusing text and its confusing feature have been removed in Plasma 5.19!

Changed in kdeadmin:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.