Closed Bug 477077 Opened 14 years ago Closed 14 years ago

Flash activate-on-mouseover buttons/links don't work if in top 22 pixels of plugin

Categories

(Core Graveyard :: Plug-ins, defect)

1.9.1 Branch
x86
macOS
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: stephend, Unassigned)

References

()

Details

(Keywords: regression, verified1.9.1)

Summary: Flash links on Akamai.com don't respond to hover/mouse clicks

Build ID:  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20090205 Shiretoko/3.1b3pre

Steps to Reproduce:

1. Using the nightly 3.1 candidates on 10.4 (Marcia can't reproduce on 10.5), load http://www.akamai.com
2. Try to click any of the "About," "Careers," "Press," etc. links
This is similar to what I reported in bug 463169, but whereas that bug is sporadic, this is a clear regression that's 100% reproducible.
Flags: blocking1.9.1?
This doesn't happen on the 1.9.0 branch, or on Windows or Linux.

And it's a recent regression -- it doesn't happen with the 2009-01-12 nightlies.

It's not convenient for me right now to try to find the regression range -- I'm downloading Apple's new SnowLeopard seed over a 1.5Mbit ADSL connection.

Could someone else please find it?
Forgot to mention that I have no problems reproducing this on OS X 10.5.6.
This regressed between 20090123 and 20090124; if someone can figure out the HG-changeset-finding magic before I can, please post here :-)
My patch for bug 474491 triggered this bug.

I'm almost certain this means the current Flash plugin uses the CoreGraphics drawing mode -- which neither Josh nor I were aware of.

I'll look into this further later this afternoon.

But in any case my patch for bug 474491 will need to be backed out.
Depends on: 474491
> I'm almost certain this means the current Flash plugin uses the CoreGraphics
> drawing mode -- which neither Josh nor I were aware of.

Brain fart.  Of course Flash uses the CoreGraphics mode.
I knew that it uses CG, that's why I asked for Flash to be tested specifically :)
This is really unfortunate. Presumably Flash works correctly in Safari where bug 474491 doesn't exist.
I *did* test my patch (for bug 474491) on several different Flash
plugins.  Unfortunately, none of then had buttons at the very top that
are only activated by mousing over them (as do at least two Flash
plugins on the Akamai page).

And by the way, this bug doesn't effect mouse-downs:  To see this for
yourself, try right-clicking (or ctrl-left-clicking) anywhere in a
Flash plugin -- you'll always get a Flash-specific context menu.

I've checked Flash 10 (Adobe's latest version) and Flash 9 (r151, the
latest version from Apple's Software Update) -- both are effected by
this bug, on both OS X 10.4.11 and 10.5.6.  So it puzzles me that
Marcia wasn't able to reproduce this bug on 10.5.6.

But in any case I'm going to have to back out my patch for bug 474491.

What's the protocol for that?  Should I just go ahead and to it?  Do I
need reviews?
Summary: Flash links on Akamai.com don't respond to hover/mouse clicks → Flash activate-on-mouseover buttons/links don't work if in top 22 pixels of plugin
> 2. Try to click any of the "About," "Careers," "Press," etc. links

Interestingly, you can get any of these buttons to work by mousing over its very bottom.  So they must be slightly more than 22 pixels high.
Fixed by backing out patch for bug 474491.
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Is it possible that Adobe added a workaround in Flash for Gecko based browsers ?
(In reply to comment #13)
> Is it possible that Adobe added a workaround in Flash for Gecko based browsers
> ?

https://bugzilla.mozilla.org/show_bug.cgi?id=474491#c18 explicitly states that, yes.
How do we get out of this circle, Adobe can't remove the code and we can't fix it because it's broken with the workaround ?
(In reply to comment #15)

One way would be for us and the major plugin vendors (those that support the CoreGraphics drawing mode) to agree that this bug will be fixed as of a given release, and make sure we bump NP_VERSION_MINOR as an indication that it's been fixed.

That way a plugin could check NP_VERSION_MINOR to see if the bug exists or not, and find out whether or not it has to work around it.
> this bug will be fixed ...

Bug 474941.
Verified FIXED on the 1.9.1 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20090207 Shiretoko/3.1b3pre
Verified FIXED on trunk too, thanks:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2a1pre) Gecko/20090207 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
Flags: blocking1.9.1? → blocking1.9.1+
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.