Closed Bug 1470840 Opened 6 years ago Closed 6 years ago

Create a test build to identify CSS rules that cross XBL anonymous content

Categories

(Core :: CSS Parsing and Computation, task, P3)

task

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Paolo, Unassigned)

References

Details

While this isn't required for the first part of the work in bug 1470830, a build that prints the file name and line number of all rules that cross XBL anonymous content will help with the second part, that is the conversion of current bindings. Some rules would apply to the anonymous content itself, for example: https://dxr.mozilla.org/mozilla-central/source/browser/themes/shared/customizableui/panelUI.inc.css#204 The most interesting case, however, is when a rule crosses the anonymous content using a child selector: https://dxr.mozilla.org/mozilla-central/source/browser/themes/shared/downloads/allDownloadsView.inc.css#20 There are also rules that do both, in different combinations: https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.css#624 Emilio, would it be possible to detect these cases, differentiated by which case they are, and with a file name and line number? I think the second case is the most relevant to the XBL conversions at this point, if we can't do both.
Flags: needinfo?(emilio)
So, to be clear, you want the set of document rules so that any of the combinators go through anonymous content to non-anoymous, or vice-versa, is that right? If so, yes, though I'm not sure how useful / worth it is to differentiate the cases. I can try to hack something up.
Flags: needinfo?(emilio) → needinfo?(paolo.mozmail)
(In reply to Emilio Cobos Álvarez [:emilio] from comment #1) > So, to be clear, you want the set of document rules so that any of the > combinators go through anonymous content to non-anoymous, or vice-versa, is > that right? Yes, if this includes rules where the selectors that are combined all target non-anonymous content, but the combinators actually cross anonymous content. > If so, yes, though I'm not sure how useful / worth it is to differentiate > the cases. I can try to hack something up. They are relevant for different types of conversions, so it may be worth differentiating. In particular, from the description in bug 1470830: - For bindings where we won't be using Shadow DOM and have <children>, we have to identify rules that cross the XBL anonymous boundaries with child selectors, and update them to keep the new DOM structure into account. - For bindings where we will be using Shadow DOM, we have to convert every rule that applies to the anonymous content so that it's loaded in the Shadow DOM scope. Note that descendant selectors crossing anonymous content are probably not an issue for us, although it's probably not an issue if these are listed also.
Flags: needinfo?(paolo.mozmail)
Priority: -- → P3
Even though we haven't yet migrated many bindings requiring the conversion of anonymous content to non-anonymous, we've handled some of those by looking manually for CSS rules that could be affected. Given this, we've decided to close this bug for now, and reopen if a special build becomes necessary to facilitate some of those conversions.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Blocks: war-on-xbl
(In reply to :Paolo Amadini from comment #3) > we've decided to close this bug for now, and reopen if a special build > becomes necessary to facilitate some of those conversions. I’ve set this to block bug 1397874 directly to make this easier to find if that case were to ever come to pass.
Type: enhancement → task
You need to log in before you can comment on or make changes to this bug.