Bug 204687 – CSS Rules with the same selector from several large stylesheets are applied in the wrong order

• Component: CSS
• Status: RESOLVED FIXED

[Anton Khlynovskiy]

Created attachment 384463 [details]
Error reproduction demo and a screenshot

In some cases rules with the same selector from the different stylesheets override each other in the wrong order.

It is reproduced with the large stylesheets (> 10000 rules, probably less) and is somehow related to the count of css rules in those stylesheets. Most noticeable the error is when the count of rules is near power of two.

The reproduction demo is attached to this issue, or can be accessed https://saf-rule-order.subzey.now.sh/dist/0x7fff/ or GitHub: https://github.com/subzey/saf-rule-order/tree/master/dist

There are 20 styleheets on a page. Each features a rule that sets the ::before contents on the body element. Other than these rules each sheet contains lots of other rules, so there are 32767 total (0x7FFF). The contents of these "dummy" rules doesn't matter, it can be even empty.

*Expected:*
Once all the selectors are the same, the rule from the last stylesheet should "win" and the body::before contents should be "Hello from 20.css".

*Actual Behavior:*
It says, "Hello from 09.css". The Inspector shows the order of rules application (see the attached screenshot) and it's totally random and does not reflect the DOM order of link elements.

This order is changed if the count of "dummy" rules is changed. https://saf-rule-order.subzey.now.sh/dist/0x8000/ 32768 rules yields "Hello from 16.css"

[Anton Khlynovskiy]

Created attachment 384468 [details]
Web Inspector Screenshot

[Radar WebKit Bug Importer]

<rdar://problem/57522566>

[Simon Fraser (smfr)]

CSS JIT bug?

[Antti Koivisto]

RuleData has

unsigned m_position : 18;

so if you have > 256k rules it will get confused about the order. The test consists of 32k rule sheets and fails as expected on 9th.

[Antti Koivisto]

There are some free bits here so we can increment the limit some.

[Antti Koivisto]

Created attachment 389643 [details]
patch

[Antti Koivisto]

Created attachment 389646 [details]
patch

[Andreas Kling]

Comment on attachment 389646 [details]
patch

r=me

[EWS]

Comment on attachment 389646 [details]
patch

Rejecting attachment 389646 [details] from review queue.

[e-mail] does not have reviewer permissions according to https://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/contributors.json.

- If you do not have reviewer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags.

- If you have reviewer rights please correct the error in Tools/Scripts/webkitpy/common/config/contributors.json by adding yourself to the file (no review needed).  The commit-queue restarts itself every 2 hours.  After restart the commit-queue will correctly respect your reviewer rights.

[Antti Koivisto]

sad face

[Andreas Kling]

(In reply to Antti Koivisto from comment #10)
> sad face

Sorry about that. I didn’t know I had been demoted. Patch looks good fwiw.

[alan]

Comment on attachment 389646 [details]
patch

trust kling.

[Antti Koivisto]

I did but the bot had doubts.

[WebKit Commit Bot]

Comment on attachment 389646 [details]
patch

Clearing flags on attachment: 389646

Committed r255671: <https://trac.webkit.org/changeset/255671>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.