All users were logged out of Bugzilla on October 13th, 2018
I'm not sure how critical this is, I guess as a UI issue it is pretty minor but I'm not sure what else might be going on if the cursor is coming through. Clicks don't seem to get through. Anyway, STR: 1. Try the url, hopefully there should be a flash ad in the middle left of the article, maybe refresh a few times till you get one. 2. Move the mouse over the ad, make sure you get the hand pointer. 3. Scroll the page such that the flash ad is half above the view, underneath the tab bar. 4. Move the mouse up into the bottom of the ad, the cursor should change to the hand, keep moving up into the tab bar. At this point on my machine the cursor remains as a hand and continues to do so till it hits the address bar or titlebar when it should be changing back to a regular pointer. The cursor is definately from the flash, if I move left and right it will change back to a pointer at the edges of where the ad must be underneath the tab bar (in effect).
Interesting... This reminds of a Camino trunk bug: bug 381003, that one is not limited to Flash, however.
Flags: blocking1.9? → blocking1.9-
I just experienced this bug in most recent Shiretoko nightly. Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20091025 Firefox/3.1a1pre (.NET CLR 3.5.30729) However it is a wider problem than just bleeding into the chrome... It also shows through onto other tabs of content. Should I create a new bug for that? or is it all related? Actually... if an underlying tab has a strange custom cursor in a flash app, then that cursor would be shown on all other pages at the same screen coordinates. Maybe it the cursor could even be appear as a dialog box and confuse the user, or even open a security issue.
Richard, you should file a separate bug; this sort of bug is typically platform-specific and similar-sounding Mac and Windows bugs may have different causes and need different fixes. Also, something is very confused in your user-agent string; you're reporting a build date of Sunday (26 Oct 09) and a recent nightly Gecko version (188.8.131.52pre), but a Firefox version (3.1a1pre) from months ago. Mossop: I think bug 325558 should have fixed the bug you originally reported here (by resetting the cursor), though it's probably hard to tell now whether it did or not (but see also bug 381003 comment 20; I was convinced that the fix for bug 325558 didn't fully fix bug 325558--even in Firefox, where instead it just made it harder to trigger.)
This website no longer uses flash.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.