Bug 14979 – REGRESSION: fast/css/css-selector-text.html failing after r25098

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: DOM

fast/css/css-selector-text.html is failing on the build bot (and on my local build) after <http://trac.webkit.org/projects/webkit/changeset/25098>. It was also failing after the previous incarnation of that change.

[Beth Dakin]

The problem is in this function:

function parseThenSerializeRule(rule)
{
    var styleElement = document.createElement("style");
    styleElement.appendChild(document.createTextNode(rule));
    return styleElement.sheet.cssRules[0].cssText;
}

with my patch, styleElement.sheet.cssRules[0] is null.

[Beth Dakin]

This is failing because the style element is not in the document, so we do not create the sheet.

[Beth Dakin]

The test may have to change. It does not pass in Firefox for what appears to be the same reason. 

Firefox is consistent: it always returns null for the 'sheet' property of a <style> element that is not in the document. TOT WebKit always returns a CSSStyleSheet, and the stylesheet will contain no rules if the <style> element has never been inserted into the document; but if it has been inserted at some point, the rules will persist even after it has been removed, so there is no consistent "not in document" behavior.

Created attachment 15993 [details]
Test case

In this test case, the rule that's added using insertRule() is knocked out and replaced with the rule in the text node when the <style> element is removed and re-inserted into the document. I think if you are going to match Firefox, it will be better not to allow something like that to happen (e.g. by also returning null for the 'sheet' property when not in a document). I don't think the Firefox behavior makes sense (or follows the specification), though.

[Beth Dakin]

cc-ing Hyatt. I am interested to know his thoughts on this.

[Dave Hyatt]

I don't think this is worth fixing for Leopard, even though it is inconsistent.  Both link element and style element need to null out their sheet stuff in their removedFromDocument methods.

In the case of <link>, we should get rid of the process() call in removedFromDocument() because it is a no-op, and we should move the code from the destructor into removedFromDocument.  We should also null out m_sheet.

In the case of <style>, we should add the code that is in createSheet near the top that nulls out m_sheet and calls removePendingSheet if the sheet was loading.  updateStyleSelector should still be called.

[Beth Dakin]

I changed the test with r25111 to get it passing. 

(In reply to comment #7)
> Both link element and style element need to null out their sheet stuff in
> their removedFromDocument methods.

Why is that? Because of <http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/stylesheets.html#StyleSheets-extensions> ? It seems odd that if you remove and re-insert a <style> element it will be re-parsed and you will lose any dynamic changes you've made to it.

[David Kilzer (:ddkilzer)]

<rdar://problem/5925718>

[Ahmad Saleem]

I am unable to reproduce this bug in Safari 15.6 on macOS 12.5 and does not get expected result of "green" and "solid border". It is same across all browsers (Chrome Canary 106 and Firefox Nightly 105).

Since all browsers are rendering this test case same, I am going to mark this as "RESOLVED CONFIGURATION CHANGED". Please reopen, if you think test case need to be tweak and my testing is not applicable. Thanks!