Closed Bug 57717 Opened 24 years ago Closed 20 years ago

view-source on blank page shows <html><body></body></html>

Categories

(Core :: DOM: HTML Parser, defect, P4)

defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: jruderman, Assigned: mrbkap)

References

()

Details

Attachments

(1 file, 1 obsolete file)

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?)
Blocks: 57724
OS: Windows 98 → All
Hardware: PC → All
Not a show stopper. Setting to FUTURE.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
QA Contact: janc → bsharma
updated qa contact.
*** Bug 71635 has been marked as a duplicate of this bug. ***
Suggested behavior:

Disable view-source on pages that have not loaded yet or contain no data.
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.
No longer blocks: 57724

*** This bug has been marked as a duplicate of 57724 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
QA Contact: bsharma → moied
Reopening 57724 dependencies for independent resolution.
Status: RESOLVED → REOPENED
Depends on: 57724
Resolution: DUPLICATE → ---
adjustments...
Severity: major → trivial
Priority: P3 → P4
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.
No, it's not. This bug is also about 0-byte .html local files. Bug 63047 is only
relevant for about:blank.
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.
The JS engine basically generates the equivalent of the about:blank document for
'javascript:""'.  We show the source correctly.
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → WORKSFORME
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 → ---
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.
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.
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
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. 
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....
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.
Attached patch remove the generated stuff (obsolete) — Splinter Review
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?
Assignee: harishd → mrbkap
Status: REOPENED → NEW
Comment on attachment 150636 [details] [diff] [review]
remove the generated stuff

Looks good.
Attachment #150636 - Flags: superreview+
Attachment #150636 - Flags: review+
Checked in.
Status: NEW → RESOLVED
Closed: 22 years ago20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: