Closed
Bug 567738
Opened 15 years ago
Closed 14 years ago
Javascript alert() faulty including inability to move dialog box
Categories
(Core :: General, defect)
Tracking
()
People
(Reporter: rohan, Unassigned)
References
Details
(Keywords: regression)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( )
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( )
On Mozilla Firefox 3.6.3, a modal-dialog box generated by alert() *before the page has finished loading* in Javascript will not allow the user to move the dialog box.
Also, the dialog box sometimes require multiple clicks on OK to activate.
The confirm() dialog box has the same problem.
Firefox 3.5.9 does not have this problem. This build works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 ( )
I have tried putting script containing the alert() code in different places -- in an external .js file, in the HTML <HEAD> section, in-line between <SCRIPT> tags and in script activated by the <BODY onLoad="xxx"> attribute. In all cases the problem surfaces by the second invocation.
One severe side effect of this bug is what happens when you have another Windows application showing in front of the Firefox window when Firefox is in this failure state: Clicking on that other application does not give it focus! Instead you have to click on the other application's icon in the taskbar.
Reproducible: Always
Steps to Reproduce:
1. Create a web page like so:
<head>
</head>
<body>
<form>
<input type='submit' value='Try again after clicking here' />
</form>
<script>alert("try and move this window");</script>
</body>
2. Load the web page into the browser.
3. When you see the dialog box, click OK
4. Press the submit button
5. When you see the dialog box again, try moving it around the screen. If it works, try moving it for a bit longer - say 10 seconds. Then try clicking OK and see if it responds.
Actual Results:
When you get to step 5 above, if you try and move the dialog box around, it might work for a while and then Firefox will freeze.
In my simple test code above, I can move the dialog box before it freezes, but in the bigger web application I am working on, I can't move the window at all, though I can usually press OK.
You may even notice mouse movement being restricted.
You may be able to regain control of Firefox by switching to another Windows application by pressing CTRL+ESC and then switching back with ALT+TAB.
Expected Results:
Dialog box should move around freely without freezing. When you click OK (or the close button on the dialog box) it should dismiss the dialog box immediately.
You might like to experiment by adding the additional line:
<input type='submit' value='Try again after clicking here' />
to the form in the test code above.
This is only a hunch, but is this bug due to the new implementation of "DEFER" for scripts in Gecko 1.9.2?
https://developer.mozilla.org/En/HTML/Element/Script
![]() |
||
Comment 1•15 years ago
|
||
Hmm. I can't seem to reproduce on Windows 7 (over vnc, though).
You could test your hunch by using nightly builds to narrow down when the problem first appeared. Are you willing to spend some time doing that? ("No" is a perfectly reasonable answer!)
Reporter | ||
Comment 2•15 years ago
|
||
(In reply to comment #1)
> Hmm. I can't seem to reproduce on Windows 7 (over vnc, though).
>
> You could test your hunch by using nightly builds to narrow down when the
> problem first appeared. Are you willing to spend some time doing that? ("No"
> is a perfectly reasonable answer!)
No, I don't think I could manage that. But if you give me URLs to download a few specific builds, I could try them and report back.
![]() |
||
Comment 3•15 years ago
|
||
Sure. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/08/2008-08-04-03-mozilla-central/ is the nightly before <script defer> landed and http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/08/2008-08-05-04-mozilla-central/ is the nightly after it landed. I would expect that this isn't the cause, but good to check....
Neil, did focus manager land in 1.9.2?
Thank you for testing!
Reporter | ||
Comment 4•15 years ago
|
||
Hi Boris, I've kept my FF pretty up to date over the years and 2008 seems too long ago. (That would be pre v.3.5.9 anyway though, right?) I only encountered it in recent months. Maybe the two version numbers I gave (v3.5.9 - working) and (v.3.6.3 - broken) can narrow things down to a smaller band of nightlies?
![]() |
||
Comment 5•15 years ago
|
||
Oh, right. <script defer> was supported in 3.5.x, so of course that range is before the 3.5.x branchpoint...
Rohan, knowing something works in 3.5.x but not in 3.6.x more or less gives us a time range from early December 2008 (which is when 3.5.x branched off the trunk) to mid-August 2009 (which is when 3.6.x branched from the trunk) or later (in case the patch that caused the problem was backported).
So I guess trying the nightly at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/05/2009-05-02-04-mozilla-central/ might be a good start...
Reporter | ||
Comment 6•15 years ago
|
||
(In reply to comment #5)
> So I guess trying the nightly at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/05/2009-05-02-04-mozilla-central/
> might be a good start...
That build does not have the fault. Feel free to suggest another.
![]() |
||
Comment 7•15 years ago
|
||
Reporter | ||
Comment 8•15 years ago
|
||
(In reply to comment #7)
> How about
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/08/2009-08-01-04-mozilla-central/
> ?
Bug not present. (Interesting how the alert window has maximise, minimise and close on that one.)
![]() |
||
Comment 9•15 years ago
|
||
Reporter | ||
Comment 10•15 years ago
|
||
(In reply to comment #9)
> Hmm. How about
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/10/2009-10-01-04-mozilla-central/
> ?
Bug not present here either.
![]() |
||
Comment 11•15 years ago
|
||
How about http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/10/2009-10-01-05-mozilla-1.9.2/ ?
And if that doesn't have the bug, what about http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/02/2010-02-01-04-mozilla-1.9.2/ ?
Reporter | ||
Comment 12•15 years ago
|
||
(In reply to comment #11)
> How about
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/10/2009-10-01-05-mozilla-1.9.2/
bug not present
>
> And if that doesn't have the bug, what about
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/02/2010-02-01-04-mozilla-1.9.2/
bug IS present, build ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2pre) Gecko/20100201 Namoroka/3.6.2pre ( )
![]() |
||
Comment 13•15 years ago
|
||
Reporter | ||
Comment 14•15 years ago
|
||
bug present in this build too
![]() |
||
Comment 15•15 years ago
|
||
![]() |
||
Comment 16•15 years ago
|
||
We've got this narrowed down to about 600 changes, by the way. ;)
Reporter | ||
Comment 17•15 years ago
|
||
(In reply to comment #16)
> We've got this narrowed down to about 600 changes, by the way. ;)
No worries - need to hunt this one down and kill it. :)
No bug in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-01-04-mozilla-1.9.2/
![]() |
||
Comment 18•15 years ago
|
||
Reporter | ||
Comment 19•15 years ago
|
||
(In reply to comment #18)
> What about
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-15-04-mozilla-1.9.2/
no bug
![]() |
||
Comment 20•15 years ago
|
||
Reporter | ||
Comment 21•15 years ago
|
||
the bug is back :)
![]() |
||
Comment 22•15 years ago
|
||
Reporter | ||
Comment 23•15 years ago
|
||
(In reply to comment #22)
> OK, how about
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-19-05-mozilla-1.9.2/
> ?
no bug
Reporter | ||
Comment 24•15 years ago
|
||
Reporter | ||
Comment 25•15 years ago
|
||
this one has the bug: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-20-05-mozilla-1.9.2/firefox-3.6b4pre.en-US.win32.installer.exe
Is that as far as we can go?
![]() |
||
Comment 26•15 years ago
|
||
With prebuilt builds, yes; if we need to I can spin up more builds in between but it would take several hours per build.
If I might ask, what are the changeset ids on those Nov 19 and Nov 20 builds? You can get the changeset id by opening about:buildconfig; they're the part after "rev/" in the "Built from" line.
![]() |
||
Comment 27•15 years ago
|
||
Pending that, a conservative range for the regression is http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?startdate=2009-11-19+00&enddate=2009-11-20+10
Kyle made a change to Windows widgetry in there, but that doesn't seem obviously relevant here...
Once I have those build ids I'll kick off a tryserver build to try to bisect more.
Yeah my changeset isn't likely to be relevant. The only one that jumps out at me is http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0113c6c01241 which is at least relevant at the right time.
Hmm. If it's not a bug on trunk then we could do some extra bisection to figure out why.
![]() |
||
Comment 30•15 years ago
|
||
Yes, if we find a trunk build showing the bug...
Reporter | ||
Comment 31•15 years ago
|
||
(In reply to comment #26)
> With prebuilt builds, yes; if we need to I can spin up more builds in between
> but it would take several hours per build.
> If I might ask, what are the changeset ids on those Nov 19 and Nov 20 builds?
> You can get the changeset id by opening about:buildconfig; they're the part
> after "rev/" in the "Built from" line.
The last nightly build without the bug is a2af57fed584.
The first nightly build to have the bug is 978fa137b516.
So that's the range http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=a2af57fed584&tochange=978fa137b516 which still includes roc's patch which changes how scripts work on load and my widget patch. Nothing else looks likely to be relevant.
![]() |
||
Comment 33•15 years ago
|
||
I pushed the changeset right before roc's to tryserver as rev b7b5c001e59a.
There should be builds at https://build.mozilla.org/tryserver-builds/bzbarsky@mozilla.com-try-b7b5c001e59a/ sometime in the next several hours.
![]() |
||
Comment 34•15 years ago
|
||
Er, apparently try builds go to a different place now. I'll post the link once I have it.
![]() |
||
Comment 35•15 years ago
|
||
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bzbarsky@mozilla.com-b7b5c001e59a/ seems to be the right place. There are debug Windows builds up now, and I would expect optimized ones in the near future.
![]() |
||
Comment 36•15 years ago
|
||
I confirmed regression in local build.
Changeset of 711a206bccb0(Robert O'Callahan — Bug 528493 preliminary. Don't MaybeLoadImage on bind if image loading for this node is disabled) casues this problem.
![]() |
||
Comment 37•15 years ago
|
||
Huh. That's _really_ weird...
Comment 39•15 years ago
|
||
But bug 528493 was also fixed in 3.5.8 -- are we sure that's the cause? (There are lots of differences on the branches so it's plausible the same patch would cause different interactions, but worth double-checking.)
blocking1.9.2: ? → needed
status1.9.2:
--- → wanted
Updated•15 years ago
|
status1.9.1:
--- → ?
Reporter | ||
Comment 40•15 years ago
|
||
This bug is present with Firefox 3.6.3 on Windows 7 too.
I'm sure there's a good reason, but I'd be interested to know why a fix hasn't made it into the last couple of minor releases.
![]() |
||
Comment 41•15 years ago
|
||
I am sorry that Comment #36 was wrong.
As a result of having performed local build carefully, rsults as follows.
Revert to changeset cf145e14e35b, Fails
Revert to changeset b8c270d94697, Fails
Revert to changeset f20c59deb6ac, Works
So, I guess landing changeset b8c270d94697 of Bug 520386 causes the problem.
No longer blocks: 528493
![]() |
||
Comment 43•14 years ago
|
||
Note that this may no longer need to block given tab-modal dialogs.... though see bug 613714. ;)
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 44•14 years ago
|
||
Dear Benjamin Smedberg,
Can you please give more information regarding your decision to mark this as "RESOLVED WORKSFORME"?
The bug is still present on Firefox 3.6.13 on Windows 7.
Did you try the test HTML in the "Steps to Reproduce" above? You will need to press OK, then click the "Try again after clicking here" button and only then will you see the bug.
![]() |
||
Comment 45•14 years ago
|
||
Rohan, there are no plans to change any behavior in the stable releases here. And the issue is not present as described in Firefox 4.
Reporter | ||
Comment 46•14 years ago
|
||
OK, glad to see it works in Firefox 4. (Though I noticed in Beta 8 the ability to move the alert dialog box at all has not been implemented yet.)
Thanks Boris for clarifying.
![]() |
||
Comment 47•14 years ago
|
||
Well, that's why I said "as described". The general inability to move the tab-modal dialogs is known; I'm not sure what the plan is for it.
You need to log in
before you can comment on or make changes to this bug.
Description
•