if you go to: http://gemal1.sprawl.dk/ and press the Login button but dont move your cursor away from the Login button a alert appears. Now the button in the "original" window stays pressed down. Moving the cursor inside the "original" window still makes the button pressed down, but as soon as you move the mouse cursor inside the alert window the button gets unpressed. Expected: As soon a the button is pressed an the new alert dialog appear the button should get unpressed down. This is also the way it works in all other browsers. Using build 20010118
URL should have been: http://gemal4.sprawl.dk/
This is, indeed, extremely annoying, and visible everywhere. It's also evident in other ways. For example, in the prefs dialog, if you set focus to a button in the pref pane and then set focus to the OK button, the button in the pref pane will remain in :focus until you mouse back over the pane (or something like that...not at home to check). Chris, I think this is yours...
Summary: button stays down until mouse is over new dialog → Content state doesn't update often enough across windows
[forgot to point out that the pref pane and the pref buttons are part of different documents]
in my opinion this is a network cache problem. Since the login page is nocache, pressing back to the login page on other pages should instruct mozilla to reget the login page since it's not in the cache, because of the nocache.
Was that intended for this bug? This has nothing to do with network cache, it's an ESM problem.
Hmm...I think I mixed this with another bug that I've been thinking of filing the past few days (about content state not properly updating across documents, like in preferences), although they're related. This seems like some kind of event ordering problem -- the state of the button needs to return to just :hover before the action in the event handler happens. If it doesn't, and the button is launching a modal dialog, we're unable to process any mouse events except those that occur in the new modal dialog, which is probably what's causing this.
Lots of events aren't supposed to go to the parent window when an alert is up. See bug 60150.
Setting milestone and assigning.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Summary: Content state doesn't update often enough across windows → Content state needs to reset before event handler is fired
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Assignee: joki → blakeross
Status: ASSIGNED → NEW
The patch is straight forward enough, but changing the ordering could cause other regressions. Some click event handlers may well be looking for the active attibute. It makes sense to me that active would be set at the time you get the click. That we don't fix that across a window trasition is a problem, but I don't think reordering is the right fix.
Hmm. I certainly agree with saari that this might cause regressions, no telling how many people are subtly using the current ordering. As to what the active state should be at the time of the click I'm not sure. Active typically means the control is ready to fire. Once you mouse up and actually cause the firing do you still need the active state? Not sure. But its largely the regressions that frighten me. One other possible fix of this is that I'm working on a fix to reset some pieces of state when a dialog comes up. Like if the mouse is down we need to reset the mouse state to account for losing mouseups to dialog boxes and the like. We could possibly also reset the active state at this time. While this too has some possible regression issues I think it has fewer. Though if we can get a good regression safety plan I'm not necessarily opposed the patch that's here now.
> It makes sense to me that active would be set at the time you get the > click. But clicks are, by definition, mousedown and mouseup. The button should return to normal before any action takes place, or you run into this problem. I'm not sure I understand what kind of regressions could come of this; seeing if a button is :active onclick doesn't seem like something you'd need to do often, if at all. Also, isn't ::GetContentState the only way to get the state? (That's the only method I'm aware of). If so...http://lxr.mozilla.org/seamonkey/search?string=getcontentstate
Run this by Ben Goodger for navigator, some editor people (akkana, sfraser, mjudge, etc.) and some mail news people. If they don't see any regressions or know of anything that would be a problem with this off the top of their head, then go for it. I don't know what "should" happen, if active should be set during a click or not. I can see both sides of it. Actually, see what IE does and follow that.
cc'ing the rest of the world For what it's worth, IE seems to reset active first from some cursory testing.
If anyone has any objections speak now, or forever behold this patch in the tree.
Has this been tested on Linux, Mac and Windows? Has this been tested in Composer? Has this been tested in Mail/News?
This was fixed.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified in 20010514
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.