Closed Bug 1425829 Opened 2 years ago Closed 2 years ago

New popup window appears blank until right-click


(WebExtensions :: Frontend, defect, P3)



(firefox59 affected)

Tracking Status
firefox59 --- affected


(Reporter: mozbug, Unassigned)




(3 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171129230835

Steps to reproduce:

Open a new popup window with this code:

    var options = {"url": "../create-address/create-address.html",
                   "type": "popup", "width": 750, "height": 490};;

Even when the HTML file is something really simple like this:

    <!DOCTYPE html>
	    <meta charset="utf-8" />
        <title data-i18n="createTitle"></title>

Actual results:

The window is displayed completely blank. The page content does not appear until I right-click the window.

Expected results:

The page content should be loaded immediately.

I am able to reproduce this 100% of the time in my dev version of Firefox (57.0.1 on Ubuntu) with the extension loaded as a temporary extension. When installed normally on my regular version of Firefox (also 57.0.1 on Ubuntu), the problem is not always apparent, but it still seems that there is often a delay before the page renders, and on some occasions needs the right-click to get it to display.

The only error I see consistently when debugging the extension while opening the window is:
TypeError: invalid 'in' operand browser[Learn More]  tabbrowser.xml:2426:1
Also, I developed the extension on FF 56, and don't recall noticing any issues until I started using it on FF 57, so this may be a regression between these versions.
Sam, could you please add an example of the extension reproducing the issue for debugging purposes?
Flags: needinfo?(mozbug)
Attached file
Flags: needinfo?(mozbug)
Attached file remadetest.xpi
Sam, the example add-on is incomplete, it misses the icon. I am uploading an updated version, but I'm not able to reproduce the problem at all. I've tried using 57.0.2 (2017-12-06) and 57.0a1 (2017-08-05) on Ubuntu 16.04 x64, since you hinted it might be a regression. 

I'm not sure what dev. version (57.0.1 on Ubuntu) from comment 0 means? Could you take a look at the test extension and check if it's correct and you can reproduce with it?

While you are at it, could test if turning on extensions.webextensions.remote and see if there is any change in the behavior?
Flags: needinfo?(mozbug)
The addon works for me, any icon should be optional. I'm simply unpacking the zip file and then opening the manifest file from about:debugging, loading it as a temporary addon. You should then be able to right-click an editable field and open the window.

The actual full addon is:

I changed extensions.webextensions.remote and now the window loads immediately, fixing the issue. What does this option do?

My dev Firefox is basically just an Ubuntu Firefox run from an LXC container, it might also be the Firefox Developer edition, or I've just installed the additional debugging extensions that normally come with that.
Flags: needinfo?(mozbug)
Last night we got a bug report against our extension showing the same issue, so this is definitely not just me.
OS: Unspecified → Linux
Apparently, the bug reports are only coming from Linux users (myself included), in case that helps.
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Version: 57 Branch → Trunk
I could reproduce the issue with the extension from comment 5 and Firefox Nightly 59.0a1 Build ID 	20171228100111 on Ubuntu 16.04 x64.

At this point setting the security.sandbox.content.level to 2 or setting extensions.webextensions.remote to true solves the issue and the pop-ups show properly and the bug is not reproducible (both preferences not default in 59-57).

might also be related to bug 1353060 ?
Ever confirmed: true
Priority: -- → P3
Component: WebExtensions: Untriaged → WebExtensions: Frontend
I can confirm that this happens for me on Linux with FF 57.0.4 (Ubuntu) with two different extensions:
* Kee (formerly KeeFox):
* SAML Tracer:

The following posts also report the same issue with other extensions:
the first one contains even more information to reproduce it.
This bug can be reproduced easily in Windows too.

In Windows, extensions.webextensions.remote is set to true by default. But in Linux, it is set to false by default. If set extensions.webextensions.remote to false in Windows, then it will have similar behavior bug. with popup/panel/detached_panel type will create a blank popup window unless right-click to it.

And maybe it is related to Bug 1324255 somehow. See below.

If set extensions.webextensions.remote to true (default in windows):
Any popup windows are opened normally as usual so I didn't record it. You can see the Bug 1324255 is present (autofocus on text field is not working).

If set extensions.webextensions.remote to false (default in linux):
Autofocus attribute on text field is working normally. But it got the blank popup window bug. offers a workaround though it is not working for me, though adjusting height and width does do the trick:

async function firefoxWorkaroundForBlankPanel () {
    const {id, width, height} = await;, {
        width: width + 1,
        height: height + 1
This bug just started appearing for me immediately after upgrading to Firefox 60. In Firefox 59 I wasn't affected yet.
The same for me, the workaround has stop to work in Firefox 60.

In Firefox 60 / have stopped to return the Promise result.

(and I'm a Linux user too)
So I've been seeing something similar with my extension:
(install extension, select some text on a web page, right-click, and choose "Identify Characters" in the context menu; the window that results is blank until a right click or a resize), that sounds the same as the problems described here.

I debugged the problem a bit, and so far I've found that the problem is that the <browser> element in the (basically empty) chrome window that contains the content has the blank="true" attribute set, which causes this rule:
to apply and hide the <browser>.

I haven't yet debugged why *that* is happening, though.
A few observations from debugging blank="true" last night, not very well verified:

 * the <browser> starts off with blank="true":

 * there are three places that removeAttribute("blank"): (I'm thinking about the 2 in AsyncTabSwitcher.jsm as one.)  I *think* the one that's supposed to happen here (although I haven't verified this, and probably should), is the "Browser:NonFirstBlankPaint" message listener at

 * However, it looks like that message listener doesn't fire until we actually do something else (haven't looked at what *that* is, either, although I'm guessing it's the AsyncTabSwitcher code) to remove the blank attribute.  I suspect this is because we're dealing with an in-process tab in this case (why?) rather than the normal cross-process tab, and the painting code is therefore unified between the iframes and we don't do any painting inside the iframe until the opacity is removed.
(In reply to David Baron :dbaron: ⌚UTC-7 from comment #16)
>  * However, it looks like that message listener doesn't fire until we
> actually do something else (haven't looked at what *that* is, either,
> although I'm guessing it's the AsyncTabSwitcher code) to remove the blank

It's actually not.  It's that right clicking or resizing somehow actually makes a paint happen in the iframe despite the opacity:0, and thus sends Browser:FirstNonBlankPaint, causing the blank="true" and the opacity:0 to be removed.
See Also: → 1408446
Product: Toolkit → WebExtensions
I'm 98% sure this is a dupe of bug 1408446.
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1408446
You need to log in before you can comment on or make changes to this bug.