Closed Bug 227028 Opened 21 years ago Closed 6 years ago

about:blank frankendocument needs a visit from the villagers

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: danm.moz, Unassigned)

References

(Blocks 2 open bugs)

Details

Mozilla makes the assumption that a window can always supply a fully-formed document. Our chosen scheme for dealing with this is to always be able to supply one. When asked, if the real document has not yet finished loading, we return a fake one with a face hastily sketched. This was bug 88229. There's no full accounting of all the problems this fixed. I do know this: with the Blank Frankendocument disabled, these things go wrong: Sometimes a new window or frame is initially drawn with the wrong background colour. Script, from the highly obvious document.write to the less obvious resizeTo, fails to execute. This is a problem in Mozilla proper, as well as in embedded applications (embedded apps were the reason for 88229). This also causes problems. It's surprising this works as well as it does. C'mon, when you asked for the document, you probably wanted the actual document. Issues that I know of: We must special-case about:blank. For example, event listeners must be brought to the next document (most recently, bug 226416). There may be other examples. (Session history, for one. Though about:blank must be special-cased for other reasons, as well.) As it's replaced by the real document, BFD fires an unload event during creation of a new window (bug 197709). There are instances of code that really just want the extant document, if any. Instead they may get the BFD. onLocationChange in nsBrowserStatusHandler.js is pretty clearly an example. (This is the code most likely to trigger creation of the BFD.) I'm not saying we have to fix this, but the current situation does seem like a weakness. This bug is either a "won't fix" posterchild or a future metabug to track the work necessary to find another solution.
Another problem this causes is that when you are looking at a document that has failed to load, if you go to View Source, you'll be told the source is "<html><body></body></html>" which is completely bogus.
QA Contact: general → ian
Blocks: 197709
Blocks: 236547
Product: Browser → Seamonkey
Product: SeaMonkey → Core
QA Contact: ian → general
Shouldn't this be closed?

This is specced behavior at this point...

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.