NEW 13522
Saving a webarchive with a <script><noscript> will render images in both when opened again 
https://bugs.webkit.org/show_bug.cgi?id=13522
Summary Saving a webarchive with a <script><noscript> will render images in both when...
Mark Rowe (bdash)
Reported 2007-04-27 06:37:31 PDT
28/04/07 1:21 AM Sky Huvard: Summary: Saving a webarchive with a <script><noscript> will render images in both when opened again. Steps to Reproduce: Save a web archive with a <script><img></script><noscript><img (same)></noscript> Open the web archive and see both references to the image being rendered, the noscript one and the script one. Expected Results: Only one should be rendered Actual Results: Both are rendered <rdar://problem/5166344>
Attachments
Test case (144 bytes, text/html)
2007-04-27 10:19 PDT, David Kilzer (:ddkilzer) 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1 2007-04-27 06:38:45 PDT
Reporter confirmed via IRC that he has seen this with the latest nightly build (r21143) and in the released version of WebKit.
David Kilzer (:ddkilzer)
Comment 2 2007-04-27 10:19:55 PDT
Created attachment 14230 [details] Test case An <img> tag within <script></script> tags is not even valid, and content within <noscript></noscript> tags should only appear if JavaScript is turned off. Thus the webarchive should show zero images (assuming JavaScript is on), as the test case does when loaded. Hixie's live dom viewer is handy in this situation as well: http://software.hixie.ch/utilities/js/live-dom-viewer/
David Kilzer (:ddkilzer)
Comment 3 2007-04-27 10:23:32 PDT
(In reply to comment #2) > Created an attachment (id=14230) [edit] > Test case When I save a .webarchive of this test page, then view the source after opening it with Safari, I see the following HTML: <html><script> <img src="http://webkit.org/images/icon-gold.png"> </script><body><noscript></noscript> </body></html> Admittedly, the content in the <noscript></noscript> is NOT getting saved (and should be), but I can't reproduce the behavior the reporter is talking about. I also saved the webarchive and loaded the webarchive using a local debug build of WebKit r21145 with Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135). I haven't tried creating a webarchive with shippng Safari.
David Kilzer (:ddkilzer)
Comment 4 2007-04-27 10:27:13 PDT
(In reply to comment #3) > I haven't tried creating a webarchive with shippng Safari. Shipping Safari doesn't even save the <noscript></noscript> tags in its webarchive: <HTML><SCRIPT> <img src="http://webkit.org/images/icon-gold.png"> </SCRIPT><BODY></BODY></HTML> Need more information (good test case) to reproduce the issue.
Adam Barth
Comment 5 2010-08-19 15:15:13 PDT
The source of the WebArchive on trunk is as follows: <html><head><script> <img src="http://webkit.org/images/icon-gold.png"> </script> <noscript> &lt;img src="http://webkit.org/images/icon-gold.png"&gt; </noscript> </head><body></body></html> The entification of the contents of <noscript> seems wrong, but the description in Comment #0 no longer seems to be happening.
Alexey Proskuryakov
Comment 6 2012-05-17 10:02:18 PDT
This sounds much like bug 80170. Related Radar issues for Apple engineers: <rdar://problem/10972577>, <rdar://problem/10758026>. > The entification of the contents of <noscript> seems wrong I had a brief look at this a while ago. WebKit doesn't match HTML5, but the spec also seemed wrong in some respects. Anyway, we think that WebArchives are a special case, as they don't have to follow HTML serialization rules.
Brady Eidson
Comment 7 2012-05-17 10:41:28 PDT
(In reply to comment #6) > This sounds much like bug 80170. > > Related Radar issues for Apple engineers: <rdar://problem/10972577>, <rdar://problem/10758026>. > > > The entification of the contents of <noscript> seems wrong > > I had a brief look at this a while ago. WebKit doesn't match HTML5, but the spec also seemed wrong in some respects. Anyway, we think that WebArchives are a special case, as they don't have to follow HTML serialization rules. In deed. I even have a patch locally that simply and effectively does the right entification of noscript elements when serializing to a WebArchive, but that resulted in more of our favorite "double content when loading the archive" bug, which is why we went with stripping out noscripts altogether.
Note You need to log in before you can comment on or make changes to this bug.