flash player mouse position tracking unreliable




Event Handling
18 years ago
10 years ago


(Reporter: neal bedard, Assigned: joki (gone))


Windows NT

Firefox Tracking Flags

(Not tracked)





18 years ago
The 'k.' animation does not always track the mouse. Sometimes can be cleared up
by changing focus or invoking right-click pop-up.

Comment 1

18 years ago
*** Bug 48140 has been marked as a duplicate of this bug. ***

Comment 2

18 years ago
Confirm that it happens - but this is not a plugins bug.
Maybe event handling or xptoolkits?
Ever confirmed: true

Comment 3

18 years ago
Somehow..I fail to see any difference on 4.7 and seamonkey(2000081008m18). 
Changing component to event handling to take a look.
Component: Plug-ins → Event Handling
QA Contact: shrir → janc

Comment 4

18 years ago
reassign : joki
Assignee: av → joki
Hmm.. when I went to the site it said Mac IE 4.5 users not supported, I should 
upgrade (I was using NT and latest Netscape 6 commercial build). Anyway, I 
grabbed some URL from NN 4.x and tried that, but it seemed to get stuck to the 
loading phase.

If someone could try this with some recent build and report the exact 
differences between NN 4.x and Mozilla it would be appreciated.

Comment 6

18 years ago
Evidently they changed the site. I get the same demand to 'upgrade' (that's a 
laugh) to IE 5.0 as Heikki did using M17. Prolly bogus, but it does block access 
to the interesting testcase.

The original "k." case is gone, but you can get to a revised one at 

Using NT commercial build from late last week I do not see any difference to NN 
4.x. mouse position tracking. One difference I noticed was that klicking on the 
OTV news button does not work in Mozilla, but mouse tracking seems to be correct 
as far as I can tell.

Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 8

18 years ago
In looking further, the tracking appears to be inactive on first load until 
something 'happens' (you click the face or the animation 'speaks') for both NN 
4.7x and M17. After this the cursor-follow seems to work. This is different from 
the old testcase, where NN 4.7x would follow from first-load and M17 would not.

What does seem to be messed up is the ability of M17 to properly coordintate 
cursor state with clickables. This may have been the case with the old page too. 

Details - 

The frame has four clickable areas: the there numbered buttons to the left and 
the face bounding-box. In NN 4.7x, these seem to have resonable behavior:  the 
cursor state changes ('finger' icon) when on the clickables, then back when 
moving off.

Not so with M17. Moving into a clickable is okay, but the 'finger' sticks after 
moving off until the cursor is completely out of the frame. Interestingly 
enough, the numbered button on-mouse-over states behave correctly.

This is repeatable and definitely broken in M17. Perhaps reopen?
The finger sticking is a different bug from mouse move. I get the sticky finger 
even from the numbered buttons. Could you open a new bug on that?

Unless someone can come up with a testcase where mouse position tracking does 
not work I am keeping this bug as WFM.

Comment 10

18 years ago
Updating QA Contact.
QA Contact: janc → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok


17 years ago
Keywords: flash, verifyme

Comment 12

17 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 13

17 years ago
verified on build 2001-08-13-trunk


10 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.