593857 - Flash's buttonMode = true doesn't trigger a pointy cursor, as of 2010-04-06 nightly

Status: RESOLVED DUPLICATE of bug 621117

(Core Graveyard :: Plug-ins, defect)

Description

[Tony]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4) Gecko/20100818 Firefox/4.0b4
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4) Gecko/20100818 Firefox/4.0b4

I'm building ads and flash interfaces using AS3.0, setting a sprite's buttonMode property to true. This should normally trigger the 'pointy' cursor that is standard for a link but doesn't.

Reproducible: Always

Steps to Reproduce:
1. Find a flash file
2. Find a link
3. See the standard cursor!
Actual Results:  
Sadness ensues when the cursor stays the same.

Expected Results:  
I'm meant to know that it's a link with the nice cursor!

Comment 1

[Alex Butin]

Confirming.

Last good nightly: 2010-04-05 First bad nightly: 2010-04-06

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c4df407008b5&tochange=523d0f8e0926

Comment 2

[Ed Morley [:emorley]]

Marking as new, given comment 1.

Tony/Alex, does this affect all controls or just links? eg: Does this affect say hovering over the play/pause button on Youtube? (Which WFM using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre ID:20110222191848).

Alex, from bug 635878 I gather you are using Flash 10.2.152.26 debug. Does this occur using the non debug build as well?

Tony, what version of Flash are you using?

Comment 3

[Ed Morley [:emorley]]

Just taken a look at the regression range.

Possible candidates (though somewhat guessing here) might be:

Jim Mathies — Bug 552062 - [OOPP] Black Background on certain Flash Objects. r=bent.
http://hg.mozilla.org/mozilla-central/rev/d31c87f6d202

Jim Mathies — Bug 535295 - [OOPP] Tearing/Repainting issues with flash videos, their controls and other page content during/after scrolling. r=roc.
http://hg.mozilla.org/mozilla-central/rev/3549ea4a9bd9

CC'ing Jim for opinion.

Comment 4

[Tony]

The YouTube play/pause button isn't triggering the pointer cursor either.

Flash version: "You have version 10,1,102,64 installed" (from Adobe). This is still appearing in Beta 9. Is there anything you need me to check out at this end?

Comment 5

[Ed Morley [:emorley]]

Thanks for the quick response Tony :-)

Could you see if it still occurs using a clean profile and the latest nightly please:
http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_make-a-new-profile
http://nightly.mozilla.org/

Comment 6

[Jim Mathies [:jimm]]

(In reply to comment #3)
> Just taken a look at the regression range.
> 
> Possible candidates (though somewhat guessing here) might be:
> 
> Jim Mathies — Bug 552062 - [OOPP] Black Background on certain Flash Objects.
> r=bent.
> http://hg.mozilla.org/mozilla-central/rev/d31c87f6d202
> 
> Jim Mathies — Bug 535295 - [OOPP] Tearing/Repainting issues with flash videos,
> their controls and other page content during/after scrolling. r=roc.
> http://hg.mozilla.org/mozilla-central/rev/3549ea4a9bd9
> 
> CC'ing Jim for opinion.

Might want to look for a newer regression range / different set of patches. The first change isn't in use anymore, and the second has to do with updating the window in response to a paint event in the browser. That really shouldn't have any effect on cursor settings.

Can someone put together a simple test case that can be posted to the bug?

Comment 7

[Ed Morley [:emorley]]

The range was much larger than those two, I just plucked them out as they were plugin related.

Is a testcase needed, seeing as simply hovering over a youtube play/pause demonstrates the issue (for Tony/Alex above, using OS X ; it WFM using Win7)?

Comment 8

[Ed Morley [:emorley]]

Can someone who can build locally please reduce the regression range in comment 1 further - thanks!

Comment 9

[Jim Mathies [:jimm]]

Ok, those csets threw me off, this is Mac OS specific. cc'ing Josh.

Youtube cursors (arrow over video, hand over buttons) are WFM on Windows 7 as well.

Comment 10

[Tony]

No luck. Still no cursor on the nightly, with a new profile and all other extensions/plugins disabled. I have xcode, is there anything else I need to compile the source? Can get around to it later tonight (4 or 5 hours away).

Comment 11

[Ed Morley [:emorley]]

(In reply to comment #9)
> Ok, those csets threw me off

Yeah sorry about that, I just felt that if I didn't at least try and have a stab at a possible cause cset, the bug would just sit here UNCO whilst beta 12/the RC came and went; even though gut feeling was that it's OS X reproducible and possibly a softblocker. I was going to nominate for blocking to try and get visibility (especially given that we have a regression range), but it would just have been minused by Mike due to being UNCO; so wasn't really sure what else to try.

Comment 12

[Ed Morley [:emorley]]

I'm mixing up bugs now (clearly too tired to be doing this), ignore comment 11.

Comment 13

[Alex Butin]

Still no cursor on the RC1. Are you kidding us!?!?!?

Comment 14

[Ed Morley [:emorley]]

Hi Alex, this has the regressionwindow-wanted keyword (since the current 24 hr range still contains a lot of changesets and would be good for someone to build locally and narrow it) and also the qawanted keyword; but no one seems to have noticed yet, sorry.

In the meantime, can you answer:

> Alex, from bug 635878 I gather you are using Flash 10.2.152.26 debug. Does this
> occur using the non debug build as well?

At this point I doubt it's going to block Fx4; seeing as the regression occurred almost a year ago and only two confirmations so far. (And it WFM; so isn't broken for everyone).

Have both of you tried with safe mode and also a clean profile?
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Basic+Troubleshooting#w_make-a-new-profile

Comment 15

[Alex Butin]

OK, I understand, but it seems Mozilla wants to release FF with some major bugs... IMHO feature to differ clickable and non-clickable elements is very important! It's the same like to ignore links underlining!

Comment 16

[Josh Aas]

This is bug 621117.