bringing up dialog while network test is running freezes app




18 years ago
8 years ago


(Reporter: sairuh (rarely reading bugmail), Unassigned)


({hang, platform-parity})

Windows NT
hang, platform-parity

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rtm-], URL)



18 years ago
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.].

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.

Comment 1

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

Comment 2

18 years ago
it sucks to be on the trunk too ;)  This does break us on the trunk mozillla
builds 102704 NT4

Comment 3

18 years ago
->danm/M18/P2/Critical, nominate for rtm
Assignee: trudelle → danm
Severity: normal → critical
Keywords: rtm
Priority: P3 → P2
Target Milestone: --- → M18

Comment 4

18 years ago
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
(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).

Comment 5

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

Comment 6

18 years ago
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]

Comment 7

18 years ago
pdt - this is a need info from the developer this is assigned to probably.

56934 has been marked fixed btw.

Comment 8

18 years ago
doron, this isn't a problem on Mac or Linux, at least with branch bits.

Comment 9

18 years ago
se: I had someone on irc who said he saw this on linux, turned out it was some
profile issue. my mistake.

Comment 10

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


18 years ago
Keywords: crash → freeze


18 years ago
Keywords: freeze → hang


14 years ago
Assignee: danm.moz → nobody

Comment 12

8 years ago
none of the test URLs exist anymore
Last Resolved: 8 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.