Closed Bug 401946 Opened 12 years ago Closed 12 years ago

[FIX]Nothing shows up in this case, the previous page stays visible

Categories

(Core :: XML, defect, P5, major)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9beta2

People

(Reporter: martijn.martijn, Assigned: bzbarsky)

References

Details

(Keywords: regression, testcase)

Attachments

(3 files)

Attached file testcase
See testcase, when loading that testcase, it seems that nothing is happening and you stay on the previous page like you didn't load that page.

This seems to have regressed between 2007-01-30 and 2007-01-31, which would make it a regression of bug 18333, I guess.
I find this behavior really bizar, so I'm marking it security sensitive for now.

I'm also seeing this assertion appearing in current trunk build:
###!!! ASSERTION: tag in XUL doc epilog: 'mState != eInEpilog', file c:/mozilla-build/mozilla/content/xul/document/src/nsXULContentSink.cpp, line 512
Maybe that has something to do with it?
Severity: critical → major
Currently, the testcase is getting an xml parsing error, that was filed as bug 404866.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P5
I think expat is somehow getting confused with its parser-blocking...  taking out the single <script> makes life happy again.

Then again, I can take out a good bit of the testcase and have the problem still be there.  Martijn, would you be willing to minimize this a bit?

And yes, I can see the XUL epilog assert leading to not rendering....
Component: Layout → XML
QA Contact: layout → xml
Attached file testcase2
Ok, this still asserts for me in my debug build.
Hmm.  I don't get an assert with that last testcase, just a parse error (as expected)...
Attached patch FixSplinter Review
Two things this patch is fixing:

Minor: <script> with a present but whitespace-only type attribute was leading to a parse error instead of just being treated like any script of unknown (don't know how to run it) type.  The change right after the GetParameter call fixes that.

Major: When we hit a <script> of unknown type, we returned without pushing anything on the context stack.  Then we ended up popping "too much" (since we did pop when we closed the <script>).  So we put nodes into the wrong child lists, and ended up in the epilog state at the point when the root element was still open.  The change to push the prototype element on the stack if OpenScript succeeded but didn't put us in script mode fixes that.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #290957 - Flags: superreview?
Attachment #290957 - Flags: review?
Attachment #290957 - Flags: superreview?(jst)
Attachment #290957 - Flags: superreview?
Attachment #290957 - Flags: review?(jst)
Attachment #290957 - Flags: review?
OS: Windows XP → All
Hardware: PC → All
Summary: Nothing shows up in this case, the previous page stays visible → [FIX]Nothing shows up in this case, the previous page stays visible
Target Milestone: --- → mozilla1.9 M10
Attachment #290957 - Flags: superreview?(jst)
Attachment #290957 - Flags: superreview+
Attachment #290957 - Flags: review?(jst)
Attachment #290957 - Flags: review+
Group: security
Checked in, with a reftest.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120405 Minefield/3.0b2pre
The contents of the first testcase show up fine now.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.