Closed
Bug 443390
Opened 17 years ago
Closed 6 years ago
hang when opening a valid XML when the filesize > 64KiB
Categories
(Core :: XML, defect)
Core
XML
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: paroga, Unassigned)
Details
(Keywords: hang, regression, testcase)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008070203 Minefield/3.1a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008070203 Minefield/3.1a1pre
Firefox hangs, when opening xml2.xhtml, if you open xml.xhtml it throws the following parseing error:
XML Parsing Error: mismatched tag. Expected: </head>.
Location: xml.xhtml
Line Number 6, Column 5:
Reproducible: Always
Steps to Reproduce:
open the attached files
Actual Results:
XML Parsing Error @ xml.xhtml
Firefox hangs @ xml2.xhtml
This errors only occur when filesize of xml.xhtml is > 128KiB and the filesize of xml2.xhtml is > 64KiB. So if you remove one character in the file it will work without problems.
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
I think more than one problem attributes here. Someone should really look into this.
In Firefox 2 (as well as Opera and Safari) both testcases work fine.
In Firefox 3 and 3.1 beta 2 the first testcase results in the parse error mentioned above. Interestingly, the alert() still works.
The second testcase crashes. When I open it, the alert apears. After I click ok, the content of the file is shown, but there's a second alert and if I click that we crash.
It's not 100% reproducable, but after the crash, when I restore the session the crashy testcase is sometimes restored as well and working instead of crashing.
Minefield shows different symptoms: Both testcases open and send the alert, but the content isn't shown in any testcase.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1?
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Comment 4•16 years ago
|
||
Both those testcases work as expected here, it seems. They both load, they both show an alert, and no error is reported anywhere as far as I can tell. Blocking- based on that, but please re-nominate if someone can confirm this really is a problem, or what it takes to trigger this.
Flags: blocking1.9.1? → blocking1.9.1-
I tested this once more.
I'm unable to reproduce the crash now, even though I used the same profile. I updated b2 to the latest branch nightly. It didn't crash an there was also no parsing error.
However, the latest branch build and Minefield show a strange bug with the first testcase (attachment 327941 [details]).
Sometimes after I click "Ok" on the alert, the content isn't shown. Not always, but rather often.
Keywords: crash
Comment 6•16 years ago
|
||
(In reply to comment #5)
> Sometimes after I click "Ok" on the alert, the content isn't shown. Not always,
> but rather often.
Tried 5-6 times, the page is blank every time after clicking "Ok" on the alert on
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090206 Shiretoko/3.1b3pre ID:20090206033253
Comment 7•16 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090206 Shiretoko/3.1b3pre ID:20090206033253
I can fairly reliably reproduce the hanging scenario.
1. New profile, start firefox
2. Load the first testcase, attachment 327941 [details]
3. Whilst the testcase is loading, mash the return button in order to dismiss the alert dialog as soon as it appears.
4. If no crash, click the refresh icon and go to 3
So it seems the trick to getting the browser to hang is to interact with/dismiss the alert as soon as it appears. JST are you able to reproduce this?
[ I will assume the background text ("1234567890") intermittently being shown/not shown is another bug ]
Keywords: hang
![]() |
||
Comment 8•16 years ago
|
||
i can reproduce the hang with https://bugzilla.mozilla.org/attachment.cgi?id=327942 using Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7 ID:2009021910 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090315 Shiretoko/3.1b4pre ID:20090315052502 but not with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090315 Minefield/3.2a1pre ID:20090315050013
considering this and previous comments maybe there was a recent trunk fix for this issue.
![]() |
||
Comment 9•16 years ago
|
||
as i thought, a recent checkin:
fails:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090225 Minefield/3.2a1pre ID:20090225033705
http://hg.mozilla.org/mozilla-central/rev/8eba35e62d92
works:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090226 Minefield/3.2a1pre ID:20090226035935
http://hg.mozilla.org/mozilla-central/rev/a979ac23e17e
=> range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8eba35e62d92&tochange=a979ac23e17e
no idea which one, and so no idea if there's an outstanding 1.9.1/1.9.0 landing ...
Keywords: regressionwindow-wanted
Comment 10•6 years ago
|
||
I can not reproduce this issue with a current nightly on windows.
I will mark this report wfm based on my testing and comment #8 and #9
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•