Closed Bug 567738 Opened 15 years ago Closed 14 years ago

Javascript alert() faulty including inability to move dialog box

Categories

(Core :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- final+
blocking1.9.2 --- needed
status1.9.2 --- wanted
status1.9.1 --- ?

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
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!)
(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.
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!
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?
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...
(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.
(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.)
(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 ( )
bug present in this build too
We've got this narrowed down to about 600 changes, by the way. ;)
(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/
the bug is back :)
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
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.
Yes, if we find a trunk build showing the bug...
(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.
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.
Er, apparently try builds go to a different place now. I'll post the link once I have it.
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.
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.
Huh. That's _really_ weird...
Blocks: 528493
blocking1.9.2: --- → ?
blocking2.0: --- → ?
blocking1.9.3+. Regression.
blocking2.0: ? → final+
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
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.
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
Hmm... That's possible...
Blocks: 520386
Flags: wanted-fennec1.0?
Flags: in-litmus+
Note that this may no longer need to block given tab-modal dialogs.... though see bug 613714. ;)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
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.
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.
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.
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.