Closed
Bug 21005
Opened 25 years ago
Closed 25 years ago
Unclosed <TITLE> completely blocks painting of canvas
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
WONTFIX
M14
People
(Reporter: sidr, Assigned: rickg)
Details
(Whiteboard: [TESTCASE])
Attachments
(1 file)
(deleted),
text/html
|
Details |
* Overview:
If the <TITLE> element of a new document is not closed, the browser canvas
does not get painted with any of the content of the new document, and
becomes effectively transparent until another page is viewed.
* Steps to Reproduce:
1. View any HTML page in a Mozilla browser window (for convenience, this report)
2. View the attached simple testcase.
3. Switch to any other Window using ALT-TAB, the taskbar, or mousing.
4. Switch back to the Mozilla browser window.
* Actual Results:
A. The page viewed in step 1 remains visible in step 2, even though the
page viewed in step 2 loads, as can be seen in the title bar.
The entire document after the <TITLE> start-tag ends up in the title bar.
B. The canvas area of the Mozilla window shows whatever had most recently
been on top in step 4. Speculation: as of step 2, the contents of the
canvas area are undefined - no longer the previous document, but nothing
displayed for the new document either.
* Expected Results:
A. The canvas area should be blanked as soon as a Content-Type HTTP header
that Mozilla knows how to handle is parsed, in preparation for display
of the new document. So long as the <TITLE> element is unclosed in the
B. Mozilla should always re-paint the canvas when it becomes the topmost
window, and should always have *something* to paint there.
* Tested with:
1999-12-05-16-M12 nightly binary on Windows NT 4.0sp3.
* Additional Information:
This may actually be due to the HEAD not being closed, or the BODY
not existing, as a result of the unclosed TITLE...will investigate further.
It would be nice if the <TITLE> could be implicitly closed (if not already
explicity closed by the HTML source) when the <HEAD> is closed.
More importantly, I can see no reason not to start a new page visually
by blanking the canvas as soon as a response is received from an HTTP
(or any?) server that will presumably result in displayable content.
I have no idea who should own this part of the bug.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Whiteboard: [TESTCASE]
Reporter | ||
Comment 2•25 years ago
|
||
Testcase added as attachment, simple as possible:
<HTML>
<HEAD>
<TITLE>A TITLE with no proper end...>
</HEAD>
<BODY>
<P>Text</P>
</BODY>
</HTML>
With my debug build I'm hitting an assert in the debugger. Looks like the stack
maintained by the content sink is deleted.
Very likely parser and not content sink so starting with parser
operator delete(void * 0xdddddddd) line 47 + 3 bytes
SinkContext::~SinkContext() line 1014 + 18 bytes
SinkContext::`scalar deleting destructor'(unsigned int 1) + 15 bytes
HTMLContentSink::~HTMLContentSink() line 1946 + 28 bytes
HTMLContentSink::`scalar deleting destructor'(unsigned int 1) + 15 bytes
HTMLContentSink::Release(HTMLContentSink * const 0x01e17790) line 1972 + 134
bytes
CNavDTD::~CNavDTD() line 363 + 27 bytes
CNavDTD::`vector deleting destructor'(unsigned int 1) + 84 bytes
CNavDTD::Release(CNavDTD * const 0x01f2dfa0) line 216 + 134 bytes
CParserContext::~CParserContext() line 74 + 27 bytes
CParserContext::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsParser::~nsParser() line 232 + 31 bytes
nsParser::`vector deleting destructor'(unsigned int 1) + 84 bytes
nsParser::Release(nsParser * const 0x01ef5f30) line 237 + 134 bytes
nsCOMPtr<nsIStreamListener>::assign_assuming_AddRef(nsIStreamListener *
0x00000000) line 416
nsCOMPtr<nsIStreamListener>::assign_with_AddRef(nsISupports * 0x00000000) line
761
nsCOMPtr<nsIStreamListener>::operator=(nsIStreamListener * 0x00000000) line 516
nsDocumentBindInfo::OnStopRequest(nsDocumentBindInfo * const 0x01ec3398,
nsIChannel * 0x01ef4b88, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00000000) line 1496
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x01e2c178,
nsIChannel * 0x01ef4b88, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00000000) line 222
nsChannelListener::OnStopRequest(nsChannelListener * const 0x01ef4ab8,
nsIChannel * 0x01ef4b88, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00000000) line 1590
nsHTTPChannel::ResponseCompleted(nsIChannel * 0x01f02bc0, unsigned int 0, const
unsigned short * 0x00000000) line 817 + 50 bytes
nsHTTPResponseListener::OnStopRequest(nsHTTPResponseListener * const 0x01ca9f38,
nsIChannel * 0x01f02bc0, nsISupports * 0x01ef4b88, unsigned int 0, const
unsigned short * 0x00000000) line 263
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x01e500e0) line
279
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x01cb5618) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x01cb5618) line 522 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b3bb98) line 483 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0014008c, unsigned int 49437, unsigned int 0,
long 11778968) line 947 + 9 bytes
USER32! 77e135f8()
USER32! 77e13769()
USER32! 77e17b9a()
main(int 1, char * * 0x00a92c48) line 137 + 11 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e9bc52()
Reporter | ||
Comment 4•25 years ago
|
||
Presence or absence of ending </FONT> tag and/or beginning <BODY>
tag irrelevant to this bug - only the missing </TITLE> causes the bug.
Also tested unclosed <SCRIPT> and <STYLE> elements in the <HEAD>;
canvas paints and re-paints normally, although these do block
display of the <BODY> contents. Looks specific to <TITLE>.
Tested with:
1999-12-08-15-M12 nightly binary on Windows NT 4.0sp3
1999-12-08-08-M12 nightly binary on Windows NT 4.0sp3
I've fixed the crash, and have the change in my tree. I'll land it this weekend.
The fact that the page doesn't render is OK (it's what Nav does), and is the
result of the missing </title>. If I get energetic, I may add code to back up,
insert the missing tag myself, and reinitiate the parse phase. Maybe.
All the three browsers, Nav4.x, IE, and Gecko, behave almost identically. I
think it's not worth fixing.
Note: Per spec. </TITLE> is mandatory.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Marking won't fix since this is just *really bad* html, and we deal with it the
same way the other browsers do.
Reporter | ||
Comment 9•25 years ago
|
||
Sorry I didn't get around to splitting off the "It would be nice if the <TITLE>
could be implicitly closed..." bit earlier on ... I couldn't think of a really
good reason not to do fix up unclosed <TITLE> elements, but I couldn't think
of a reason good enough to justify the work, either, so it never did get split
off.
For the record, the serious part of the problem as reported, the part
that made the browser look dead, was FIXED ... the added bit, that won't be
fixed, was comparatively unimportant, and should have been in a distinct bug
report anyway. All of this was the result of a cut-and paste accident, which is
the only way this would ever happen in the wild, other than bad typing of raw
HTML. If Mozilla fixed that up for the user (closing the element), it would be
bad for the author (testing the page, looking for mistakes), so it's just as
well that that won't be done.
You need to log in
before you can comment on or make changes to this bug.
Description
•