65943 - Content state needs to reset before event handler is fired

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Henrik Gemal]

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

Comment 1

[Henrik Gemal]

URL should have been:
http://gemal4.sprawl.dk/

Comment 2

[Loco]

Hmm...Thought this was a duplicate, but I couldn't find one.  Saw bug 1500, and
bug 2004, but no cigar.  Oh, well.  Deserves some more mention anyway, since its
so annoying.

Comment 3

[Loco]

Hmm...Thought this was a duplicate, but I couldn't find one.  Saw bug 1500, and
bug 2004, but no cigar.  Oh, well.  Deserves some more mention anyway, since its
so annoying.

Comment 4

[Blake Ross]

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...

Comment 5

[Blake Ross]

[forgot to point out that the pref pane and the pref buttons are part of 
different documents]

Comment 6

[Henrik Gemal]

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.

Comment 7

[Blake Ross]

Was that intended for this bug?  This has nothing to do with network cache, it's 
an ESM problem.

Comment 8

[Blake Ross]

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.

Comment 9

[Jesse Ruderman]

Lots of events aren't supposed to go to the parent window when an alert is up.  
See bug 60150.

Comment 10

[joki (gone)]

Setting milestone and assigning.

Comment 11

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 12

[Blake Ross]

Attachment: [patch] just reorder

Comment 13

[Blake Ross]

saari, r=?

Comment 14

[saari (gone)]

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.

Comment 15

[joki (gone)]

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.

Comment 16

[Blake Ross]

> 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

Comment 17

[saari (gone)]

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.

Comment 18

[Blake Ross]

cc'ing the rest of the world

For what it's worth, IE seems to reset active first from some cursory testing.

Comment 19

[Blake Ross]

If anyone has any objections speak now, or forever behold this patch in the 
tree.

Comment 20

[Kathleen :Brade]

Has this been tested on Linux, Mac and Windows?
Has this been tested in Composer?
Has this been tested in Mail/News?

Comment 21

[Blake Ross]

This was fixed.

Comment 22

[Henrik Gemal]

verified in 20010514