Bug 156849
| Summary: | Parsing of <body link vlink alink> is not per spec | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Pieters (:zcorpan) <zcorpan> |
| Component: | DOM | Assignee: | Ryosuke Niwa <rniwa> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | ahmad.saleem792, ap, bfulgham, obzhirov, rniwa, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=61697 | ||
Simon Pieters (:zcorpan)
(Same issue for Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=605534 )
https://github.com/WebKit/webkit/blob/66e68cd8d7bf4ea1cf52f31ed9cb242f83ea5b57/Source/WebCore/html/HTMLBodyElement.cpp#L159
This code does not match the requirements in the HTML spec:
[[
When a body element has a bgcolor attribute set, the new value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the element's 'background-color' property to the resulting colour.
When a body element has a text attribute, its value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the element's 'color' property to the resulting colour.
When a body element has a link attribute, its value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the 'color' property of any element in the Document matching the :link pseudo-class to the resulting colour.
When a body element has a vlink attribute, its value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the 'color' property of any element in the Document matching the :visited pseudo-class to the resulting colour.
When a body element has an alink attribute, its value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the 'color' property of any element in the Document matching the :active pseudo-class and either the :link pseudo-class or the :visited pseudo-class to the resulting colour.
]]
https://html.spec.whatwg.org/multipage/rendering.html#the-page
It seems we use the correct rules for bgcolor (on various elements, and <font color>, <table bordercolor>, <hr color>) and text but not the link/vlink/alink attributes on body. This should also not be conditional on quirks mode. Gecko matches the spec AFAICT.
Simple tests:
<!doctype html>
<body bgcolor="00ff0x">This should have a green background.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4091 bgcolor
---
<!doctype html>
<body link="00800x"><a href=javascript:>This text should be green.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4092 link (standards mode)
---
<!doctype html>
<body link="00800x"><a href=javascript:>This text should be green.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4093 link (quirks mode)
---
<body link="008000"><a href=javascript:>This text should be green.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4094 link (quirks mode, using a value we successfully parse today)
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Anton Obzhirov
I am fixing it for chromium (https://codereview.chromium.org/1921823006/) - will port the fix here as well.
Ahmad Saleem
I am still able to reproduce this bug in Safari 15.6 on macOS 12.5 from following test cases:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4092
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4093
Further, this has been fixed in Chrome in following commit:
https://chromium.googlesource.com/chromium/src.git/+/ac6c480c0c078999a785de7ef1e10c6c0c928c75
I think this might be linked to bug 61697?
Ryosuke Niwa
Pull request: https://github.com/WebKit/WebKit/pull/2883
EWS
Committed 252992@main (c521422a249b): <https://commits.webkit.org/252992@main>
Reviewed commits have been landed. Closing PR #2883 and removing active labels.
Radar WebKit Bug Importer
<rdar://problem/97886718>