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)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: sidr, Assigned: rickg)

Details

(Whiteboard: [TESTCASE])

Attachments

(1 file)

HTML doc with unclosed TITLE displays in title bar
108 bytes, 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.
Whiteboard: [TESTCASE]
Testcase added as attachment, simple as possible: <HTML> <HEAD> <TITLE>A TITLE with no proper end...> </HEAD> <BODY> <P>Text</P> </BODY> </HTML>
Assignee: troy → rickg
Component: Layout → Parser
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()
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
Status: NEW → ASSIGNED
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.
Target Milestone: M14
setting target milestone.
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.
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.
Marking verified won't fix per last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: