| Summary: | <style> inside <noscript> is parsed when JavaScript is enabled. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | johanneslindenbaum | ||||
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | abarth, ap, commit-queue, eric, hohle, webkit.review.bot | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Mac (Intel) | ||||||
| OS: | OS X 10.6 | ||||||
| Attachments: |
|
||||||
In all likelihood this is fixed on trunk. Testing now. *** Bug 28195 has been marked as a duplicate of this bug. *** Created attachment 64668 [details]
Patch
Comment on attachment 64668 [details] Patch Thanks! It's a little surprising to see noscript without script, and maybe we should be also testing the more common case where they come together, but I don't think there is a strong technical reason to. I'm a little confused by your comment in bug 28195 - is 13522 the same, after all? > Thanks! It's a little surprising to see noscript without script, and maybe we should be also testing the more common case where they come together, but I don't think there is a strong technical reason to. Huh? I don't understand this comment. Why would script and noscript come together? > I'm a little confused by your comment in bug 28195 - is 13522 the same, after all? I haven't looked at Bug 13522 yet. Bug 28195 is the same bug as this one. The old parser didn't understand how to properly lex <noscript>. The new parser lexs it as RAWTEXT and then makes it not display. > Huh? I don't understand this comment. Why would script and noscript come together?
They usually did on Web pages (and sample code) where I saw <noscript>, with it logically being fallback for scripted behavior. Of course, they are not technically related, which is why I said there was no strong reason to test that case.
Comment on attachment 64668 [details] Patch Clearing flags on attachment: 64668 Committed r65712: <http://trac.webkit.org/changeset/65712> All reviewed patches have been landed. Closing bug. http://trac.webkit.org/changeset/65712 might have broken SnowLeopard Intel Release (Tests) The following changes are on the blame list: http://trac.webkit.org/changeset/65699 http://trac.webkit.org/changeset/65700 http://trac.webkit.org/changeset/65701 http://trac.webkit.org/changeset/65702 http://trac.webkit.org/changeset/65703 http://trac.webkit.org/changeset/65704 http://trac.webkit.org/changeset/65705 http://trac.webkit.org/changeset/65706 http://trac.webkit.org/changeset/65707 http://trac.webkit.org/changeset/65708 http://trac.webkit.org/changeset/65709 http://trac.webkit.org/changeset/65710 http://trac.webkit.org/changeset/65711 http://trac.webkit.org/changeset/65712 http://trac.webkit.org/changeset/65713 |
Summary: When adding <style> definitions inside of a <noscript> tag the style declarations are applied even when JavaScript is enabled. Steps to Reproduce: <noscript> <style type="text/css"> #myId { display: none; } </style> </noscript> Expected Results: Style declarations inside of no script, attempting to gracefully degrade a form, should not be parsed. When JavaScript is in enabled #myDiv should remain visible, where during a disabled JavaScript page load the element should not be displayed. Actual Results: Style definitions are applied when JavaScript is enabled. Firefox 3.6.8 correctly ignores <style> in <noscript> IE 8 (Win 7) correctly ignores <style> in <noscript> Chrome 5.0.375.99 parses <style> in <noscript> Safari 5.0.1 (6533.17.8) parses <style> in <noscript>