Rule with too many selectors causes unrelated elements to be matched
Reported by
tim.ca...@algolia.com,
Mar 23 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. Go to https://jsfiddle.net/naskqpp1/ 2. All `label` in the display contains the word "OK" (only the first one should have it) 3. Remove the last selector (`.try_removing_me`) 4. Suddenly only the first `label` correctly have the content What is the expected behavior? No matter how many selectors are in my rule, only the first `label` should have its `:after` content set. What went wrong? Here, I have a very long number of selectors on a unique rule. Many selectors are duplicated, but the first one is unique and should add content to the first `label` placed after the `input`. Weirdly, it seems to add the content to all labels and not only the first one. If I remove *any* selector from the list, then the content is correctly added only to the first label. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.87 Channel: stable OS Version: 16.04 Flash Version: It seems that after a certain number of selectors in a rule, Chrome has trouble parsing the rule. I had a similar issue (with simpler selectors) here: https://github.com/jakubpawlowicz/clean-css/issues/916. My initial testing found the limit at around 8191, but it seems that this number is dependent on the complexity of the selectors. I did not find any way to reduce my test case any further. I tried with other, simpler, selectors, but could not reproduce the bug. I can't reproduce the bug on Firefox.
,
Mar 24 2017
,
Mar 24 2017
,
Mar 24 2017
Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.3 with chrome #55.0.2883.87, canary #59.0.3048.0 and also in earlier version #49.0.2623.0. This is a non-regression issue Attaching a screencast for reference. Note: ----- In below M49 builds, the output text is not displayed. Thank You...
,
Mar 30 2017
Same as issue 312913 , only now we got 8194 simple selectors in one StyleRule which is excessive.
,
Mar 30 2017
The relevant bitfield: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/RuleSet.h?l=114
,
Mar 30 2017
,
Apr 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bf40056461d01f9e704f7608c5684663ded95abc commit bf40056461d01f9e704f7608c5684663ded95abc Author: rune <rune@opera.com> Date: Mon Apr 03 09:05:47 2017 Added available bit to m_selectorIndex. Increased the max number of simple selectors for one style from 8192 to 16384 by moving one bit to the second 32-bit part to make space for another bit. There is one bit left, but it cannot be utilized since the bit field cannot span two 32 bit values. This doesn't really fix the issue since it's not unlikely someone will use more than 16000 selectors if they use more than 8000 selectors. R=meade@chromium.org BUG= 704562 Review-Url: https://codereview.chromium.org/2785103004 Cr-Commit-Position: refs/heads/master@{#461389} [delete] https://crrev.com/330bfd236aa4574a1ee370d4b369e755c6fe034d/third_party/WebKit/LayoutTests/fast/css/selector-list-limits.html [modify] https://crrev.com/bf40056461d01f9e704f7608c5684663ded95abc/third_party/WebKit/Source/core/css/RuleSet.cpp [modify] https://crrev.com/bf40056461d01f9e704f7608c5684663ded95abc/third_party/WebKit/Source/core/css/RuleSet.h [modify] https://crrev.com/bf40056461d01f9e704f7608c5684663ded95abc/third_party/WebKit/Source/core/css/RuleSetTest.cpp
,
Apr 4 2017
What's the limit in other browsers? Historically we WontFix'ed this because having more than 8192 joined selectors is super unusual and not something we intended to encourage.
,
Apr 4 2017
Works with 2^25 simple type selectors in Gecko, not 2^26.
,
Apr 4 2017
I haven't looked at the code, but given that the number of bits in Gecko also looks like it's been picked given available bits in a bitfield, I think we should just wontfix.
,
Apr 4 2017
Should we keep this raised limit? I wonder if it's encouraging bad practices, and folks will just increase until they hit 16384 and ask for more. Maybe we should revert that change?
,
Apr 5 2017
> Maybe we should revert that change? Probably. If we need more bits for other things in RuleData, and reduce the limit later, it will show up as a regression.
,
Apr 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6a550e547934bfce597bab1d52bf89a3ae18d1df commit 6a550e547934bfce597bab1d52bf89a3ae18d1df Author: rune <rune@opera.com> Date: Wed Apr 05 09:17:03 2017 Revert increased limit for m_selectorIndex. If 2^13 simple selectors in a style rule was not enough, 2^14 will be exceeded at some point. Leave the available bit for later use and avoid regressions for m_selectorIndex when we need that bit. R=esprehn@chromium.org BUG= 704562 Review-Url: https://codereview.chromium.org/2797953002 Cr-Commit-Position: refs/heads/master@{#462015} [modify] https://crrev.com/6a550e547934bfce597bab1d52bf89a3ae18d1df/third_party/WebKit/Source/core/css/RuleSet.cpp [modify] https://crrev.com/6a550e547934bfce597bab1d52bf89a3ae18d1df/third_party/WebKit/Source/core/css/RuleSet.h [modify] https://crrev.com/6a550e547934bfce597bab1d52bf89a3ae18d1df/third_party/WebKit/Source/core/css/RuleSetTest.cpp |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by alancutter@chromium.org
, Mar 24 2017Status: Available (was: Unconfirmed)