1353022 - Creating a chrome privileged windowless browser and loading a XUL window into it from a bootstrap.js script confuses Windows theming code

Status: NEW

(Core :: Widget: Win32, defect, P3)

Description

[:Gijs (he/him)]

Attachment: Example add-on

I don't pretend to understand what's going on here, but the breakage here is... surprising. It suggests that if we ever create certain content (not sure what!) in a windowless browser before we create a normal window (or, perhaps, the hidden window, if that's any better-behaved...), Firefox starts looking bad. People noticed this with my initial fix for uBlock Origin in https://github.com/gorhill/uBlock/issues/2502 . I'm attaching a minimal testcase.

STR:

1. Install attached add-on (you might need to disable signature checks on Nightly)
2. restart nightly.

ER:
Nightly looks just like before

AR:

    windowlessBrowser = appShell.createWindowlessBrowser(true);
    windowlessBrowser.document.location = "data:application/vnd.mozilla.xul+xml;charset=utf-8,<window%20id='" + hostName + "-win'/>";

in bootstrap.js' startup method seem to be enough to mess up our theming.


When looking at this with the browser toolbox, it seems that at the chrome window level of browser.xul, Windows media queries are returning inaccurate results (uncannily similar to bug 1351676) - layout thinks we're not using -moz-windows-default-theme, for instance.

I expect this is because something is doing checks/measurements that are getting cached and never updated.

Comment 1

[:Gijs (he/him)]

Attachment: Screenshots of bad (top) and good (bottom) titlebar/toolbar styling on win10

Comment 2

[Jim Mathies [:jimm]]

What's the use case here, is this windowless browser something we plan / are using?

Comment 3

[:Gijs (he/him)]

(In reply to Jim Mathies [:jimm] from comment #2)
> What's the use case here, is this windowless browser something we plan / are
> using?

Yes, it's used from the add-on SDK, from webextensions, and from all the (other) internal modules that use HiddenFrame.jsm. Right now I think through various reasons those will all load after other things happen (which make this not break) but I don't think leaving this race condition around is a good idea long-term. Plus, as long as we don't fully understand /why/ this happens it's hard to guarantee there aren't edgecases where it already happens that we're just not aware of.

Finally, as noted in comment #0, I expect the cause will be related to the cause of bug 1351676 which we need addressed in order to provide correctly-styled in-content video controls everywhere on Windows (and might start affecting other in-content stuff once we start using the content process for more chrome-y stuff like about:addons/about:preferences/about:newtab/activitystream).

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information