hang when opening a valid XML when the filesize > 64KiB

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
10 years ago
11 days ago

People

(Reporter: paroga, Unassigned)

Tracking

({hang, regression, testcase})

Trunk
hang, regression, testcase
Points:
---
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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

10 years ago
Created attachment 327941 [details]
File with Parseing Error
(Reporter)

Comment 2

10 years ago
Created attachment 327942 [details]
File with Hang

Comment 3

10 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?
Keywords: crash, regression, regressionwindow-wanted, testcase
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-

Comment 5

10 years ago
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

10 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
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 ...
Keywords: regressionwindow-wanted
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
Last Resolved: 11 days ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.