Closed Bug 58276 Opened 24 years ago Closed 13 years ago

bringing up dialog while network test is running freezes app

Categories

(Core :: XUL, defect, P2)

x86
Windows NT
defect

Tracking

()

RESOLVED INCOMPLETE
Future

People

(Reporter: bugzilla, Unassigned)

References

()

Details

(Keywords: hang, platform-parity, Whiteboard: [rtm-])

tever found this using today's commercial branch bits. also occurs using y'day
bits 2000.10.26.13 (on winNT, sp5).

to repro:
1. load the URL to start test.
2. while test is running, open a modal dialog [eg, prefs or open web location].
3. attempt to dismiss the dialog [click cancel, esc, etc.].

results:
unable to dismiss dialog, and, even though the test runs to completion, the app
is essentially frozen. unable to dismiss dialog even after end of test.
essentially a 'crash'. but no talkback.

unable to surf or do much else, even after test completes. i wonder if this
occurs in a trunk build? cc'ing doron/asa to see if it does, or on other win32
os's. according to tpreston, this doesn't occur on win2k. adding pp kw.
Keywords: crash, pp
it sucks to be on the trunk too ;)  This does break us on the trunk mozillla
builds 102704 NT4
->danm/M18/P2/Critical, nominate for rtm
Assignee: trudelle → danm
Severity: normal → critical
Keywords: rtm
Priority: P3 → P2
Target Milestone: --- → M18
This zdnet test simply chains a series of pages together by setting
|onload='document.location.href="nextDoc.html"';|. The equivalent testcase, 
which just reloads itself 60 times and will also hang-up the browser is at 
  http://jrgm.mcom.com/bugs/58276/test.html
(I will attach the source if anyone outside the firewall would like to look
at it). 

This will hang on win2k (and I would think any win32). On Linux it does not 
hang, and curiously, exiting the dialog kills the page-loading. On Mac, 
when the dialog is up, all application activity ceases aside from the dialog, 
so no hang there. 

I'm not sure about the rtm for this. While the zdnet tests are high-profile,
this is a narrow set of conditions. (In fact, if I use a .setTimeout to 
delay the next page load by any amount, even "0 msec", this will not lock
up in my tests). It is only when the onload handler immediately initiates
another load that a modal dialog can be hung-up. (Actually, I'd be more 'sure'
about rtm if this was likely to be a simple fix, but I doubt it).
bug 56934 might be related, as it is also the ZDNET bench thing. As this is a
crasher, nominating for m0.9 should this not make rtm (wondering why the target
is m18, oh well).

Has anyone tested this on linux/mac?  I'll try to get this tested on linux
Keywords: mozilla0.9
Does the ibench test explicitly create this situation, or does it only happen
why you try to mess with the browser while the test is running?  Would ZDNet
ever do this while the tests are running?  If not, it seems like rtm- is the
right call.
Whiteboard: [need minus]
pdt - this is a need info from the developer this is assigned to probably.

56934 has been marked fixed btw.
doron, this isn't a problem on Mac or Linux, at least with branch bits.
se: I had someone on irc who said he saw this on linux, turned out it was some
profile issue. my mistake.
rtm-/future
Whiteboard: [need minus] → [rtm-]
Target Milestone: M18 → Future
i can confirm this on win2k with build 2000102704 (trunk)
After the benchmark test i hit the run button on that page and mozilla
freeze.
Keywords: crashfreeze
Keywords: freezehang
Assignee: danm.moz → nobody
none of the test URLs exist anymore
Status: NEW → RESOLVED
Closed: 13 years ago
QA Contact: jrgmorrison → xptoolkit.widgets
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.