Closed Bug 104970 Opened 23 years ago Closed 12 years ago

Cursor is changed by QT plugin even if it is not visible -- QuickTime movie changes cursor when mouse is over it even when it's covered by other browser window or tab

Categories

(Core Graveyard :: Plug-ins, defect, P3)

x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED INVALID
Future

People

(Reporter: bugzilla.mozilla.org, Unassigned)

References

()

Details

(Whiteboard: [PL2:Vendor][THIS IS A QUICKTIME ISSUE -- NOT A MOZILLA ISSUE])

Moz 0.9.5, Win2000 Pro SP2

I noticed this on CNN.  When watching a quicktime movie in the popup window, the
cursor flickers badly in all other moz windows.  In the window playing the
movie, the cursor does not flicker.
actually..i see the exact reverse..the mouse flickers wildly inside the window
that is playing the quicktime plugin.. Outside the window, in another browser
window, the caret behaves. :) ...marking NEW. Luke, can u pls reconfirm ? thx
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reconfirming.  I'm definitely seeing it in the other window.  I'm now using
latest 0.9.5+ nightly 2001110703.

You're not using QuickTime for Java are you? I think Java applets cause the
window with the applet to flicker for me (using JRE 1.3.1).  I guess I'll test &
submit a bug if so...
Actually ignore that - Java applets aren't causing cursor flickering for me at
the moment.  Just QuickTime.  In the other windows.
I'm also seeing this behavior: w2k pro moz build 2001122703
when using quicktime VR in one tab, and switching to another tab or window,
'target' (quicktime) cursor will show. flicks back to normal pointer when mouse
is moving. using win98, build 20020202406, quicktime plugin 5.0.2 (npqtplugin.dll)
joel is correct. The mouse pointer appears as the 'target' cursor when I switch 
tabs and if I move the mouse in exactly the same area where the VR is supposed 
to be on the other tab/window, the pointer flickers alternatig between 'arrow' 
and'target'.

steps:
launch browser, open home page
go here in another window: http://www.kaidan.com/glacier.html
move mouse inside the quicktime movie and ALT+TAB to the previous browser 
window.

Now, move the mouse exactly in the same place where the qktime movie is in the 
second page and see the wild flicker. 
Adding Eric to the bug.

Eric, the cursr events seem to bleed through and through windows. This also
happens in 4.x, I tested this using QT6 as well. We believe this could be a QT
issue, can you help us out here?
Priority: -- → P3
Whiteboard: [QuickTime]
Target Milestone: --- → mozilla1.1beta
 Some QuickTime movies change the cursor when it is within the movie 
region. The wild flickering happens because Mozilla is also setting the 
cursor, even when it is within the movie embed region, so we change it, 
you immediately change it, we change it again, etc, etc. This does not 
happen with NN 4.x or other browsers.
Whiteboard: [QuickTime] → [QuickTime][PL2:NA]
Severity: minor → normal
Target Milestone: mozilla1.1beta → mozilla1.0.2
Target Milestone: mozilla1.0.2 → mozilla1.2beta
Eric, I think what is happening here is different. There is no wild flickering.
The problem is that if QT movie is covered by another browser window or tab and
is not visible it still changes the cursor when mouse is over that region. It
looks like the plugin detects mouse over it but somehow fails to check its own
visibility.

Interesting observation: if when having this kind of cursor you hit Shift button
(which zooms in the movie) one zoom step goes through, and after that the cursor
is fixed.

And I confirm, that this does happen with 4.x browsers too. I am inclined to
think that this is QT issue and updating the Status Whiteboard. If you disagree
please tell us why.
Whiteboard: [QuickTime][PL2:NA] → [QuickTime][PL2:NA][THIS IS A QUICKTIME ISSUE -- NOT A MOZILLA ISSUE]
Summary: playing quicktime movie in one window, cursor filckers in other windows → Cursor is changed by QT plugin even if it is not visible -- QuickTime movie changes cursor when mouse is over it even when it's covered by other browser window or tab
Whiteboard: [QuickTime][PL2:NA][THIS IS A QUICKTIME ISSUE -- NOT A MOZILLA ISSUE] → [PL2:Vendor][THIS IS A QUICKTIME ISSUE -- NOT A MOZILLA ISSUE]
Target Milestone: mozilla1.2beta → Future
*** Bug 182464 has been marked as a duplicate of this bug. ***
*** Bug 253985 has been marked as a duplicate of this bug. ***
*** Bug 271127 has been marked as a duplicate of this bug. ***
*** Bug 231891 has been marked as a duplicate of this bug. ***
*** Bug 306944 has been marked as a duplicate of this bug. ***
*** Bug 331936 has been marked as a duplicate of this bug. ***
*** Bug 338165 has been marked as a duplicate of this bug. ***
*** Bug 351207 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0

I've had same with http://www.apple.com/ca/macbookpro/gallery/qtvr17.html on one tab once switched to another (such as while typing this comment). Cursor flickers when the pointer moves, but also changes to the different QTVR cursors depending on the position of the pointer relative to the invisible plugin. Holding the Control or Shift keys also change the cursor's appearance, and zoom in or out on the QTVR in the background.
jo, stefan, Do you see this on MAC?  (all the dupes here have been windows only)

This could be just one more mozilla+windows-centric oddity.  Unless "It looks like the plugin detects mouse over it but somehow fails to check its own visibility." in comment 9 is true - which Eric had not responded to.
Assignee: serhunt → nobody
QA Contact: shrir → plugins
Available link.(You should disable Flash Player plugin,and enable QuickTime)
http://www.panorama360.jp/viewer.php?utsukushigahara&id=1
If this is still an issue it's a QT plugin issue, not an issue with Gecko. QT is being informed that its clip rect is size zero.

Marking invalid, if somebody wants to press on this please do it via Apple's bug system.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.