Long leaving bug(?)

[_yup_]

Mozilla documentation (http://udn.realityripple.com/docs/Archive/Add-ons/Tabbed_browser) says about openUILinkIn(url, where, allowThirdPartyFixup, postData, referrerUrl) function:

where:

• "current" current tab (if there aren't any browser windows, then in a new window instead)
• "tab" new tab (if there aren't any browser windows, then in a new window instead)
• "tabshifted" same as "tab" but in background if default is to select new tabs, and vice versa

The same is written in the Pale Moon sources (https://repo.palemoon.org/MoonchildProductions/Pale-Moon/src/branch/master/palemoon/base/content/utilityOverlay.js):

* |where| can be:
* "current" current tab (if there aren't any browser windows, then in a new window instead)
* "tab" new tab (if there aren't any browser windows, then in a new window instead)
* "tabshifted" same as "tab" but in background if default is to select new tabs, and vice versa

"if default is to select new tabs" refers to the value of browser.tabs.loadInBackground parameter in about:config.

Nevertheless, when I use "tab", Pale Moon always opens URL in a new foreground tab (and in a new background tab, when I use "tabshifted") - regardless of browser.tabs.loadInBackground state.

Pale Moon is not alone here - Basilisk and ancient Firefox 49-53 work in the save way.
At the same time Seamonkey and Iceape-UXP work as documentation prescribes, and take browser.tabs.loadInBackground into account.

(For reproducing you can execute openUILinkIn("https://palemoon.org", "tab"); and openUILinkIn("https://palemoon.org", "tabshifted"); in the browser console.)

If behavior of function contradicts its specification, then this is definitely a bug. But should so long existent bug be fixed? I fear that there is a lot of code that depends on current behavior, so changing it can break something else.

Why am writing this: now I am finishing work on some multi-platform extension which uses this function, and don't know how to handle this issue - analyze the platform and then use corresponding branch of code, or use this function in accordance with documentation for all browsers (in hope that Pale Moon and Basilisk will be fixed somewhen)?

[vannilla]

This is interesting. Apparently the "bug" is this snippet:

Code: Select all

let loadInBackground = where == "current" ? false : aInBackground;
  if (loadInBackground == null) {
    loadInBackground = aFromChrome ?
                       false :
                       Services.prefs.getBoolPref("browser.tabs.loadInBackground");
  }

It starts at line 336 of the linked utilityOverlay.js file.

The aInBackground variable is always "empty" (i.e. == null) when openUILinkIn is used, so the loadInBackground null-check always goes through.
On the other hand, aFromChrome is always true when openUILinkIn is used and this makes the code completely ignore the preference (or act as if the preference is always false, however you want to see it).

Changing this piece of code might have cascading effects since apparently at some point someone needed to be explicit on the request's origin (chrome or content), which is always a sign of extreme coupling and the openLinkIn function might be used even in places it shouldn't be.