View-Source buffer corrupted with nested script tags
Reported by
stefano....@gmail.com,
Feb 16 2017
|
||||||||
Issue descriptionSteps to reproduce the problem: 1. Save minimal.html 2. view-source:file:///tmp/minimal.html 3. Notice that there's a stray "</script" in the middle of one of the lines. This isn't present in the source. What is the expected behavior? We expect Chrome to accurately show the source it received. What went wrong? This example (invalid) markup causes chrome to corrupt later data in view-source: <script type="text/javascript"> "<!-- --!><script>"; It needs a largish chunk of data after that, to start corrupting it with stray </script tags. This lead to much torn hair when trying to understand where these stray tags were coming from. Did this work before? N/A Chrome version: 55.0.2883.75 Channel: n/a OS Version: Debian 9.0 (64-bit) Flash Version: Seen in Chrome 56.0.2924.87 on OSX, too.
,
Feb 17 2017
Looks similar to issue 622291 .
,
Feb 17 2017
It looks like the uncorrupted source shows up correctly in DevTools' sources panel. Changing component labels.
,
Feb 17 2017
Weird! Agreed that it's likely the same cause as issue 622291 . tkent@: Can you help triage or find an owner for this? (Feel free to mark this as a dupe if that sounds right, but it'd be good to find a resolution.) FWIW, I'm only familiar with the process model aspect of view-source, which is that we put the renderer into a special view-source mode and then just load the URL without the view-source prefix. This bug sounds like it's in the parser.
,
Feb 19 2017
,
Feb 27 2017
I uploaded the patch for this problem and under review. https://codereview.chromium.org/2717303002/
,
Mar 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f commit e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f Author: wanchang.ryu <wanchang.ryu@lge.com> Date: Wed Mar 08 11:00:19 2017 Considering HTMLTokenizer state in HTMLSourceTracker HTMLSourceTracker takes account of HTMLTokenizer's temporary buffor when tracking source location of token. But in some of ScriptDataXXX states, characters are already pushed as token's characters so in that cases we don't need to consider temporary buffer of tokenizer. BUG= 692910 TEST=fast/frames/viewsource/* Review-Url: https://codereview.chromium.org/2717303002 Cr-Commit-Position: refs/heads/master@{#455427} [modify] https://crrev.com/e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f/AUTHORS [add] https://crrev.com/e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f/third_party/WebKit/LayoutTests/fast/frames/viewsource/viewsource-9-expected.txt [add] https://crrev.com/e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f/third_party/WebKit/LayoutTests/fast/frames/viewsource/viewsource-9.html [modify] https://crrev.com/e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f/third_party/WebKit/Source/core/html/parser/HTMLSourceTracker.cpp [modify] https://crrev.com/e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f/third_party/WebKit/Source/core/html/parser/HTMLSourceTracker.h [modify] https://crrev.com/e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f/third_party/WebKit/Source/core/html/parser/HTMLTokenizer.cpp [modify] https://crrev.com/e39d4d6f3fb1b4d558bd2d2eca1d603bec1c588f/third_party/WebKit/Source/core/html/parser/HTMLTokenizer.h
,
May 2 2017
Is this change fixed with wanchang.ryu's CL?
,
May 2 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 7 2018
,
May 21 2018
This was probably fixed by #7, and doesn't repro as of 68.0.3434.0. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by tansell@chromium.org
, Feb 16 2017Status: Untriaged (was: Unconfirmed)