I'm going to stop replying to myself now :) I'm getting closer to the answer
and I think I can walk it in from here.
And thank you Dan -- you were actually much closer to the actual issue than
my earlier hypotheses. Animate is not killing hoverIntent, but it is
(occasionally) delaying one of the polling intervals, so that two are firing
in very close succession.
Hopefully my next posting will have an official "ready for production"
plug-in announcement. :)
Brian.
On 3/25/07, Brian Cherne <[EMAIL PROTECTED]> wrote:
I've updated the Firebug console.log messages. They are now showing:
- coordinates from the polling interval
- message when previous == current
- message when mouseOut function is called
An example of console.log:
c= 444 956
c= 448 958
c= 485 939
c= 458 910
c= 424 951
c= 459 966
c= 440 925
li.p4; makeShort(){ animate() }
c= 349 919
c= 349 919
li.p3; previous == current; makeTall()
... and there was no way my mouse was stationary at 349, 919.
Note: It appears that animate() only needs to be called to kill mouseMove.
It is not animate returning anything.
Note: If I add a console.log() to hoverIntent's handleHover, to show when
a mouseover has been triggered, this bug goes away. Adding console.log()
to mouseMove also alters the playing field. I really hate it when taking a
measurement alters your experiment in a significant way.
Note: This bug does not happen on my Mac in Firefox. It only happens in
Firefox on my WinXP laptop.
Later today/tomorrow I'll test a few other machines and report back. (I
hope it's not just my laptop). I will also try storing the console.log()
output in a buffer string to see if I can get any meaningful data from
mouseMove/handleHover.
Brian.
On 3/24/07, Brian Cherne < [EMAIL PROTECTED]> wrote:
>
> If the mouse is in the target zone and you're moving it, the mouseOver
> event should not be triggered. You can test this by mousing over just one of
> the "target" LI tags. If you stay within that LI and keep your mouse moving
> the sensitivity threshold is never met (because for sake of testing I
> reduced it to 1... so the mouse has to be motionless for the threshold to be
> crossed).
>
> When you mouseOut of li.p4 into li.p3 (for example), li.p3's mouseOver
> event should not be triggered as long as your mouse is moving. However,
> li.p4's mouseOut function for some reason trips up li.p3's hoverIntent
> function... or more specifically li.p3's mousemove listener. Without
> that listener the coordinates for your mouse do not update, so the polling
> interval (which compares coordinates) thinks your mouse has stopped moving.
>
> Turning the polling interval down would only speed up this last step
> (coordinate comparison). Otherwise it has no effect. Once this bug is fixed,
> I'll dial it down and increase the threshold to an acceptable level.
>
> Removing animate() from the mouseOut function is the only thing that
> stops this bug from happening.
>
> In Firebug, I'm logging what object (li) is inside
> compareMouseCoordinates(). If you change that to show the mouse coordinates,
> you'll see that they are "frozen" after another li's animate mouseOut
> function is called.
>
> Brian.
>
>
>
> On 3/24/07, Dan G. Switzer, II < [EMAIL PROTECTED]> wrote:
>
> > Brian,
> >
> >
> >
> > From my playing around it seems that it gets triggered because mouse
> > is in the target zone at each check (even though it's been moved around a
> > lot.) Does the bug go away if you lower the interval way down?
> >
> >
> >
> > -Dan
> >
> >
> > ------------------------------
> >
> > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > *On Behalf Of *Brian Cherne
> > *Sent:* Saturday, March 24, 2007 7:44 PM
> > *To:* jQuery Discussion
> > *Subject:* [jQuery] hoverIntent r3 -- animate vs. hoverIntent
> >
> >
> >
> > I've re-written hoverIntent since the last time I posted. It now has
> > configurable options, a mouseOut timeout, and is $-friendly.
> >
> > However, not all is good in the land of hoverIntent. I've been
> > struggling with this one bug for a while (hence the delay since my last
> > update) and I've finally (sucked up my pride and) decided to approach the
> > list for help.
> >
> > I have some example code on my web site that explains the problem in
> > detail.
> > <http://cherne.net/brian/resources/jquery.hoverIntent.html >
> > (demo requires Firefox and Firebug)
> >
> > Simply put, when multiple instances of hoverIntent are in-play the
> > mouseOut of one can kill the mouseMove of another. This happens when the
> > mouseOut uses animate(). Functions like html() do not kill the other
> > instance of hoverIntent.
> >
> > And when hoverIntent is killed, the polling interval lives on
> > (presumably because timers/intervals live in a different context).
> > Unfortunately, the mouseMove function of hoverIntent isn't updating the
> > "current" set of mouse coordinates (because it was killed), so the polling
> > interval compares frozen coordinates and of course they're the same, thus
> > triggering an accidental mouseOver.
> >
> > I can see the symptoms, but I don't understand what's going on. Can
> > someone explain what's happening and suggest a way to fix it? And why it
> > breaks with animate() but not html() is also a mystery...
> >
> > Note, this problem exists in the much simpler r1. It is not something
> > I introduced with the inclusion of the mouseOut timeout.
> >
> > Thanks in advance,
> >
> > Brian.
> >
> > _______________________________________________
> > jQuery mailing list
> > discuss@jquery.com
> > http://jquery.com/discuss/
> >
> >
>
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
