889075 - getComputedStyle does not give correct styles that needs to be applied with removal of :hover pseudo-class on mouseout event in mouseout event

Status: UNCONFIRMED

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

Description

[Amit Ambardekar]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

1. Create a element(div) with styles of following form
#d1 {
  background-color:Blue;
}
#d1:hover {
  background-color:Red;
}
2. Attack mouseout event to the element
3. In mouseout event handler check the backgroundColor style through getComputedStyle function.

http://jsbin.com/eluruv/3/edit


Actual results:

getComputedStyle still gave old style value Red(/RGB(255,0,0)) i.e. old value when mouse was over the element


Expected results:

It should give its value as Blue(/RGB(0,0,255)) i.e. style which is applied to the element after removal of pseudo class :hover as mouse is out of the element and not hovering

Comment 1

[Amit Ambardekar]

It works as expected in chrome 27.0.1453.116

Adding 0 millisecond timeout and checking for style change gives correct output but that should not be needed.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I assume mouseout is just hovering before hover state is updated internally.  Not sure whether there is a spec covering this...  Olli?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

There is no spec for mouse event's hit testing or anything like that. So not a spec for this case
either.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  Do we want to change behavior here?  I would think there is no way to get this "right", offhand, unless hover state goes away completely into lala-land between the start of mouseout and the start of mouseover, which is also somewhat bogus.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Should we clear the old hover and set new right before dispatching mouseout.
Basically in nsEventStateManager::NotifyMouseOver call SetContentState before NotifyMouseOut.
Looks like we're somewhat inconsistent with state handling. Sometimes it happens before
mouseout, (if NotifyMouseOut is called with null as latter param), sometimes between
mouseout/over

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't think I have any particular insight here.  You should consider what other browsers do and what behavior is sensible, across both this case and related cases (and I'm sure there are interesting cases where the handlers move things around on the page).  When considering other browsers, note that some other browsers don't update :hover state (and probably also mouseover/out events) in response to changes in page layout, but only in response to mouse movements.  If you draw a useful conclusion, you should try to get that into a relevant specification.