The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla13

Status

()

Core
SVG
RESOLVED FIXED
15 years ago
5 years ago

People

(Reporter: Bryant Howell, Assigned: jwatt)

Tracking

Trunk
mozilla13
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

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

Comment 1

15 years ago
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?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
":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.
that seems really strange. Then if only one element has :hover set then you 
would never be able to "unhover" it?
er, i mean "if there is only one :hover rule in the stylesheet"
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

Updated

13 years ago
Depends on: 20022

Comment 7

13 years ago
Updated the test URL (link was broken).
(Assignee)

Comment 8

13 years ago
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. 
Assignee: alex → general

Comment 9

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

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

Comment 11

8 years ago
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?
OS: Windows 98 → All
Hardware: x86 → All
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?
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.
(Assignee)

Comment 14

8 years ago
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.
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!  ;)
(Assignee)

Updated

8 years ago
Depends on: 470845
No longer depends on: 20022
(Assignee)

Comment 16

8 years ago
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.
Does sending mouse events via window utils not trigger hover state?
(Assignee)

Comment 18

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

Comment 20

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

Comment 21

8 years ago
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
OK.  We can stick to manual testing for now...
(Assignee)

Comment 23

8 years ago
Comment on attachment 381062 [details] [diff] [review]
patch

Any opinions on how we should proceed to enable this case to be tested longer term?
Attachment #381062 - Flags: review?(roc)
Comment on attachment 381062 [details] [diff] [review]
patch

viewMgr can't be null here.
Attachment #381062 - Flags: review?(roc) → review+
(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.
(Assignee)

Comment 26

8 years ago
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.
Attachment #381062 - Attachment is obsolete: true
Attachment #381074 - Attachment is obsolete: true
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.
(Assignee)

Comment 28

8 years ago
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?
Flags: in-testsuite+
Summary: Blue star retains opacity even when it has moved out of mouseover → SVG elements to which :hover apply do not restyle when moved under the mouse pointer
(Assignee)

Comment 29

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

Anyways, FIXED I guess.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 30

8 years ago
Thanks for pointing out the fix bz.
The mochitest here could also end up looking a lot like test_hover.html, except with SVG in it :-)
> 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.
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: general → nobody
QA Contact: bbaetz → general

Comment 34

7 years ago
No news in the last year? Still orange on linux unit tests?
(Assignee)

Updated

5 years ago
(Assignee)

Comment 35

5 years ago
Seemed to pass Try, so pushed to m-i:

https://hg.mozilla.org/integration/mozilla-inbound/rev/f91f161171dd
Assignee: nobody → jwatt
Target Milestone: --- → mozilla13
(Assignee)

Comment 36

5 years ago
https://hg.mozilla.org/mozilla-central/rev/f91f161171dd
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.