Closed Bug 1619108 Opened 4 years ago Closed 9 months ago

Add an option to load new opened tab(s) in background from SeaMonkey/SM's Library.

Categories

(SeaMonkey :: Bookmarks & History, enhancement)

All
Unspecified
enhancement
Not set
normal

Tracking

(seamonkey2.53+ fixed)

RESOLVED FIXED
Future
Tracking Status
seamonkey2.53 + fixed

People

(Reporter: ant, Assigned: frg)

References

(Blocks 1 open bug)

Details

(Whiteboard: SM2.53.17)

Attachments

(3 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1

Steps to reproduce:

  1. Open up an old Library in SM v2.53.1 web browser.
  2. In either History or Bookmark section (both are reproducable in multiple computers and OSes), right click on one or multiple bookmark(s)/URLs(s) into new tab(s).

Actual results:

SeaMonkey web browser would open the new tab(s) from requested right clicks and go to one.

Expected results:

I don't want to go there right away. I just wanted SM to load them in the background while still on the old tab like in v2.49.5 and older versions.

Also, about:config's browser.tabs.loadBookmarksInBackground's value to true didn't work. It works in Firefox v73.0.1 though. So, maybe this is a bug.

NI to myself

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(frgrahl)
Hardware: Unspecified → All
Version: SeaMonkey 2.53 Branch → Trunk

Current 2.53.7 seems to properly respect the pref "browser.tabs.loadBookmarksInBackground". Both bookmarks and history entries load in background (when "Open in New Tab" by rightclick menu).

Or it is some another use case?

Just confirmed browser.tabs.loadBookmarksInBackground yes here works, possibly one of the last blockers keeping me on 2.49.5 for my primary profile. :)

It works when opening only one link from Library (history and bookmarks), but with two or more the issue is still there. I am able to reproduce them in v2.53.7 in both my over decade old, updated 64-bit W7 HPE SP1 and Debian Jessie v8 PCs. Did you try multiples links?

5 unique links from history, 2 from bookmarks, loaded in background. :)

Interesting. So, you don't lose current tab focus to one of the background loading tabs?

History window retains focus. :)

I attached a short MP4 video capture example with a brand new SeaMonkey v2.53.7's profile in opening two visited URLs in its Library. Note that I was in Bugzilla web page. I didn't want it to lose focus while opening these two visited URLs.

I tried to open that mp4 in 2.49.5, but all I get is dark grays surrounded by black. What is it supposed to demonstrate?

I attached a zip file of the video so you can download, extract, and play it locally on your computer (VLC and MPC-HC players worked).

I got to see it play, but it told me nothing, only mousetype moving too fast to follow. Is this supposed to be showing a problem, or is everything working as expected?

Look at the single tab when the video started. It was showing this Bugzilla bug report web page. Pay attention to that tab and see where its focus goes when I open two new tabs from Library's history. It is no longer on that Bugzilla bug report web page tab. I only wanted to load the new web page tabs in the background without changing the tab focus (Bugzilla bug report web page).

Confirm. "Open All in Tabs" does not respect loadBookmarksInBackground ...

(In reply to Ant from comment #1)

Also, about:config's browser.tabs.loadBookmarksInBackground's value to true didn't work. It works in Firefox v73.0.1 though.

Could you pls re-check whether it works in Firefox as expected?
My tests with FF-esr78.4.0 shows that Fx does not open several tabs in background...

(Just to make sure what to do -- either backport something from Fx, or implement something new in SM).

Flags: needinfo?(ant)

The tabs are open in background (as in 2.49.5) if you hit "Ctrl+Shift" when clicking (or entering) on "Open All in Tabs".

Is this a viable option for user habits? Or it is highly desirable that it be the same as in 2.49.5 - i.e. without extra key typing?

Well, this one restores the old 2.49.5 behaviour, in the case when "browser.tabs.loadBookmarksInBackground" is true.

Ctrl+Shift toggles the behavior (ie. to open in background when the pref is "false", and to opposite way when the pref is "true").

--- comm/suite/components/places/PlacesUIUtils.jsm.orig 2021-04-08 19:35:52.322459790 +0300
+++ comm/suite/components/places/PlacesUIUtils.jsm      2021-04-08 19:35:56.256427521 +0300
@@ -921,17 +921,18 @@ var PlacesUIUtils = {
                   createInstance(Ci.nsIMutableArray);
       args.appendElement(uriList);
       browserWindow = Services.ww.openWindow(aWindow,
                                              "chrome://navigator/content/navigator.xul",
                                              null, "chrome,dialog=no,all", args);
       return;
     }

-    var loadInBackground = where == "tabshifted";
+    var loadInBackground = Services.prefs.getBoolPref("browser.tabs.loadBookmarksInBackground") ?
+                           (where == "current" || where == "tab") : (where == "tabshifted");
     // For consistency, we want all the bookmarks to open in new tabs, instead
     // of having one of them replace the currently focused tab.  Hence we call
     // loadTabs with aReplace set to false.
     browserWindow.gBrowser.loadTabs(urls, {
       inBackground: loadInBackground,
       replace: false,
       triggeringPrincipal: Services.scriptSecurityManager.getSystemPrincipal(),
     });

It can be tested without recompiling, just by applying the changes into omni.ja:modules/PlacesUIUtils.jsm .

I tried Firefox v78.9.0 ESR in MacOS X El Capitan v10.11.6, and it worked nicely the way it should.

In my SeaMonkey, the ctrl+shift hot keys trick work but that's annoying.

Flags: needinfo?(ant)

(In reply to Ant from comment #18)

I tried Firefox v78.9.0 ESR in MacOS X El Capitan v10.11.6, and it worked nicely the way it should.

You mean Ctrl+Shift (or Meta+Shift) way, or something changed in 78.9.0 compared to 78.4.0?

In my SeaMonkey, the ctrl+shift hot keys trick work but that's annoying.

Then the patch should help.

Opening in "new tab" a link in CZ immediately focuses the new browser tab. :(

(In reply to Felix Miata from comment #20)

Opening in "new tab" a link in CZ immediately focuses the new browser tab. :(

It should respect the common "browser.tabs.loadInBackground" set to true...

(In reply to Dmitry Butskoy from comment #21)

(In reply to Felix Miata from comment #20)

Opening in "new tab" a link in CZ immediately focuses the new browser tab. :(
It should respect the common "browser.tabs.loadInBackground" set to true...

It doesn't. browser.tabs.loadInBackground shows true as default, and remains so here.

Well, then try to hit "shift" while open a "new tab".

You mean in 2.49.5 the behaviour differs?

(In reply to Dmitry Butskoy from comment #23)

Well, then try to hit "shift" while open a "new tab".

Tried it. No impact. Besides, my brain doesn't make any connections between mouse actions and keyboard actions. IOW, mouse and keyboard are an either/or, no ability remember which keys do what with which mouse actions. I don't even remember what the middle button hidden under the wheel is for.

You mean in 2.49.5 the behaviour differs?

2.53.7 is where I use CZ. I don't use CZ in my 2.49.5 profile.

After the bug #1379369 part1, the function utilityOverlay.js:openUILinkIn() was changed and splitted into two ones: utilityOverlay.js:openUILinkIn() and utilityOverlay.js:openLinkIn() . After that, the first one now has fromChrome flag always set. Because of this, "browser.tabs.loadInBackground" no more takes effect, if the tab is opened by openUILinkIn() .

This explans why CZ now always open new tab focused.

So either reconsider whether fromChrome in new implementation of openUILinkIn() is actually needed, or s/openUILinkIn/openLinkIn/ in chatzilla code.

The simplest way for CZ to follow "browser.tabs.loadInBackground" seems to be:

--- comm/suite/extensions/irc/xul/content/commands.js.orig	2021-03-01 21:18:24.000000000 +0300
+++ comm/suite/extensions/irc/xul/content/commands.js	2021-04-11 03:07:23.215810651 +0300
@@ -2264,18 +2264,18 @@ function cmdGotoURL(e)
             dd(formatException(ex));
         }
     }
 
     if (action == "goto-url-newtab")
     {
         try
         {
-            if (typeof browserWin.openUILinkIn == "function")
-                browserWin.openUILinkIn(e.url, "tab");
+            if (typeof browserWin.openLinkIn == "function")
+                browserWin.openLinkIn(e.url, "tab", {});
             else if (client.host == "Mozilla")
                 browserWin.openNewTabWith(e.url, false, false);
             else
                 browserWin.openNewTabWith(e.url, null, null, null, null);
         }
         catch (ex)
         {
             dd(formatException(ex));

where openLinkIn() decides itself how to open the tab depending on the standard SM prefs.

A bit strange that CZ does not use "shift" modifier anywhere...

Since 2.53.8, the patch for cZ is slightly changed:

--- comm/suite/extensions/irc/xul/content/commands.js.orig      2021-05-25 21:36:20.000000000 +0300
+++ comm/suite/extensions/irc/xul/content/commands.js   2021-05-28 20:56:51.825784239 +0300
@@ -2243,17 +2243,17 @@ function cmdGotoURL(e)
             dd(formatException(ex));
         }
     }

     if (action == "goto-url-newtab")
     {
         try
         {
-            browserWin.openUILinkIn(e.url, "tab");
+            browserWin.openLinkIn(e.url, "tab", {});
         }
         catch (ex)
         {
             dd(formatException(ex));
         }
         dispatch("focus-input");
         return;
     }

The fixing of cZ stuff is continued at bug #1713458

See Also: → 1715188
Assignee: nobody → frgrahl
Status: NEW → ASSIGNED
Flags: needinfo?(frgrahl)
Attached patch 1619108-libraryopen-25317.patch (obsolete) — Splinter Review

This treats opening links by clicking on them in the library differently. Rules for external applications are applied. Not yet perfect. Both browser focus and load in background are not yet applied. Focus browser setting for loads from external applications is substituted for both. It works more or less because opening bookmarks from the toolbar or menu replaces the current tab.

Should be in tomorrows 2.53.17b1 prerelease. Feedback welcome.

Now unused browser.tabs.loadBookmarksInBackground pref removed. I prefer to no yet have another set of semi documented opening prefs just for the library. One for internal use and one for (more or less) external use should hopefully all which is needed.

Attachment #9327838 - Flags: feedback?(nunojsg)
Attachment #9327838 - Flags: feedback?(iannbugzilla)

Comment on attachment 9327838 [details] [diff] [review]
1619108-libraryopen-25317.patch

It would be nice to have a single helper function to determine where to load a link, but I think this is a good starting point for future clean up.

Attachment #9327838 - Flags: feedback?(iannbugzilla) → feedback+

Version 1 1. switches openAsExternal to using the new function too. I doubt I will find the time to do other enhancements soon so lets get this reviewed first and worry later (hopefully without new problems).

[Approval Request Comment]
Regression caused by (bug #): Bug 1378089
User impact if declined: Unable to set defaults for opening bookmarks from the library via prefs.
Testing completed (on m-c, etc.): 2.53.17b1 pre
Risk to taking this patch (and alternatives if risky): Mostly trivial
String changes made by this patch: none

Attachment #9327838 - Attachment is obsolete: true
Attachment #9327838 - Flags: feedback?(nunojsg)
Attachment #9330009 - Flags: review?(iannbugzilla)
Attachment #9330009 - Flags: approval-comm-release?

Comment on attachment 9330009 [details] [diff] [review]
1619108-libraryopen-1_1-25317.patch

[Triage Comment]
Considering this is a basis for future work, LGTM r/a=me

Attachment #9330009 - Flags: review?(iannbugzilla)
Attachment #9330009 - Flags: review+
Attachment #9330009 - Flags: approval-comm-release?
Attachment #9330009 - Flags: approval-comm-release+

Pushed by frgrahl@gmx.net:
https://hg.mozilla.org/comm-central/rev/c40553ca74b8
Treat opening urls from the library as external. r=IanN

Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Whiteboard: SM2.53.17
Target Milestone: --- → Future
You need to log in before you can comment on or make changes to this bug.