Closed Bug 119061 Opened 23 years ago Closed 12 years ago

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

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla13

People

(Reporter: BryanZx, Assigned: jwatt)

References

(
URL
)

Details

Attachments

(1 file, 2 obsolete files)

patch + disabled test
5.58 KB, patch
Details | Diff | Splinter Review 
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?
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
Depends on: 20022
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
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.
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
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.
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!  ;)
Depends on: 470845
No longer depends on: 20022
Attached patch patch (obsolete) — — Splinter Review 
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?
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.
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
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...
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.
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.
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
Weird. History says I did get r+. Wonder where it went.

Anyways, FIXED I guess.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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
No news in the last year? Still orange on linux unit tests?
Seemed to pass Try, so pushed to m-i:

https://hg.mozilla.org/integration/mozilla-inbound/rev/f91f161171dd
Assignee: nobody → jwatt
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/f91f161171dd
Status: REOPENED → RESOLVED
Closed: 15 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: