101140 - Warning dialog hidden inaccessibly behind new window

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[bht237]

A blocking warning dialog is hidden under a new window, consequently avoiding
the execution of a script.

This worked OK with build ID 2001072403

The severity of this bug alone is critical.
However, bug 57841 "window.focus and window.blur not functioning correctly"
makes it a blocker because window.blur() does not hide the new window.

Comment 1

[bht237]

Attachment: testcase

Comment 2

[Matthias Versen [:Matti]]

Reporter: 
Please don't touch the "Target Milestone" and "Priority" fields and please don't
add the "+" or the "-" to any keywords (nsenterprise+)
and this is not a blocker... 
and please add to all your bugs your used build ID !

Comment 3

[bht237]

Point taken. Build ID 2001092103. Each time I enter a bug, Bugzilla displays
build ID info apparently initialised from the USER_AGENT HTTP header. So I
assume that info is lost in the process.
If ecommerce stops because users cannot continue their purchase transaction that
is a blocker for us but in Mozilla terms maybe not.
Maybe we need a new keyword such "ecommerce_stops" but I don't care as long as
this is seen as what it is: A malfunction on the highest level of the component
hierarchy (window) that is capable of rendering the browser completely useless
in the perception of an ordinary user.

Comment 4

[Jesse Ruderman]

WFM.  I clicked on the "submit form in new window" button, and got a new window 
with a crypto warning dialog in front of it.

Comment 5

[bht237]

Jesse, what is your OS platform, Build ID, CPU speed? I use a 300MHz AMD 300 on
Win95 with a Matrox Millenium graphics card, not a fast computer by today's
standards.

This appears to be a typical racing condition type of bug.
In fact I have just been able to get a failure on the second attempt directly
after a _successful_ first attempt. So the error might be difficult to reproduce
with the first testcase.

With a variable setTimeout delay value, you and others might be able to zoom
into the critical zone and hit the racing condition more easily.

I will attach a second testcase with this option.

With my hardware/OS configuration, I get the error with timeout values between 0
and 150ms. In camparison when I increase the value to say 500ms, then I cannot
reproduce the error at all.

Comment 6

[bht237]

Attachment: testcase 2 with variable time delay

Comment 7

[bht237]

Attachment: Screenshot of the "illegal case" NB incorrect message ("unencrypted")

Comment 8

[bht237]

There is more to this bug than I thought. The latest testcase, when it fails,
submits into an arbitrary unnamed window instead of opening a new one as
specified, which schould be considered a security risk.
It pushed my bug report page out and I thought I had lost a window!
Note that 2 warning dialogs, directly following each other, are displayed:
1) insecure
2) secure.
The screenshot attachment shows the first dialog.

Comment 9

[Asa Dotzler [:asa]]

I'm confused by all the keywords. I wonder what value is added to this bug by
half of those flags. 

Comment 10

[John Morrison]

Worksforme at a variety of delay settings. The warning dialog is always the 
topmost window, although when that dialog is spun up, the first window is 
raised above the SSL/submit window.

Comment 11

[bht237]

I just tested build 2001092803 and reproduced the error - exactly the same as
before - with a 300MHz AMD K6-2 processor.
After John Morrison's test it appears that the variable timout value does NOT
make it easier to reproduce the error on systems that are not susceptible to
this racing condition.
Maybe someone with a slow processor e.g. 120MHz Pentium wants to try this?
Would everyone testing this please provide some documentation, at least nominal
CPU clock speed.

Comment 12

[Paul Chen]

-> danm

Comment 13

[Hong Kwon]

marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Comment 14

[Arun Prasannan (polar)]

This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/

Comment 15

[Mark Banner (:standard8)]

Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.

Comment 16

[Philip Chee]

Cannot reproduce on SeaMonkey 2.0a3pre trunk