1425424 - browser_style does not appear to work for option pages

Status: RESOLVED INVALID

(WebExtensions :: Untriaged, defect, P2)

Description

[Anthony Shipman]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

I created an options page, set with the options_ui part of the manifest. 


Actual results:

I checked through the CSS using the Browser Toolbox debugger that shows the chrome surrounding the page. I could find no browser_style CSS that was visible to the options page. The CSS that was in the add-on manager pages was not visible to my options page.


Expected results:

I want to set the style of the options to match the rest of the material on the add-on's options page (Under Tools->Add-ons)

Comment 1

[Andy McKay]

This was added in bug 1275287, has it regressed since then, or is just not visible?

Comment 2

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

When the extensions are running in OOP mode (which is the default on Windows starting from Firefox >= 56), the options_ui page is running in the extension process instead of running in the main process, and so the Browser Toolbox cannot be used to inspect the options_ui page anymore, and the Addon Debugging window (the one opened from about:debugging#addons) has to be used instead.

We have a mochitest-browser test that is explicitly testing that the browser_style css is applied to the options_ui page and so, given that all the mochitest-browser extension tests are executed in both OOP and non-OOP mode, this feature should not have regressed without being caught by a failure on the following test file:

- https://searchfox.org/mozilla-central/source/browser/components/extensions/test/browser/browser_ext_optionsPage_browser_style.js

Comment 3

[Anthony Shipman]

I am using FF 56-dev on Linux.  The options_ui page appears in Browser Toolbox under
all of the chrome. 

I tried this again and I can't reproduce the problem.  It is now picking up browser-style
stuff from extensions.css

Comment 4

[Anthony Shipman]

Agh.  I've misdescribed the problem and should create a new bug report. 
The Browser Toolbox shows that the Add-Ons manager page on which the options_ui 
page is installed does not use browser-style.  For example the HTML has

<xul:label class="detail-row-label" xbl:inherits="value=label" value="Last Updated"></xul:label>

The classes used in the upper part of the options page are not available to the options_ui page
so I can't make them match.  The browser-style styles don't match the top part of the options page.

If you like you can close this and I'll create a new bug report.

Comment 5

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

(In reply to als from comment #4)
> Agh.  I've misdescribed the problem and should create a new bug report. 
> The Browser Toolbox shows that the Add-Ons manager page on which the
> options_ui 
> page is installed does not use browser-style.  For example the HTML has
> 
> <xul:label class="detail-row-label" xbl:inherits="value=label" value="Last
> Updated"></xul:label>
> 
> The classes used in the upper part of the options page are not available to
> the options_ui page
> so I can't make them match.  The browser-style styles don't match the top
> part of the options page.

That is expected, the options_ui page is always isolated (besides OOP or non OOP mode) from the about:addons page that contains it (and the about:addons page is not even HTML, currently it is still a XUL document), and not all the CSS styling that are applied to the about:addons XUL page are part of the browser-style CSS (only a subset of them).

> If you like you can close this and I'll create a new bug report.

Thanks for the confirmation, I'm closing this issue as invalid.