Open Bug 1619108 Opened 1 year ago Updated 12 days 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.49esr unaffected, seamonkey2.53 affected, seamonkey2.57esr affected)

Tracking Status
seamonkey2.49esr --- unaffected
seamonkey2.53 --- affected
seamonkey2.57esr --- affected

People

(Reporter: ant, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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...

You need to log in before you can comment on or make changes to this bug.