If you notice anything that doesn't look right, please speak to a member
of staff or text the British Transport Police at six-one-zero-one-six...
Whoops, wrong announcement! Let's retry. If you're using Nightly and
notice anything that looks off in the main browser interface or
secondary windows, like an incorrect margin, color, or button state,
please use mozregression to determine if it's caused by one of the CSS
updates we're about to land, and file a bug in the "Firefox :: Theme"
component as usual.
The "browser.xul" window and other XUL documents use a variety of CSS
stylesheets to define the appearance of interface elements. Many styles
are defined in XBL stylesheets, some are defined in UA stylesheets, and
others in regular stylesheets imported in the document. These all have
different "cascade levels", meaning that the CSS specificity rules don't
apply as one would expect if the sheets were at the same cascade level.
There's no way to tell the difference just by looking at the file name.
Today we are starting a process to convert XBL stylesheets to regular
document stylesheets, and remove the XBL cascade level completely. We
are also making sure that the sheets in the "browser" folder are loaded
after those in the "toolkit" folder, because the former are meant to
override the latter in the main browser window. This will make things
easier because rules in "browser" will always take priority when they
have the same specificity as those in "toolkit".
This will greatly simplify reasoning about browser styles going forward,
but there will be an initial cost. We have too many CSS rules to check
them individually, and the "MozScreenshots" regression tests are limited
to the main interface, so as we make these changes we expect the
appearance of widgets to regress in subtle ways. This is part of the
process, and this is why we are landing stylesheets migrations one by
one, in dependencies of meta-bug 1470830.
If you notice a regression, just file a bug in the "Firefox :: Theme"
component. It would help a lot if you could use mozregression to find
the exact bug it should block, rather than just blocking the meta-bug.
We expect to respond quickly to bugs caused by these modifications,
especially during the upcoming long Nightly cycle. While most migrations
will land in one or two weeks, we may find some regressions only later.
This plan of record has been defined after various attempts at different
migration strategies in the past few months. If you're curious, you can
find relevant discussion in these bugs:
These are all under the tracking bug for the XBL removal project:
firefox-dev mailing list