WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
44021
<style> inside <noscript> is parsed when JavaScript is enabled.
https://bugs.webkit.org/show_bug.cgi?id=44021
Summary
<style> inside <noscript> is parsed when JavaScript is enabled.
johanneslindenbaum
Reported
2010-08-14 22:52:18 PDT
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>
Attachments
Patch
(2.75 KB, patch)
2010-08-17 21:38 PDT
,
Adam Barth
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Adam Barth
Comment 1
2010-08-17 21:29:48 PDT
In all likelihood this is fixed on trunk. Testing now.
Adam Barth
Comment 2
2010-08-17 21:36:48 PDT
***
Bug 28195
has been marked as a duplicate of this bug. ***
Adam Barth
Comment 3
2010-08-17 21:38:18 PDT
Created
attachment 64668
[details]
Patch
Alexey Proskuryakov
Comment 4
2010-08-19 14:30:55 PDT
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?
Adam Barth
Comment 5
2010-08-19 14:36:30 PDT
> 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.
Alexey Proskuryakov
Comment 6
2010-08-19 15:12:26 PDT
> 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.
WebKit Commit Bot
Comment 7
2010-08-19 15:35:52 PDT
Comment on
attachment 64668
[details]
Patch Clearing flags on attachment: 64668 Committed
r65712
: <
http://trac.webkit.org/changeset/65712
>
WebKit Commit Bot
Comment 8
2010-08-19 15:35:58 PDT
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 9
2010-08-19 16:44:58 PDT
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
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug