Closed Bug 1281135 Opened 8 years ago Closed 5 years ago

"disabled=true" not working in link for stylesheet at initial load

Categories

(Core :: DOM: CSS Object Model, defect, P3)

47 Branch
x86_64
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox68 --- fixed

People

(Reporter: amnon.david, Assigned: emilio)

References

Details

(Keywords: dev-doc-complete, Whiteboard: [webcompat][wptsync upstream])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

<link id='rtl' rel="stylesheet" href="./mypath/mystyle.css" disabled="true">


Actual results:

mystyle.css affects the rendered page.


Expected results:

mystyle.css should have not have any effect on the rendered page. Changing the disabled property via DOM after the page loads fixes this, but it is a workaround and not the correct behaviour

Also explained here:
http://stackoverflow.com/questions/18237591/firefox-not-adhering-to-disabled-stylesheet
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Cameron, what do you think?
Flags: needinfo?(cam)
I guess it's a bug; Safari, Chrome and Edge all disable the style sheet when disabled="" is set in content.  The HTML spec seems to have lost the disabled attribute on <link> and <style> (filed https://github.com/whatwg/html/issues/1577), but I imagine it should work as the test case expects.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(cam)
Though https://github.com/whatwg/html/issues/1081 points out that Firefox doesn't support the disabled="" content attribute at all (just the IDL attribute).
Priority: -- → P3
Flags: webcompat?
Whiteboard: [webcompat]
Summary: "disabled=true" not working in link for stylesheet → "disabled=true" not working in link for stylesheet at initial load
Component: DOM: Core & HTML → DOM: CSS Object Model

WebKit / Blink behavior for <link rel="stylesheet" disabled> is a bit fishy, but I'll take a look.

Flags: needinfo?(emilio)

I proposed something in that HTML spec issue.

Assignee: nobody → emilio
Flags: needinfo?(emilio)

...instead of forwarding to the sheet like HTMLStyleElement does.

I've proposed this behavior in:

https://github.com/whatwg/html/issues/3840#issuecomment-480894419

I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.

Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.

That means that setAttribute does something different than setting disabled,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ef991fe893a4
Make <link disabled> work and HTMLLinkElement.disabled reflect that attribute. r=bzbarsky
Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/edbf9758ea94
Make <link disabled> work and HTMLLinkElement.disabled reflect that attribute. r=bzbarsky
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Pushed by emilio@crisal.io:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e0e8a1c9dc1d
followup: Address a review comment on a test.
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/16521 for changes under testing/web-platform/tests
Whiteboard: [webcompat] → [webcompat][wptsync upstream]

Documentation has been updated:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link

Changes include moving the disabled attribute from the obsolete properties section up into the main list, and updating the text to describe the behavior implemented by this spec change.

BCD data update has been submitted and is pending review:

https://github.com/mdn/browser-compat-data/pull/4323

Reviews appreciated; feel free to correct any errors yourself or point them out to me.

Thanks Eric, I did some edits (please review if you find some time as English is not my first language), and left a few comments in BCD regarding a misunderstanding between what the old and new behavior is :)

:emilio -- I am working on an update to the BCD patch which I will submit shortly. I have read your changes to the article and think I see what you're saying there. I did rewrite the text to be more specific on a couple of things (I think) and would appreciate it if you would read it again to be sure I didn't screw up my rewrite. Otherwise, I'll restore your original text and just make minor grammatical tweaks.

Thanks for jumping on the reviewing right away! I very much appreciate it!

Flags: needinfo?(emilio)

Commented there, thank you :)

Flags: needinfo?(emilio)
Regressions: 1567182
Regressions: 1678987
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: