Closed
Bug 1425829
Opened 7 years ago
Closed 6 years ago
New popup window appears blank until right-click
Categories
(WebExtensions :: Frontend, defect, P3)
Tracking
(firefox59 affected)
RESOLVED
DUPLICATE
of bug 1408446
| Tracking | Status | |
|---|---|---|
| firefox59 | --- | affected |
People
(Reporter: mozbug, Unassigned)
References
Details
Attachments
(3 files)
Blank window before right-click
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};
browser.windows.create(options);
Even when the HTML file is something really simple like this:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title data-i18n="createTitle"></title>
</head>
<body>
HELLO
</body>
</html>
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.
|
||
Comment 2•7 years ago
|
||
Sam, could you please add an example of the extension reproducing the issue for debugging purposes?
Flags: needinfo?(mozbug)
|
|
||
Comment 4•7 years ago
|
||
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?
|
|
||
Updated•7 years ago
|
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: https://addons.mozilla.org/en-GB/firefox/addon/trashmailnet/
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.
Apparently, the bug reports are only coming from Linux users (myself included), in case that helps.
|
|
||
Updated•7 years ago
|
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Version: 57 Branch → Trunk
|
|
||
Updated•7 years ago
|
|
|
||
Comment 8•7 years ago
|
||
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 ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Updated•7 years ago
|
Priority: -- → P3
|
|
||
Updated•7 years ago
|
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): https://addons.mozilla.org/en-US/firefox/addon/keefox/
* SAML Tracer: https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/
The following posts also report the same issue with other extensions:
https://discourse.mozilla.org/t/ff57-browser-windows-create-displays-blank-panel-detached-panel-popup/23644
https://discourse.mozilla.org/t/ff57-browser-windows-create-displays-blank-popup/22815
the first one contains even more information to reproduce it.
|
||
Comment 10•7 years ago
|
||
Duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1408446 ?
|
||
Comment 11•7 years ago
|
||
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. browser.windows.create 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):
https://thumbs.gfycat.com/CluelessFemaleDavidstiger-size_restricted.gif
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):
https://thumbs.gfycat.com/DeficientIdolizedKittiwake-size_restricted.gif
Autofocus attribute on text field is working normally. But it got the blank popup window bug.
|
||
Comment 12•7 years ago
|
||
https://discourse.mozilla.org/t/ff57-browser-windows-create-displays-blank-panel-detached-panel-popup/23644/5 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 browser.windows.getCurrent();
browser.windows.update(id, {
width: width + 1,
height: height + 1
});
}
```
|
||
Comment 13•7 years ago
|
||
This bug just started appearing for me immediately after upgrading to Firefox 60. In Firefox 59 I wasn't affected yet.
|
||
Comment 14•7 years ago
|
||
The same for me, the workaround has stop to work in Firefox 60.
In Firefox 60 browser.windows.create / browser.windows.getCurrent have stopped to return the Promise result.
(and I'm a Linux user too)
|
||
Comment 15•6 years ago
|
||
So I've been seeing something similar with my extension:
https://addons.mozilla.org/firefox/addon/character-identifier/
(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:
https://searchfox.org/mozilla-central/rev/3737701cfab93ccea04c0e9cab211ad10f931d87/browser/base/content/tabbrowser.css#91-94
to apply and hide the <browser>.
I haven't yet debugged why *that* is happening, though.
|
|
||
Comment 16•6 years ago
|
||
A few observations from debugging blank="true" last night, not very well verified:
* the <browser> starts off with blank="true": https://searchfox.org/mozilla-central/rev/3737701cfab93ccea04c0e9cab211ad10f931d87/browser/base/content/browser.xul#1232
* there are three places that removeAttribute("blank"): https://searchfox.org/mozilla-central/search?q=removeAttribute%28%22blank%22%29&path= (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 https://searchfox.org/mozilla-central/source/browser/base/content/browser.js#1622
* 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.
|
|
||
Comment 17•6 years ago
|
||
(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.
|
||
Updated•6 years ago
|
|
||
Updated•6 years ago
|
Product: Toolkit → WebExtensions
|
||
Comment 19•6 years ago
|
||
I'm 98% sure this is a dupe of bug 1408446.
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox57:
affected → ---
status-firefox58:
affected → ---
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•