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)

defect
Not set
critical

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.
Attached file File with Hang
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
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
(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
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
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.
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 ...
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.

Attachment

General

Created:
Updated:
Size: