Closed
Bug 57717
Opened 24 years ago
Closed 21 years ago
view-source on blank page shows <html><body></body></html>
Categories
(Core :: DOM: HTML Parser, defect, P4)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: jruderman, Assigned: mrbkap)
References
()
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Mozilla will inappropriately display <html><body></body></html> in view-source
for blank html pages. CC Ian, who mentioned this when reporting bug 51844.
Happens at:
- about:blank
- javascript:""
- empty local file
Doesn't happen at:
- data:text/html, (why not?)
Not a show stopper. Setting to FUTURE.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Suggested behavior:
Disable view-source on pages that have not loaded yet or contain no data.
Comment 5•24 years ago
|
||
In which case, this bug would be a dup of bug 63047. However, that wouldn't
stop me from typing `view-source:about:blank' or whatever into the address
field.
Comment 6•24 years ago
|
||
*** This bug has been marked as a duplicate of 57724 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 7•23 years ago
|
||
Reopening 57724 dependencies for independent resolution.
Comment 9•23 years ago
|
||
Well, now... about:blank is in fact _not_ empty. It has source. Anyone typing
crap like "view-source:about:blank" into the URL bar deserves what he gets,
imo. I say this is bug 63047.
Comment 10•23 years ago
|
||
No, it's not. This bug is also about 0-byte .html local files. Bug 63047 is only
relevant for about:blank.
Comment 11•22 years ago
|
||
I just tested a zero-byte file, and source shows nothing.
boris is right about the about:blank situation.
That leaves javascript, which I don't pretend to understand.
I suggest checking that, and either way WFM. If javascript is a problem, send it
to a new bug.
Comment 12•22 years ago
|
||
The JS engine basically generates the equivalent of the about:blank document for
'javascript:""'. We show the source correctly.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → WORKSFORME
Comment 13•22 years ago
|
||
Build 2002090804, Win2k.
1) Open testcase (which I am about to attach).
2) View source.
Expected results: ""
Actual results: "<html><body></body></html"
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 14•22 years ago
|
||
Doh. Can't attach it. Bugzilla says "The file you are trying to attach is
empty!". Bug 167703 filed on that.
Zero byte file served as text/html: http://jonasj.dk/moztests/zerobytes.html
Zero byte file served as text/plain: http://jonasj.dk/moztests/zerobytes.txt
View source on the text/html one displays "<html><body></body></html>"; the
text/plain one works correctly.
Updated•22 years ago
|
Assignee | ||
Comment 15•21 years ago
|
||
I think the problem here is that the parser does not like necko's method of
handling empty inputs. The actual (code) cause of the problem is in
nsParser.cpp, line 2450. Apparently, necko finds that it's at the end of the
document, and calls nsParser::OnStopRequest instead of
nsParser::OnDataAvailable. For some reason (that isn't completely clear in the
comments), the parser constructs a dummy web page (<html><body></body></html) to
give to the scanner (note that the parser does something similar with text
files, however, it simply inserts a space instead, so nothing shows up in view
source).
If the reason that the parser constructs this dummy web page is bug 108067 (as
is indicated by the comment on the following line), then that bug should block
this one, and we should remove these two hacks entirely when it is fixed.
Otherwise, I wonder if we should simply insert a space no matter what -
everything (layout, other DTDs, view source, etc.) else can handle an "empty"
html document (in fact, CNavDTD has checks for exactly this in BuildModel) and
this bug will disappear.
Comment 16•21 years ago
|
||
Bug 108067 definitely blocks this one, for now. Blake, if can figure out which
patches there are checked in and which are not and update the ones that need
landing to a current tree, we can get them reviewed and landed (ask peterv or me
for reviews).
Once that's done, we should look into this bug. There's a bunch of stuff that
will need testing (eg whether composer still works, whether document.body exists
in empty frames, etc), but I think most of those use about:blank so it should be
OK. I suspect the parser doesn't construct the dummy page because of bug 108067
but rather due to backwards compat of some sort.... What does IE do when given a
blank HTML document? What sort of DOM does it construct?
Depends on: 108067
Assignee | ||
Comment 17•21 years ago
|
||
Some answers: because CNavDTD automatically creates a <html> element (the very
first thing it does in BuildModel) all documents will have a 'body' element (as
in document.body). This is done by the DOM.
If I view-source a blank page in IE (html or text, doesn't matter) - IE
generates an empty page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD>
<BODY></BODY></HTML>
As a note - view source of about:blank in IE returns <html></html>, so I'm not
sure we should/need to follow its example in this case, especially because that
wasn't the source of the original document.
Comment 18•21 years ago
|
||
Blake, where does the DOM ensure a body? Just opening an <html> wouldn't open
one, will it? It can't since you can have frameset documents....
Good to know that IE's behavior is wacky enough that we don't have to worry
about it much....
Assignee | ||
Comment 19•21 years ago
|
||
I don't really understand it, but the impression that I got from doron over IRC
is that after the document is parsed the DOM generates a body if it has to (even
if there isn't an implicit one). From my testing, for an empty document
(completely empty), document.body returns an object of type HTMLBodyElement, and
for a document with frames, document.body returns an object of type
HTMLFrameSetElement.
Assignee | ||
Comment 20•21 years ago
|
||
I'm not quite sure how to test this patch, but here it is. It fixes this bug by
removing the hacks in the parser. bz, from the DOM inspector, I see that we
still generate a body in the DOM. As a note: in debug builds, with and without
this patch, javascript:"" generates an NS_WARNING in nsDocumentViewer.cpp. What
else do I need to check?
Comment 21•21 years ago
|
||
Attachment #150636 -
Attachment is obsolete: true
Updated•21 years ago
|
Assignee: harishd → mrbkap
Status: REOPENED → NEW
Comment 22•21 years ago
|
||
Comment on attachment 150636 [details] [diff] [review]
remove the generated stuff
Looks good.
Attachment #150636 -
Flags: superreview+
Attachment #150636 -
Flags: review+
Comment 23•21 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•