1416505 - WebExtensions popup blank

Status: RESOLVED DUPLICATE of bug 1547277

(WebExtensions :: Frontend, defect, P1)

Description

[Leif-AMO]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.2.2 Waterfox/55.2.2
Build ID: 20171010194856

Steps to reproduce:

WebExtension addon has a browser_action defined with a default_popup set to popup.html, which I am left-clicking the button to trigger popup, loads a simple JavaScript that fires a function on readystatechange handler when document.readystate === 'complete', and walks through the DOM recursively and replaces textContent on text nodes, otherwise may replace specific attribute text on element nodes, if any, before recursing inside element.


Actual results:

In 58 nightly, the popup has about a 50-75% chance of appearing completely blank.  In 57.0b13, the problem existed, but had about a 5-10% chance of appearing blank.  Seems to behave correctly in v56.  The popup size remains as if the text was there.  Not sure how to DOM Inspect a popup to see what's going on.  If I completely disable the popup.js file, I get the HTML appearing.  But then I have no way to convert l10n strings.


Expected results:

I should have the page load, hit ready state of complete, fire function to walk through nodes, replace textContent, and have a localized popup.

Comment 1

[Andy McKay]

Do you have a simple add-on that could reproduce this please?

Comment 2

[Carsten Nielsen]

Check number 1: https://github.com/phreaknerd/WebExtensionFrontendBugs

It's about external popups, not the gui-integrated ones.

Comment 3

[Shane Caraveo (:mixedpuppy)]

The extension in comment 2 doesn't replicate exactly what OP posted, however it is probably the same issue.  A quick test for OP would be (adding to extension from comment 2 for ease):

panel.html
<div id="text">some text</div>

panel.js
document.onreadystatechange = function () {
  if (document.readyState === "complete") {
    document.getElementById('text').textContent = "This text has been replaced with some really very long text that should force a resize of the panel that is containing the page.";
  }
}

I'm not really certain what the extension from OP would do, but this is a guess.  Cannot replicate on osx, and windows hg is taking forever right now.

Given the extension in comment 2 (which apparently replicates in a popup *window*), I don't think this has anything to do webextensions, but likely some paint refresh issue.

Comment 4

[Shane Caraveo (:mixedpuppy)]

Luca reproduced the paint issue in a browserAction, but couldn't as a window popup.

Comment 6

[Shane Caraveo (:mixedpuppy)]

The bug I just dup'd here is an easy repro of this issue.  Also has a nice video showing the problem.

Comment 8

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: layerscope_bug1416505.zip

While looking into another issue related to the extension popups I've been able to collect some additional information using LayerScope (https://wiki.mozilla.org/Platform/GFX/LayerScope and http://mozilla.github.io/layerscope/) that may be useful to get a better picture of the underlying issues.

The attached file is dump of the information collected by LayerScope once I've been able to reproduce the issue (which is not happening only from time to time when opening the extension popup), and I'm also going to attach the test extension that I used to reproduce it.

After loading from http://mozilla.github.io/layerscope/ the attached zip file, the following frames can be used to compare the behavior when the issue is being triggered against the behavior of a popup rendered correctly:

- from frame 6 to frame 7: it is when I clicked the browserAction and the issue is being triggered
- from frame 11 to frame 13: it is when I clicked the browserAction again and the popup has been rendered correctly

I've also been able to attach the devtools toolbox to the popup when it was blank (by running the Firefox instance inside Xephyr so that the popup doesn't lose the focus when I switched to the developer tools window) and as soon as I opened the devtools inspector panel on the popup, it has been immediately rendered (which wasn't unexpected, I'm pretty sure that the highlighter injected by the devtools inspector tool are forcing the popup content to redraw, similarly to what happens if I try to select the text inside the blank popup content).

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: bug-1416505-popup-blank-issue.xpi

Comment 10

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 1416505 - Fix popup blank for oop extensions.

Review commit: https://reviewboard.mozilla.org/r/227006/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/227006/

Comment 11

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 8958062 [details]
Bug 1416505 - Fix popup blank for oop extensions.

https://reviewboard.mozilla.org/r/227004/#review232746

::: browser/components/extensions/ExtensionPopups.jsm:512
(Diff revision 1)
>      this.browser.swapDocShells(browser);
>      this.destroyBrowser(browser);
>  
>      if (this.dimensions) {
>        if (this.fixedWidth) {
>          delete this.dimensions.width;
>        }
>        this.resizeBrowser(this.dimensions);
>      }
>  
> +    // Force a redraw of the popup content as a workaround for
> +    // rendering issues of the "oop extension" popup content
> +    // (See Bug 1416505 for a rationale).
> +    this.window.promiseDocumentFlushed(() => {
> +      if (!this.destroyed && this.browser && this.browser.isRemoteBrowser) {
> +        this.browser.messageManager.sendAsyncMessage("Extension:ForceRedraw");
> +      }
> +    });
> +

The browserAction popup window is the only one that is actually preloaded in an hidden browser XUL element (when the user move the mouse over the browserAction toolbar button) and then moved into a new browser XUL element created in the popup when it is going to be shown (when the user has released the left mouse button over the browserAction toolbar button) with the `this.browser.swapDocShells(browser)` call from line 512.

After the docShells have been swapped, we could have to resize the newly created browser XUL element to match the preferred size received from the extension page loaded into the popup (e.g. the attached test extension writes some additional text content into one of the DOM elements, which increases the preferred size of the document).

My guess (based on the behavior of the issue and the additional information collected using LayerScope) is that the `browser.swapDocShells` may be part of what is triggering the issue (e.g. the texture of the popup content is being lost if it happens while we are swapping the docShells, not sure if the browser resizing may also have a role into the issue).

I still think that it would be better if we could identify how the issue with the missing texture may be fixed where it is actually happening (and I hope that the additional information collected using LayerScope may be useful to achieve that), but I also looked if it was also possible to workaround the issue from ExtensionPopups.jsm / ext-browser-content.js. 

With this patch applied I've not been able to trigger the issue anymore locally (I tried on both Windows, where the extension popup are already been running in oop mode, and on Linux, by manually forcing the extension oop mode using the about:config preference).

As an additional note if the "Extension:ForceRedraw" is sent immediately after the docShell swapping (and XUL browser resize), e.g. without using `this.window.promiseDocumentFlushed`, the issue can still be triggered (and it can also be triggered if I use `this.window.requestAnimationFrame` instead of `this.window.promiseDocumentFlushed`).

Comment 12

[Luca Greco [:rpl] [:luca] [:lgreco]]

It seems that PanelMultiView.jsm may have met a similar issue before (and it seems that they had to workaround it here: https://searchfox.org/mozilla-central/rev/8976abf9cab8eb4661665cc86bd355cd08238011/browser/components/customizableui/PanelMultiView.jsm#720-724) which is tracked by Bug 1441015, and the issue description has some similarities to the behaviors observed about this issue.

I'm adding Bug 1441015 as a see also here (because they seems to be related but it is not clear if they could also be duplicate of the same underlying issue).

Comment 13

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 8957595 [details]
layerscope_bug1416505.zip

Hi Milan,
can someone from GFX take a brief look to the data collected (using LayerScope) and attached here to check if there something useful that may tell us more about the reasons behind this rendering issue?

In case it can be useful:

- in comment 8 there are some additional notes about the content of the LayerScope data collected
- attachment 8957597 [details] is the small test extension that I used to reproduce the issue locally
- in comment 11 I've added some details about the workaround patch attached as attachment 8958062 [details]
- in comment 12 there is a link to another bugzilla issue that seems to be related to a similar issue triggered by PanelMultiView.jsm

Thanks in advance!

Comment 14

[Bas Schouten (:bas.schouten)]

This seems to be related on invalidation, Matt would be a much better person to say something sensible about this.

Comment 15

[Matt Woodrow (:mattwoodrow)]

Has this been fixed?

I can't reproduce this issue (Latest Nightly, OSX and Windows 10), using the test addon from this bug, and the one from bug  1440006

Comment 16

[Shane Caraveo (:mixedpuppy)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #15)
> Has this been fixed?

Luca is probably best to answer that.  Probably good to ni? him.

Comment 17

[Luca Greco [:rpl] [:luca] [:lgreco]]

I just tried again on today mozilla-central artifact build and I can't reproduce it anymore.

The issues seems to have been fixed as a side-effect of the changes applied recently by
Bug 1449933, in particular by the following line

- https://searchfox.org/mozilla-central/rev/78dbe34925f04975f16cb9a5d4938be714d41897/browser/components/extensions/ExtensionPopups.jsm#361

which set the background to white if not explicitly set yet.

I also briefly verified that comment the line linked above is enough for me to be able to reproduce the issue again.

Comment 18

[Anthony Shipman]

I have this bug with my add-on on Linux, openSuse Leap 43. I am using developer edition 62.0b6.
It happens 100% of the time. If I right click on the panel to get the context menu then the contents of the panel are drawn. If I make other windows appear over the panel that doesn't prompt a redraw of the panel.

If I add the update trick to increase the panel height by 1 pixel after the panel has been created then it happens the first time after loading a new page.  Subsequent appearances of the panel on that page are drawn correctly but with messy glitching due to the resizing.

Comment 19

[Carsten Nielsen]

Still an issue in Version 61.0.1

Comment 20

[Carsten Nielsen]

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

Steps to reproduce:

1. Install an addon that opens a popup-window.
(https://addons.mozilla.org/en-US/firefox/addon/password-hasher-ng/)
2. Visit any login page with a password field.
3. Right click on the password field and choose Password hasher



Actual results:

The opened popup is empty.
Resize the popup (by dragging the border slightly) window to see its contents.


Expected results:

The content of the popup should be visible from the beginning.

Comment 22

[Rob Wu [:robwu]]

I have been seeing this issue when trying to reproduce bug 1501006 : https://bugzilla.mozilla.org/attachment.cgi?id=9019096&action=edit
That test case has an extension popup panel containing an input field and button, and when I move the mouse from the bottom-left corner of the window up to the extension action button and then click on it, then I get a blank popup very often.

This used to only happen on Nightly, but after upgrading stable to 63 (where OOP extensions are enabled by default on Linux), it also started happening on stable.

Comment 23

[Remus Dranca [rdranca], Ecosystem QA]

It seems that this issue also affects the Test Pilot experiments. Please see bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1457429).

However this seems to be an old regression. Using mozregression tools I have managed to get a pushlog:https://tinyurl.com/y7sljqou.
Unfortunately, I didn't manage to go further since there are very old builds. So probably one of the issues from the pushlog introduced this.

Comment 25

[Dale P. Smith]

Still an issue for me in 66.0 (64-bit) Linux and Nightly 68.0a1 (2019-03-20) (64-bit) Linux.

Comment 26

[Yanfang Liu]

The issue can be reproduced in 67.0b13(64-bit) Windows 10, using the test addon from this bug.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Build Id: 20190422163745

Comment 27

[Luca Greco [:rpl] [:luca] [:lgreco]]

As described in comment 8 and comment 13 this looks like an issue while at a gfx layer, the attachment 8958062 [details] contains a possible workaround (which basically forces a redraw right after the invisible XUL browser used to preload the popup is swapped with the XUL browser actually visible in the browserAction popup) but the actual issues seems to be actually happening at a gfx layer.

I also recall, from the past investigations on this issue, that the underlying issue looked as some kind of race, because the timing of pressing and releasing the mouse on the browserAction was affecting the ability of triggering these intermittent rendering issue.

The fact that the reproducibility of this issue depends from the timing of the browser swapping happening for a browserAction popup is also very likely the reason why it seems that the changes in Bug 1446027 may have made this issue easier to reproduce.

Comment 28

[Dale P. Smith]

(In reply to Luca Greco [:rpl] from comment #27)

I also recall, from the past investigations on this issue, that the underlying issue looked as some kind of race, because the timing of pressing and releasing the mouse on the browserAction was affecting the ability of triggering these intermittent rendering issue.

The fact that the reproducibility of this issue depends from the timing of the browser swapping happening for a browserAction popup is also very likely the reason why it seems that the changes in Bug 1446027 may have made this issue easier to reproduce.

Yes! When I very quickly click the browser action icon, the browser action popup is always rendered fully and properly.

When I press and then release a moment later, the popup shows the bug: an "empty" popup that is painted as the mouse hovers over it.

Not sure what the minimum time is for a "good" click. Anything longer than a quick click is too long. Guessing about 10ms or so.

Comment 29

[Timothy Nikkel (:tnikkel)]

Bug 1547277 might have fixed this, someone should retest in a build with that fixed.

Comment 30

[Yanfang Liu]

I verified and can confirm that this issue is fixed for the latest Firefox Nightly (68.0a1, buildID:20190514214217) on Windows 10 x64, Ubuntu 15.04 and mac OS 10.13.6.

Comment 31

[Dale P. Smith]

Yep. Works for me on 64bit Linux Firefox Nightly 68.0a1 (2019-05-16).

Whoo.