Summary: | View source mode is missing the processing instruction line. | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Anyang Ren <anyang.ren> | ||||||||
Component: | Web Inspector (Deprecated) | Assignee: | Elliott Sprehn <esprehn> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | ap, esprehn, hyatt, webkit.review.bot | ||||||||
Priority: | P2 | Keywords: | HasReduction, InRadar | ||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | All | ||||||||||
OS: | All | ||||||||||
Attachments: |
|
Description
Anyang Ren
2007-11-12 16:11:01 PST
Created attachment 17217 [details]
Preliminary patch for discussion
This patch is intended to show where the problem is, even though
it is in the form of a fix. I hope that the WebKit team can come up
with a better fix.
In HTMLTokenizer::write, after the call to parseProcessingInstruction
returns, we continue the while loop. So we skip the processToken call
at the end of the switch statement, and the line is not added to the
HTMLViewSourceDocument by the addViewSourceToken call in
HTMLTokenizer::processToken.
I first tried removing the "continue" statement so that we fall through to
the processToken call after the switch statement. But the parseTag call
after the processToken call caused an empty "<>" tag to be added after
the processing instruction line. So I'm now calling processToken before
the continue statement.
The other changes in this patch add the characters of the processing
instruction line to 'buffer' (via the 'dest' pointer) so that they show up
in the output. It is also necessary to remove the state.setDiscardLF(true)
statement so that we don't lose the LF after the processing instruction line
in the output.
Note that I mark the processing instruction line as a textAtom simply because
it is easier to work with HTMLTokenizer::processToken and
HTMLViewSourceDocument::addViewSourceToken to output a textAtom.
I believe the processing instruction line should be handled as a tag.
David, I'd appreciate your comments on this view source mode bug and the right way to fix it. Thanks. Viewing the source of http://alioth.debian.org/ from Safari 3 Public Beta with a local debug build of WebKit r27716 on Tiger shows the <?xml...> tag for me. Which Safari/WebKit are you seeing this on? Please set the "review?" flag if you want the patch reviewed for comments. Comment on attachment 17217 [details] Preliminary patch for discussion I'm using WebKit/WebCore/html/HTMLTokenizer.cpp, r25754. I'm not using Safari. Safari's "View Source" command doesn't seem to be implemented using the "view source mode" of the HTMLTokenizer class. (In reply to comment #3) > Viewing the source of http://alioth.debian.org/ from Safari 3 Public Beta with > a local debug build of WebKit r27716 on Tiger shows the <?xml...> tag for me. You can confirm this bug using the Source view in the Web Inspector. Comment on attachment 17217 [details]
Preliminary patch for discussion
I'm not 100% sure if this change is right, it seems generally ok.
However, it needs a ChangeLog and a layout test. You can force view source mode by putting the relevant contents into an <iframe> element with the viewsource attribute set.
r- for lack of test case and ChangeLog.
Created attachment 18449 [details]
test case
Here is a test case which I believe demonstrates the bug.
This is actually fixed, probably by the HTML5 parser rewrite. We should just add a layout test and close this bug. (Note the patch here is impossible to apply as well since HTMLTokenizer has been entirely rewritten.) Created attachment 181046 [details]
Patch
Comment on attachment 181046 [details] Patch Clearing flags on attachment: 181046 Committed r138637: <http://trac.webkit.org/changeset/138637> All reviewed patches have been landed. Closing bug. |