Last Comment Bug 119061 - SVG elements to which :hover apply do not restyle when moved under the mouse pointer
: SVG elements to which :hover apply do not restyle when moved under the mouse ...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla13
Assigned To: Jonathan Watt [:jwatt] (back in October - email directly if necessary)
:
Mentors:
http://croczilla.com/bits_and_pieces/...
Depends on: 470845
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-09 14:52 PST by Bryant Howell
Modified: 2012-02-02 03:31 PST (History)
8 users (show)
jwatt: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (1.98 KB, patch)
2009-06-02 06:19 PDT, Jonathan Watt [:jwatt] (back in October - email directly if necessary)
roc: review+
Details | Diff | Splinter Review
(non-)test that attempts to use nsIDOMWindowUtils::sendMouseEvent (doesn't work) (1.91 KB, image/svg+xml)
2009-06-02 08:25 PDT, Jonathan Watt [:jwatt] (back in October - email directly if necessary)
no flags Details
patch + disabled test (5.58 KB, patch)
2009-06-03 09:12 PDT, Jonathan Watt [:jwatt] (back in October - email directly if necessary)
no flags Details | Diff | Splinter Review

Description Bryant Howell 2002-01-09 14:52:35 PST
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 2002-01-12 18:48:33 PST
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 2002-01-12 19:06:33 PST
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) 2002-01-12 19:28:51 PST
":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 2002-01-12 19:34:46 PST
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 2002-01-12 19:38:50 PST
er, i mean "if there is only one :hover rule in the stylesheet"
Comment 6 Bradley Baetz (:bbaetz) 2002-01-12 20:43:34 PST
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 2004-05-21 12:47:27 PDT
Updated the test URL (link was broken).
Comment 8 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2004-09-15 11:36:33 PDT
Mass reassign of SVG bugs that aren't currently being worked on by Alex to
general@svg.bugs. 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 2004-12-21 12:03:13 PST
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 2004-12-21 12:32:52 PST
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] (back in October - email directly if necessary) 2009-04-29 23:46:25 PDT
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 [:bz] 2009-04-30 00:09:58 PDT
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 [:bz] 2009-04-30 00:14:43 PDT
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] (back in October - email directly if necessary) 2009-04-30 00:43:20 PDT
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 [:bz] 2009-04-30 00:52:11 PDT
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] (back in October - email directly if necessary) 2009-06-02 06:19:05 PDT
Created attachment 381062 [details] [diff] [review]
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 [:bz] 2009-06-02 06:48:25 PDT
Does sending mouse events via window utils not trigger hover state?
Comment 18 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2009-06-02 06:59:59 PDT
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 [:bz] 2009-06-02 07:10:18 PDT
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] (back in October - email directly if necessary) 2009-06-02 08:25:18 PDT
Created attachment 381074 [details]
(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] (back in October - email directly if necessary) 2009-06-02 08:29:08 PDT
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 [:bz] 2009-06-02 08:37:15 PDT
OK.  We can stick to manual testing for now...
Comment 23 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2009-06-02 08:53:57 PDT
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) (Exited; email my personal email if necessary) 2009-06-02 11:26:11 PDT
Comment on attachment 381062 [details] [diff] [review]
patch

viewMgr can't be null here.
Comment 25 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-06-02 11:53:35 PDT
(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] (back in October - email directly if necessary) 2009-06-03 09:12:37 PDT
Created attachment 381316 [details] [diff] [review]
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 [:bz] 2009-06-03 09:19:29 PDT
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] (back in October - email directly if necessary) 2009-06-11 12:53:54 PDT
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] (back in October - email directly if necessary) 2009-06-11 12:56:11 PDT
Weird. History says I did get r+. Wonder where it went.

Anyways, FIXED I guess.
Comment 30 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2009-06-11 12:56:32 PDT
Thanks for pointing out the fix bz.
Comment 31 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-06-11 13:10:57 PDT
The mochitest here could also end up looking a lot like test_hover.html, except with SVG in it :-)
Comment 32 Boris Zbarsky [:bz] 2009-06-11 14:12:17 PDT
> 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 2009-06-11 17:01:52 PDT
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 2010-07-16 11:08:35 PDT
No news in the last year? Still orange on linux unit tests?
Comment 35 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2012-02-01 11:18:51 PST
Seemed to pass Try, so pushed to m-i:

https://hg.mozilla.org/integration/mozilla-inbound/rev/f91f161171dd
Comment 36 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2012-02-02 03:31:28 PST
https://hg.mozilla.org/mozilla-central/rev/f91f161171dd

Note You need to log in before you can comment on or make changes to this bug.