59009 - alert dialogs not coming to front, causing problems

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect, P4)

Description

[(not reading, please use [e-mail] instead)]

several people have reported this.

some times you'll get an alert ("your aim sessions has been terminated","the
connection to the server has been refused", "your connection timed out")

until the user OKs the alert, the application will not behave properly.

ie, you can't sign on to aim or you can switch folders, etc.

I think we can solve this problem by raising alerts to the front after they
appear.

assigning to damn, who has strong dialog kung-fu.

Comment 1

[Dan M]

  My kung fu has been weak lately.
  1) Is this bug not the same as bug 55460? That one is long and rambling, but 
I've been focusing on John's comment from Oct 13, in which it's pointed out that 
typing "javascript:alert('hi')" in the URL bar shows no alert.
  2) Since there are no specific steps for reproducing the problem given, I'm 
working with what I know from the spate of similar bugs like 55460. Personally, 
when I try the javascript:alert trick, I'm not getting an alert hidden behind the 
browser window, I'm getting no alert window at all. The alert never finishes 
loading, apparently because of some event starvation problem that's been kicking 
my butt for days now.
  Is that what's happening to you, or do you actually get an alert window, just 
hidden? If you're getting the window, this has to be a duplicate of bug 25684 
(closed WFM because it's really a metabug placeholder), which is really an avatar 
of bug 44809, which complains that some people are still using Hidden Window to 
parent the occasional modal dialog. I think this because we're using Windows OS 
functionality to assure an alert comes up in front of its parent. If it's not 
coming up in front of the expected window, I suspect its parent is a different 
window.

Comment 2

[Syd Logan]

We see this in IM, does cause some amount of confusing (e.g., after a while of
clicking on a IM window and not seeing anything, hunting around for a modal
alert and dismissing it gets you back in a happy state). Would be nice if modals
were always at the top of the stacking order.

Comment 3

[(not reading, please use [e-mail] instead)]

the javascript urls are working for me as expected.  (when I do the url bar and
when I click on them from the message pane.)

this is on last night release linux MN6 bits.

I always get the alert, sometimes it is hidding behind windows.  it doesn't
always happen, but when it does I'm confused why nothing is working.

I've learned to go find the alert and close it.  let me work on getting a
reproducable case for you.

Comment 4

[(not reading, please use [e-mail] instead)]

if we add the raise to front behaviour, we have to make sure we don't have
multiple alerts pinging the CPU, playing king of the mountain (with being on top.)

Comment 5

[(not reading, please use [e-mail] instead)]

according to navin, alerts that come as a result of renaming local folders and
rename or delete of IMAP folders on the UW server can produce this.

I'm going to come up with a test case.  

Comment 6

[Navin Gupta]

So here is the test case. This is happening only on mozilla trunk builds.
1) Create an imap mail folder "A" and then try to rename it "A" (no UW server 
required).
2) The Alert comes up and immediately disappears in the background. If the users
do not watch closely they may miss the alert. 

It may happen in other cases as Seth mentioned but I am not able to reproduce 
them consistently.

Comment 7

[Navin Gupta]

Sorry, forgot to mention the test case is for Win NT

Comment 8

[Dan M]

ok, must not be the same as bug 555460. note, probably is similar/same as bug 
55564

Comment 9

[Navin Gupta]

*** Bug 62871 has been marked as a duplicate of this bug. ***

Comment 10

[Navin Gupta]

Renaming a folder with a same name now works fine. The problem comes when you 
try to create a folder with a name that already exists. This is for IMAP on Win 
NT.  

Comment 11

[hirata masakazu]

I thnk the point is that any alert dialog that needs user input should not be
covered by a browser window. See also bug 62740.

Comment 12

[Peter Trudelle]

->moz0.9.1

Comment 13

[Dan M]

Just passing by; words to remember: as noted above, this could be a facet of bug 
25684, or the same as bug 46988, or bug 55460, or bug 28467. It'll be good 
someday to get the root cause fixed.

Comment 14

[Peter Trudelle]

Is this happening only on IMAP folder rename conflicts? I don't see that on
Win98, is it specific to NT? What other cases of this remain? In order for this
to remain a showstopper, I'll need to see exact steps to reproduce in current
builds.

Comment 15

[jag (Peter Annema)]

I don't see this on W2k with a recent build (less than a day old).

Just to make sure, what I did was:

0) start mozilla
1) open mail/news
2) create a folder "foobar" on my imap server
3) again create a folder "foobar" on my imap server
-> a dialog pops up with a message the folder already exists

the dialog stays in the front.

Comment 16

[Navin Gupta]

yep, the above case worksforme too. 

Comment 17

[Dan M]

I'm having trouble (read: can't) finding alerts that still have this problem. 
It's always been a bit iffy to reproduce, this problem, and I don't think it's 
completely fixed, but it's better than it was. I'm closing this bug, to be 
replaced in spirit by similar bugs of the same ilk; bug 84047 for example.