If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

about:blank frankendocument needs a visit from the villagers

NEW
Unassigned

Status

()

Core
General
14 years ago
8 years ago

People

(Reporter: Dan M, Unassigned)

Tracking

(Blocks: 2 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
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
(Reporter)

Updated

14 years ago
Blocks: 236547
Product: Browser → Seamonkey
Component: General → General
Product: SeaMonkey → Core
QA Contact: ian → general
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 4

8 years ago
Shouldn't this be closed?
You need to log in before you can comment on or make changes to this bug.