sdk/windows.browserWindows does not include pre-existing private browsing windows when addon enabled or installed

RESOLVED INCOMPLETE

Status

Add-on SDK
General
RESOLVED INCOMPLETE
2 years ago
3 months ago

People

(Reporter: Josh Brennan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20150819004006

Steps to reproduce:

Create a boilerplate jpm addon.
In the package.json, make sure you include
"permissions": { 
    "private-browsing" : true
}

Include the following line:
var windows = require("sdk/windows");
Access the windows.browserWindows property in the main function.
jpm run --debug
Add a breakpoint on the line that you access browserWindows.
Open a Private Window and keep the existing window open.
Disable then enable the addon.
Check the browserWindow objects returned by windows.browserWindows


Actual results:

windows.browserWindows only contains normal browsing windows.


Expected results:

windows.browserWindows should contain normal browsing windows AND private browsing windows. Docs suggest this should be the case (https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/private-browsing).
(Reporter)

Comment 1

2 years ago
In case it helps, this seems to stem from an issue with windows() in sdk/windows/utils.js
I stumbled upon this earlier:
http://stackoverflow.com/questions/24082423/private-windows-with-requiresdk-window-utils-windows/24084063

Also:
sdk/windows/firefox.js:185
for (let domWindow of windows()) {
  let window = makeNewWindow(domWindow);
  if (window instanceof BrowserWindow)
    addListItem(browserWindows, window);
}
There doesn't seem to be anything at this level to handle whether an opted in addon should be given private browsing windows too.

I was honestly just trying to patch up an old/broken addon when I ran into this weirdness!
(Reporter)

Updated

2 years ago
Summary: sdk/windows.browserWindows does not include private browsing windows → sdk/windows.browserWindows does not include pre-existing private browsing windows when addon enabled or installed
(Reporter)

Comment 2

2 years ago
Narrowed it down to freshly installed or enabled extensions not having access to any private windows that had been opened beforehand.
I genuinely can't tell whether this is by design (to protect privacy, I guess?) or a bug.
Just providing a prebuilt xpi unfortunately won't work with the test I built.
https://github.com/JBPhoenix/test-pb-browserwindow-bug
Hope someone is willing to clone and fire off a jpm run --debug.

Comment 3

a year ago
I can confirm that it is a bug.

Users have reported that my add-on is not working in the inital private window when Firefox starts in private mode. https://github.com/Croydon/vertical-tabs-reloaded/issues/41

Every other additional window (private & regular) is getting exposed by the API, just not the initial private one.

I have created a test case for it: https://github.com/Croydon/vtr-test

I consider this a major bug, would be nice if it gets fixed.

Comment 4

8 months ago
Congratulations, Firefox staff.

You completely ignored this bug report for two years (also bug 1248903) and somewhen recently fixed this by accident.

I can no longer reproduce this bug and it works as expected now.
https://bugzilla.mozilla.org/show_bug.cgi?id=1399562
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.