119061 - SVG elements to which :hover apply do not restyle when moved under the mouse pointer

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Bryant Howell]

on build 200210909 SVG-MathML

In the example URL given, when the animation is taking place, and one mouses
over the blue star and lets it become opaque, and then the star moves away from
mouse from it's animation, it retains it's opacity even though the mouseover is
no longer present. State does not change until mouse is moved. Script bug or
possibly this is desired behavior?

Comment 1

[Bryant Howell]

Looked at code, the question on my mind is "Does a :hover still apply if the
object has moved away from the mouse of it's own accord?" In HTML the hover
color no longer applies if the item moves out without the cursor moving, i.e. a
scrollwheel movement. Thoughts? Should I post a screenshot?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

no screenshot needed.

:hover shouldn't apply if the object moves away from the pointer or if the 
scrollweel is used to scroll away from the object. And the mouseout even should 
occur. Same when entering above an object. And the same should apply all over 
mozilla, not just to SVG.

However this is an area where i don't think i've seen a single program behave 
properly (IE sometimes does and sometimes not) and is obviously something which 
is pretty hard to fix.

That said, i still think it would be nice if it was fixed.

Comment 3

[Bradley Baetz (:bbaetz)]

":hover shouldn't apply if the object moves away from the pointer or if the 
scrollweel is used to scroll away from the object."

Actually, according to the SVG specs, :hover applies until the mouse moves over
another element with :hover set, IIRC. We're ignoring that part of the spe,
since it can be interprented differently.

This bug isn't an SVG bug - it happens with a:hover too, and cursor changes when
using the scrollwheel over a link. I can't find the bug, but I'm fairly sure
that there is one.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

that seems really strange. Then if only one element has :hover set then you 
would never be able to "unhover" it?

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

er, i mean "if there is only one :hover rule in the stylesheet"

Comment 6

[Bradley Baetz (:bbaetz)]

Yeah. This is one of hixie's hate-points about SVG, but I Can't see the text in
teh spec, now that I lookfor it. Maybe it got removed from a draft. I'll have to
ask him.

See bug 78767 and its dupes - maybe that should be reopened?

Also see bug 98114 and bug 20022, and other bugs mentioned in those reports

Comment 7

[Marco Perez [:mpk]]

Updated the test URL (link was broken).

Comment 8

[Jonathan Watt [:jwatt]]

Mass reassign of SVG bugs that aren't currently being worked on by Alex to
[e-mail]. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later. 

Comment 9

[jonathan chetwynd]

it's disappointing this bug is still open.

from a learning disabilities perspective there are examples of good practice in
the field that indicate that onmouseover should activate whether the mouse or
object moves.

an example that is used frequently in all sorts of applications is here:
http://www.peepo.co.uk/launch/balloonsmove.svg
balloons float past across the screen, if the pointer rolls over one it pops
with a bang. A common and useful strategy is to start the user off moving the
mouse to a place where the balloon will be in the future.

--

the current summary is a description od the example, not the problem.
It might help searchers more if it was generalised to something like:
should event handling of mouseover events and :hover be dependent on pointer
movement, or respond to object movement?

Naturally this doesn't work with the current state of :hover

my apologies the current uri uses script rather than css, mostly because of my
lack of knowledge regarding CSS and audio. help appreciated.

Comment 10

[jonathan chetwynd]

asv6 interprets onmouseover to be fired when an object moves under the cursor.

the example in the comment above shows this, I'll try to refine this at some
time, apologies

Comment 11

[Jonathan Watt [:jwatt]]

So :hover works when scrolling causes an element to move under the stationary mouse pointer, but not when the element moves under the stationary mouse pointer due to script changes or animation. Boris, David, do you think we should make this work?

Comment 12

[Boris Zbarsky [:bzbarsky]]

This works fine for HTML.  Try it:

data:text/html,<style>div:hover { opacity: 0.5 }</style><div style="position:absolute; color:white; background: black; height: 100px;">Put the mouse over this and leave it there</div><script>var i = 0; setInterval(function() { i = 1 - i; document.getElementsByTagName("div")[0].style.top = i*100 + "px"; }, 1000)</script>

So yes, we should make this work.  Why doesn't it work for SVG?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Ah, it doesn't work because we synthesize mousemove in PresShell::DidDoReflow, and the SVG code isn't doing that here.  Presumably we just need to also do it after whatever it is that SVG does to update its geometry.

Comment 14

[Jonathan Watt [:jwatt]]

Hmm. Well we don't want to do it under nsSVGOuterSVGFrame::InvalidateCoveredRegion or UpdateAndInvalidateCoveredRegion since we'd fire events like crazy. Then again I'm guessing we don't want to be firing events under Paint.

Comment 15

[Boris Zbarsky [:bzbarsky]]

1)  Firing of the event is async.  SynthesizeMouseMove just posts an nsIRunnable
    to the event loop to fire a mousemove event; the DOM event is dispatched when
    we run that runnable.
2)  A call to SynthesizeMouseMove while such a runnable is posted is a no-op.

See nsViewManager::SynthesizeMouseMove in its 20-line glory for details.

Which doesn't tell me where this call should go, but that's where you come in!  ;)

Comment 16

[Jonathan Watt [:jwatt]]

Attachment: patch

It would be in these two places. The problem is writing an automated test though. Seems like we need bug 470845 for that.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Does sending mouse events via window utils not trigger hover state?

Comment 18

[Jonathan Watt [:jwatt]]

I'm sure it would, but we don't want to test what happens when the mouse moves over a given element. We want to "place" the cursor at a given location, and then test what happens when the element moves under or out from under that location.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Isn't that the same thing?  Dispatch a single mousemove event, check that the element entered hover state, then start moving it.  Keep asserting it's in hover state until it's been moved so it's not under the spot where we sent the mousemove, then assert it's not longer in hover.

Comment 20

[Jonathan Watt [:jwatt]]

Attachment: (non-)test that attempts to use nsIDOMWindowUtils::sendMouseEvent (doesn't work)

Ah, sorry, I thought that the window utils method required you to specify the element, not the mouse coordinates. Actually it's the opposite way round, so I tried to write a test using nsIDOMWindowUtils::sendMouseEvent but unfortunately it doesn't work. I'm guessing this is because nsViewManager::DispatchEvent only sets mMouseLocation (line 1269) if the event is eReal (line 1261):

http://hg.mozilla.org/mozilla-central/annotate/0f233616614b/view/src/nsViewManager.cpp#l1259

Comment 21

[Jonathan Watt [:jwatt]]

That test looks like it works (the viewport is filled with green) but it actually is aborting too early to even show failure (yeah, poorly written). See the Error Console error:

Error: A script from "https://bug119061.bugzilla.mozilla.org" was denied UniversalXPConnect privileges.
Source File: https://bug119061.bugzilla.mozilla.org/attachment.cgi?id=381074
Line: 29

Comment 22

[Boris Zbarsky [:bzbarsky]]

OK.  We can stick to manual testing for now...

Comment 23

[Jonathan Watt [:jwatt]]

Comment on attachment 381062 [details] [diff] [review]
patch

Any opinions on how we should proceed to enable this case to be tested longer term?

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 381062 [details] [diff] [review]
patch

viewMgr can't be null here.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #20)
> Ah, sorry, I thought that the window utils method required you to specify the
> element, not the mouse coordinates. Actually it's the opposite way round, so I
> tried to write a test using nsIDOMWindowUtils::sendMouseEvent but unfortunately
> it doesn't work. I'm guessing this is because nsViewManager::DispatchEvent only
> sets mMouseLocation (line 1269) if the event is eReal (line 1261):
> 
> http://hg.mozilla.org/mozilla-central/annotate/0f233616614b/view/src/nsViewManager.cpp#l1259

But the event generated in nsDOMWindowUtils::SendMouseEvent *is* eReal.

Comment 26

[Jonathan Watt [:jwatt]]

Attachment: patch + disabled test

Sorry, that was a bad guess on my part then, and I shouldn't have been proceeding as if I'd confirmed my guess. :-/

Turns out that the test failing was also my bad - I ran the tests in the wrong tree. The test actually works fine when run in the tree with the patch applied. The only issue now is that reftests cannot currently request UniversalXPConnect so I've had to disable it.

Comment 27

[Boris Zbarsky [:bzbarsky]]

We don't need a reftest here.  Make it a mochitest; then you get the EventUtils.js helpers too, and you can either use windowsnapshot or directly query computed style to see whether hover is being applied.

Comment 28

[Jonathan Watt [:jwatt]]

Huh. I thought I got r+ in comment 24, so I pushed http://hg.mozilla.org/mozilla-central/rev/f3fcd36fcbd1

Roc, can you let me know if I should back this out or if you're okay with it?

Comment 29

[Jonathan Watt [:jwatt]]

Weird. History says I did get r+. Wonder where it went.

Anyways, FIXED I guess.

Comment 30

[Jonathan Watt [:jwatt]]

Thanks for pointing out the fix bz.

Comment 31

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

The mochitest here could also end up looking a lot like test_hover.html, except with SVG in it :-)

Comment 32

[Boris Zbarsky [:bzbarsky]]

> Weird. History says I did get r+. Wonder where it went.

It's right there on the first patch in this bug, where roc put it.

Comment 33

[Shawn Wilsher :sdwilsh]

This got backed out due to persistent orange on linux unit tests.

http://hg.mozilla.org/mozilla-central/rev/06027b3d50d9
http://hg.mozilla.org/mozilla-central/rev/68035339a3f0

Comment 34

[RNicoletto]

No news in the last year? Still orange on linux unit tests?

Comment 35

[Jonathan Watt [:jwatt]]

Seemed to pass Try, so pushed to m-i:

https://hg.mozilla.org/integration/mozilla-inbound/rev/f91f161171dd

Comment 36

[Jonathan Watt [:jwatt]]

https://hg.mozilla.org/mozilla-central/rev/f91f161171dd

Comment 37

[Robert Longson [:longsonr]]

Iv've fixed and relanded the test via bug 1925524