From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; m17) Gecko/20000710 BuildID: 2000071020 Press and hold the left mouse button over a pushbutton, say the 'See bugs in this component' button. The button does not assume its depressed look until another event occurs, say moving the mouse slightly. Reproducible: Always Steps to Reproduce: 1.Move mouse cursor over pushbutton. 2.Press and hold left button without moving mouse. 3.Now move mouse slightly. Actual Results: 1. A solid outline appears around the button. 2. A dashed outline appears inside the button. 3. The button insides shift right and down to look depressed. Expected Results: The step 3 results should happen in step 2.
With 2000071108 linux (rh6.1), I am not seeing this at all. The button will depress on the 'click' event, and the 'mousemove' produces no additional change in the visual appearance of the button. Can you check this again, or add some additional details on how to reproduce -> rods, HTML Form Controls, but this may be worksforme
I'm running on Debian (unstable), and the behavior is just as I described, and has been that way for as long as I can remember. I don't know what else to tell you, but I'll be happy to supply more information if you tell me what you want to know.
I also don't see this on Linux (Red Hat 6.2, Gnome 1.2) 2000071108.
OK, now I have more information, and I don't think it's a Mozilla bug. I see this behavior when I am running the Enlightenment window manager. When I run Mozilla alone with no WM, it works fine. Sorry for the false alarm.
Marking INVALID based on reporter's comment.
actually, it could still be a mozilla bug (not too likely, though). reporter, are you still seeing this with new nightly builds?
Yes, it's still present. And upon further reflection, I think it must in fact be a Mozilla bug, because I don't see it happening when I use Netscape (the old one). Then buttons depress when I click on them, and I don't have to jiggle the mouse.
There is a bug filed, I believe, where a certain option on some WM's will conflict with the button being "depressed" onclick, observed for buttons in the UI (XUL). bug 49273. This bug was reported against HTML Form Controls, but quite likely it's the same bug.
firstname.lastname@example.org: Since you report this differently with different WM, I believe that this is the same problem (some type of click-trapping behavior) reported and better documented in 49273. I'm marking this as a dup. If you feel strongly otherwise, post to the bug and we can re-open. *** This bug has been marked as a duplicate of 49273 ***
small atomic mass update: qacontact->jrgm