Link clicks in the UI inconsistent with the the same clicks on webpages
Categories
(SeaMonkey :: UI Design, enhancement)
Tracking
(seamonkey2.53? affected, seamonkey2.57esr? affected)
People
(Reporter: jobbautista9, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.8
Steps to reproduce:
Do the following things on a webpage's anchor:
ctrl-leftclick
ctrl-shift-leftclick
middleclick
ctrl-middleclick
shift-middleclick
shift-leftclick
Then do the same things on a UI link (e.g. a bookmark on the bookmark's toolbar), which is handled by the whereToOpenLink function of utilityOverlay.js.
Actual results:
Here's a csv table of the inconsistencies:
click,webpage,UI
ctrl-leftclick,new background tab,new active tab
ctrl-shift-leftclick,new active tab,new background tab
middleclick,new background tab,new active tab
ctrl-middleclick,new background tab,new active tab
shift-middleclick,new active tab,new background tab
shift-leftclick,save,nothing
New background tab means a new tab is opened, but you still stay on the old tab. New active tab means you follow the new tab. Save brings up the file save dialog, and nothing of course does nothing.
Expected results:
Every click listed should have the same behavior, whether on a webpage or on the UI. Since users click more often on the webpage, I think whereToOpenLink should reflect the webpage anchor's behavior too.
|
Reporter | |
Comment 1•3 years ago
|
||
Table in Markdown format:
| click | webpage | UI |
|---|---|---|
| ctrl-leftclick | new background tab | new active tab |
| ctrl-shift-leftclick | new active tab | new background tab |
| middleclick | new background tab | new active tab |
| ctrl-middleclick | new background tab | new active tab |
| shift-middleclick | new active tab | new background tab |
| shift-leftclick | save | nothing |
|
||
Comment 2•3 years ago
|
||
Not sure if this is easy to change. There are also numerous prefs floating around and controlling this. See it more as an enhancement.
|
|
Reporter | |
Comment 3•3 years ago
|
||
Yeah, that's what I realized too, after I dug deeper into this. I wonder why they thought that ignoreSave and ignoreBackground is a good idea to use on the application. It's useful I guess for extension devs, but not so much in the suite itself. It's not like the world is going to explode when users are able to save a bookmark or the brand homepage throbber link into an HTML file..
|
||
Comment 4•3 years ago
|
||
Well, "webpage" case follows "browser.tabs.loadInBackground" pref, whereas "UI" case follows "browser.tabs.loadBookmarksInBackground" pref. (The word "bookmarks" here now has a broader meaning, rather than bookmars itself :) ).
By default, "browser.tabs.loadInBackground" is true, "browser.tabs.loadBookmarksInBackground" is false. It explans the results above.
If you set both prefs to "true" (or both to false), the behaviour will be identical. Except the "shift-leftclick" case (which probably could be leaved as is).
Note, I've tested this with the patch from bug #1619108 comment #17 applied. Pls. perform your own tests to make sure whether this patch is actually needed for this issue. (If needed, the patch can be applied just against omni.ja).
|
|
Reporter | |
Comment 5•3 years ago
|
||
I can confirm that setting both of those prefs to the same value now makes both the UI and webpage clicks consistent with each other, and I don't have the patch from bug 1619108 applied. I wonder why they bothered to make two prefs controlling separate clicks though. I think we should just make both of those prefs set to true by default as a resolution for consistency. What do you two think?
|
|
Reporter | |
Updated•3 years ago
|
|
|
||
Comment 6•3 years ago
|
||
Well, the patch from bug #1619108 is for a case of opening two or more links simultaneously. The opening of the one link per time was OK there.
The whole story began two decades ago with bug #175629 . There they decided to make different preferences.
Some people have already complained about the inconsistence in behaviour a decade ago, you can see the pro and contra reasoning in bug #469456 .
|
|
||
Comment 7•3 years ago
|
||
browser.tabs.loadBookmarksInBackground is currently unused without any patches. It was added to the library for future use. It should not affect tabs loading in the browser. Given that the library is a separate window it might make sense to have separate prefs. I am currently having some grief with a similar patch for cZ here from IanN where tabs are loaded in the background when I click on a link in cZ. Generally I wonder if we should have a separate set of general tab prefs for our non browser and mail windows or at least the library and cZ together. But I am a but uneasy here because don't want another 100 undocumented prefs floating around so if we add something it needs to be exposed in the prefs window.
As for the patch in bug 1619108. I won't test code snipplets (very very few exceptions). If something needs to be changed please add a formatted patch and ask for feedback or review. We need these for both the unofficial builds and also for later checkins into gitlab and comm-central.
Description
•