From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (X11; I; FreeBSD 5.0-CURRENT i386) BuildID: 2000030708 If I don't move the mouse the popup doesn't render, by vigorous mous movement the popup will render faster. Reproducible: Always Steps to Reproduce: 1)load URL 2)click "add item" 3)click "set date" and DO NOT MOVE THE MOUSE 4)wait Actual Results: No popup renders until the mouse is moved Expected Results: The popup should render without mouse movement Source is whatever was in the /pub/mozilla/nightly/latest directory on 2000-04-09 14:00 PDT Built on FreeBSD-current, testcase soon

If I click the button nothing happens if I don't move the mouse or type on the keyboard (greater than one minute wait, P2-350) nothing happens, but if I move the mouse or type keys the dialog will display. From the console: WEBSHELL+ = 6 << pauses here WEBSHELL+ = 7 << happens after I move the mouse WEBSHELL+ = 8 commonDialogOnLoad Move window by 268.5,96 screen x 229screen y 401 WEBSHELL- = 7 WEBSHELL- = 6 WEBSHELL- = 5

update: it doesn't render if the mouse doesn't leave the button

This bug may be related to bug 25189

This problem does not occur using the 2000-04-09-08-M15 nightly binar on WinNT; the alert appears immediately. I have seen similar problems in other apps in MS-Windows.

I've seen this happen with ordinary links as well. Looks like the onClick events don't fire until you leave the element. Note how, when you click and release the button, the 3-D press-down effect also doesn't happen until you leave the button. -> Event handling. Changing component, confirmed on Linux build 2000.04.09.09.

Puttin Sean back on the CC list. Marking pp since it doesn't happen on Windows.

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

the 3d press-down look in my case works (tested with 2000041816). Actually, that state doesnt *go away* - till after the alert box is dismissed.

I don't have a FreeBSD box to look at this on but the notion that mouse movement is required to allow painting and events sounds like its a platform issue somewhere above Gecko. Waqar, would you do me a favor and see if you can look into this or reassign it to someone appropriate to look at it?

This bug is also on Linux - see the duplicate bug 35884

This bug is also on Linux - see the duplicate bug 35884

Accepting

Accepting the bugs

Nominating for nsbeta2, because the perception is that the app is amazingly slow (I've had windows users looking over my shoulder saying "Wow, it's REALLY THAT SLOW on Linux??" because I'd forgotten I had to wiggle the mouse). Experienced users can work around it, but I don't think ordinary users will figure this out. Changing platform to Linux to make sure it doesn't get passed off by PDT as a minor-platform-only bug. No offense to FreeBSD intended!

Re-adding tor since my last change blew him away (sorry!)

Putting on [nsbeta2+] radar for beta2 fix.

I can't reproduce this anymore on Linux Build 2000052408. Using the attached testcase, the dialog pops up immediately.

What time and date build are you working with. The problem is when you click the the first time. I have been working on this bug for the last couple of hours. What I get is when you click it takes about 50 secs to pop up the dialog. But the next time it works fine. You have to restart the browser to make it behave like that.

Marking it as works for me

Trying to click a button (Cancel for example) in Open Web Location dialog still doesn't depress it without move in the latest nightly (build: 2000052520) Reopen?

What version of OS, X are you using?

Machine1: Redhat 6.1, but X has been upgraded to 6.2 rpms. (XFree 3.3.6) Machine2: Redhat 6.1 I can also try on Suse ...

Is this the correct bug for "button doesn't change state after press until mouse moves?". Perhaps a new one should be filed for this issue. Or Reopen?

Builds: Mozilla debug Linux and Windows builds made on 05/29/00. OS: Linux Red Hat 2.2.12-20smp XTerm = XFree86 3.3.3.1b(88b) OS: WinNT 4.0 (SP5) If you bring up the Mozilla for the first time, go the the URL of the 2000-04-09 attachment (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7410), this is what happens when you click on the "click me" command button: WinNT: in 1 second, an alert pops up saying, "hi" Linux: nothing happens for 15-20 seconds; then the "hi" alert pops up. At any time during the 15-20 seconds, however, you can make the alert come up by wiggling the mouse. Subsequent clicks on the button produce the alert exactly as on WinNT: in 1 second, without any wiggling needed. Note: the delay on Linux in the related Bugzilla bug# 36040 is even longer: it can be up to 40 seconds or more. Again, there is no delay on WinNT.

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

The GTK timer fixes this. I am marking this as a dependency.

Fix Checked in.

verified 2000-07-06-08-M17 - Linux