Content state needs to reset before event handler is fired

VERIFIED FIXED in mozilla0.9.1

Status

()

VERIFIED FIXED
18 years ago
11 years ago

People

(Reporter: bugzilla, Assigned: bugzilla)

Tracking

Trunk
mozilla0.9.1
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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
(Reporter)

Comment 1

18 years ago
URL should have been:
http://gemal4.sprawl.dk/

Comment 2

18 years ago
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

18 years ago
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.
(Assignee)

Comment 4

18 years ago
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...
Keywords: nsbeta1
Summary: button stays down until mouse is over new dialog → Content state doesn't update often enough across windows
(Assignee)

Comment 5

18 years ago
[forgot to point out that the pref pane and the pref buttons are part of 
different documents]
(Reporter)

Comment 6

18 years ago
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.
(Assignee)

Comment 7

18 years ago
Was that intended for this bug?  This has nothing to do with network cache, it's 
an ESM problem.
(Assignee)

Comment 8

18 years ago
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

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

Comment 10

18 years ago
Setting milestone and assigning.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
(Assignee)

Updated

18 years ago
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)

Comment 12

18 years ago
Created attachment 24326 [details] [diff] [review]
[patch] just reorder
(Assignee)

Comment 13

18 years ago
saari, r=?
Assignee: joki → blakeross
Status: ASSIGNED → NEW

Comment 14

18 years ago
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

18 years ago
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.
(Assignee)

Comment 16

18 years ago
> 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

18 years ago
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.
(Assignee)

Comment 18

18 years ago
cc'ing the rest of the world

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

Comment 19

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

Comment 20

18 years ago
Has this been tested on Linux, Mac and Windows?
Has this been tested in Composer?
Has this been tested in Mail/News?
(Assignee)

Comment 21

18 years ago
This was fixed.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 22

18 years ago
verified in 20010514
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.