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




14 years ago
14 years ago


(Reporter: moz, Assigned: mrbkap)



Firefox Tracking Flags

(Not tracked)




(2 attachments, 1 obsolete attachment)



14 years ago
Pretty self-explanitory. This only occurs if it's parsed as HTML and not XML/XHTML.

Comment 1

14 years ago
Created attachment 196111 [details]

Body should have an orange background color and some text.

Comment 2

14 years ago
Oops; I left in some of the XHTML-only attributes/values from when I was
testing. That doesn't change the behavior, though.

Comment 3

14 years ago
Crash stack:
#0  0x07b16068 in SinkContext::~SinkContext (this=0x1c9e3600, __in_chrg=2) at
#1  0x07b15fb8 in SinkContext::~SinkContext (this=0x1c9e3600) at
#2  0x07b195b8 in HTMLContentSink::~HTMLContentSink (this=0x1c9da630,
__in_chrg=3) at
#3  0x07b19180 in HTMLContentSink::~HTMLContentSink (this=0x1c9da630) at
#4  0x079fd274 in nsContentSink::Release (this=0x1c9da630) at
#5  0x07b19904 in HTMLContentSink::Release (this=0x1c9da630) at
#6  0x07b1b5f0 in HTMLContentSink::EndContext (this=0x1c9da630, aPosition=18) at
#7  0x18ce2ca0 in CNavDTD::HandleSavedTokens (this=0x1c9e2e90, anIndex=18) at
#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
#10 0x18cf4258 in nsParser::BuildModel (this=0x1c9d9e20) at
#11 0x18cf3cbc in nsParser::ResumeParse (this=0x1c9d9e20, allowIteration=1,
aIsFinalChunk=0, aCanInterrupt=1) at
#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
#15 0x054fc924 in nsHttpChannel::OnDataAvailable (this=0x1c9dc1d0,
request=0x1c9db0c0, ctxt=0x0, input=0x1c9db20c, offset=6482, count=3758) at
#16 0x05433bc4 in nsInputStreamPump::OnStateTransfer (this=0x1c9db0c0) at
#17 0x05433618 in nsInputStreamPump::OnInputStreamReady (this=0x1c9db0c0,
stream=0x1c9db20c) at
#18 0x01945f28 in nsInputStreamReadyEvent::EventHandler (plevent=0x1c9e7394) at
#19 0x0188bab4 in PL_HandleEvent (self=0x1c9e7394) at
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
Created attachment 196124 [details] [diff] [review]
Don't allow map in <html>

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,
Fyi, IE6 is moving the map stuff in the <head>
Blocks: 272702
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).


Created attachment 196257 [details] [diff] [review]
And fixing the bogus check that showed this

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

Attachment #196257 - Flags: superreview+
Attachment #196257 - Flags: review?(jst)
Attachment #196257 - Flags: review+
Attachment #196124 - Flags: review?(jst)
Fix checked into trunk.
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.