Closed Bug 308592 Opened 19 years ago Closed 19 years ago

<map> before <body> causes <body> not to render.

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: moz, Assigned: mrbkap)

References

(
URL
)

Details

Attachments

(2 files, 1 obsolete file)

Testcase.
508 bytes, text/html
Details
And fixing the bogus check that showed this
4.51 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review 
Pretty self-explanitory. This only occurs if it's parsed as HTML and not XML/XHTML.
Attached file Testcase. — 
Body should have an orange background color and some text.
Oops; I left in some of the XHTML-only attributes/values from when I was
testing. That doesn't change the behavior, though.
Crash stack:
#0  0x07b16068 in SinkContext::~SinkContext (this=0x1c9e3600, __in_chrg=2) at
../../../../../../mozilla/content/html/document/src/nsHTMLContentSink.cpp:1023
#1  0x07b15fb8 in SinkContext::~SinkContext (this=0x1c9e3600) at
../../../../../../mozilla/content/html/document/src/nsHTMLContentSink.cpp:1018
#2  0x07b195b8 in HTMLContentSink::~HTMLContentSink (this=0x1c9da630,
__in_chrg=3) at
../../../../../../mozilla/content/html/document/src/nsHTMLContentSink.cpp:1928
#3  0x07b19180 in HTMLContentSink::~HTMLContentSink (this=0x1c9da630) at
../../../../../../mozilla/content/html/document/src/nsHTMLContentSink.cpp:1888
#4  0x079fd274 in nsContentSink::Release (this=0x1c9da630) at
../../../../../mozilla/content/base/src/nsContentSink.cpp:144
#5  0x07b19904 in HTMLContentSink::Release (this=0x1c9da630) at
../../../../../../mozilla/content/html/document/src/nsHTMLContentSink.cpp:1938
#6  0x07b1b5f0 in HTMLContentSink::EndContext (this=0x1c9da630, aPosition=18) at
../../../../../../mozilla/content/html/document/src/nsHTMLContentSink.cpp:2508
#7  0x18ce2ca0 in CNavDTD::HandleSavedTokens (this=0x1c9e2e90, anIndex=18) at
../../../../../mozilla/parser/htmlparser/src/CNavDTD.cpp:1920
#8  0x18cdfa30 in CNavDTD::HandleToken (this=0x1c9e2e90, aToken=0x2a07398,
aParser=0x1c9d9e20) at ../../../../../mozilla/parser/htmlparser/src/CNavDTD.cpp:726
#9  0x18cdeee8 in CNavDTD::BuildModel (this=0x1c9e2e90, aParser=0x1c9d9e20,
aTokenizer=0x1c9e3150, anObserver=0x0, aSink=0x1c9da680) at
../../../../../mozilla/parser/htmlparser/src/CNavDTD.cpp:459
#10 0x18cf4258 in nsParser::BuildModel (this=0x1c9d9e20) at
../../../../../mozilla/parser/htmlparser/src/nsParser.cpp:2005
#11 0x18cf3cbc in nsParser::ResumeParse (this=0x1c9d9e20, allowIteration=1,
aIsFinalChunk=0, aCanInterrupt=1) at
../../../../../mozilla/parser/htmlparser/src/nsParser.cpp:1872
#12 0x18cf5dac in nsParser::OnDataAvailable (this=0x1c9d9e20,
request=0x1c9dc200, aContext=0x0, pIStream=0x1c9b4770, sourceOffset=6482,
aLength=3758) at ../../../../../mozilla/parser/htmlparser/src/nsParser.cpp:2550
#13 0x16e924e0 in nsDocumentOpenInfo::OnDataAvailable (this=0x1c9dbf20,
request=0x1c9dc200, aCtxt=0x0, inStr=0x1c9b4770, sourceOffset=6482, count=3758)
at ../../../../mozilla/uriloader/base/nsURILoader.cpp:372
#14 0x0545c550 in nsStreamListenerTee::OnDataAvailable (this=0x1c9b3210,
request=0x1c9dc200, context=0x0, input=0x1c9db20c, offset=6482, count=3758) at
../../../../../mozilla/netwerk/base/src/nsStreamListenerTee.cpp:97
#15 0x054fc924 in nsHttpChannel::OnDataAvailable (this=0x1c9dc1d0,
request=0x1c9db0c0, ctxt=0x0, input=0x1c9db20c, offset=6482, count=3758) at
../../../../../../mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:4158
#16 0x05433bc4 in nsInputStreamPump::OnStateTransfer (this=0x1c9db0c0) at
../../../../../mozilla/netwerk/base/src/nsInputStreamPump.cpp:437
#17 0x05433618 in nsInputStreamPump::OnInputStreamReady (this=0x1c9db0c0,
stream=0x1c9db20c) at
../../../../../mozilla/netwerk/base/src/nsInputStreamPump.cpp:340
#18 0x01945f28 in nsInputStreamReadyEvent::EventHandler (plevent=0x1c9e7394) at
../../../../mozilla/xpcom/io/nsStreamUtils.cpp:119
#19 0x0188bab4 in PL_HandleEvent (self=0x1c9e7394) at
../../../../mozilla/xpcom/threads/plevent.c:693

I have a potential patch that removes eHTMLTag_map from gHtmlKids. It seems that
the old code would never have allowed this situation anyway (and we apparently
don't handle it very well!).
Assignee: parser → mrbkap
Severity: normal → critical
OS: MacOS X → All
Hardware: Macintosh → All
Attached patch Don't allow map in <html> (obsolete) — — Splinter Review 
I'm not sure if this fix is sufficient. I have a bunch of changes in my tree
that may or may not affect this, so I'll test and ask for review tomorrow.
Comments on this approach are welcome.
The bug doesn't happen in a 2005-09-09, so this is a regression from bug 272702,
right?
Fyi, IE6 is moving the map stuff in the <head>
Blocks: 272702
Status: NEW → ASSIGNED
Comment on attachment 196124 [details] [diff] [review]
Don't allow map in <html>

Yeah, this is sufficient to restore our old behavior (which put the stray
<map>s in the head).
Attachment #196124 - Flags: review?(jst)
(In reply to comment #7)
> Yeah, this is sufficient to restore our old behavior (which put the stray
> <map>s in the head).

s/head/body/


This is the best of all worlds, fixing the bogus |top != eHTMLTag_head| check
and not allowing <map> in <html>
Attachment #196124 - Attachment is obsolete: true
Attachment #196257 - Flags: review?(jst)
Comment on attachment 196257 [details] [diff] [review]
And fixing the bogus check that showed this

r+sr=jst
Attachment #196257 - Flags: superreview+
Attachment #196257 - Flags: review?(jst)
Attachment #196257 - Flags: review+
Attachment #196124 - Flags: review?(jst)
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: