152978 - [have-fix] Mac: Flash "drags" like an image would if you put the browser in the background and bring it to the foreground again

Status: VERIFIED FIXED

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

Description

[Peter Lubczynski]

Using a Mac Classic build, go take a look at sites using Flash to generate
scrollbars such as:

http://www.natzke.com
http://www.hardrockhotel.com

Notice when dragging the scroller thumb, you are able to drag the entire flash
animation. This makes it difficult to navigate using these kind of scrollers.

Comment 1

[Peter Lubczynski]

This happens on OSX too.

[internal] testcase:
http://warp.mcom.com/u/peterlubczynski/mmdragbug/ObjectMCLoader.html
Go to test 18. Click outside the browser then clicking inside Flash while
dragging causes this bug.

Comment 2

[Peter Lubczynski]

*** Bug 146916 has been marked as a duplicate of this bug. ***

Comment 3

[Peter Lubczynski]

*** Bug 136116 has been marked as a duplicate of this bug. ***

Comment 4

[Chris Casciano]

Comment carried over from  Bug 136116 - This seems to work fine for me in the
build I'm currently running (Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US;
rv:1.1a) Gecko/20020613)... Does anyone know what changed? What patch went in
that might have hit this stuff?

Comment 5

[Peter Lubczynski]

So pinkerton sent beard this message which clues in on how to fix this bug:

Patrick Beard wrote:
Scratch that, I can easily get into a dragging outline state when doing simple
mouse tracking on a button. Click in a button while watching a chess game at
pogo.com, and while tracking, move the mouse. How can we notify our window's
drag handler that we are doing mouse tracking in a plugin? This is a very
serious problem with using Java to play games in the Mac OS X browser builds.

you can put a dragGesture handler on the plugin's DOM node when you create the
frame, and have that always call event.PreventBubble() to keep the event from
going up to the drag handler of the content area.

--------
So, looks like the object frame needs to implement a nsIDOMDragListener and
consume the event like it does for all the other DOM listeners.

Comment 6

[Peter Lubczynski]

Attachment: possible patch?

This patch seems to fix the drag probelms for me on Carbon and Classic builds.

Comment 7

[Peter Lubczynski]

Steps to reproduce (from bug 136116):

1) visit site at http://dplusplus.de
2) click to "information" section (bottom left link)
3) click/place focus in the chrome location field to pull focus away from the
flash movie
4) click & drag the center part of the scroller.

Comment 8

[Brian Nesse (gone)]

*** Bug 144827 has been marked as a duplicate of this bug. ***

Comment 9

[Brian Nesse (gone)]

Comment on attachment 89302 [details] [diff] [review]
possible patch?

r=bnesse. Does this need to happen for full page plugins too?

Comment 10

[Brian Nesse (gone)]

This is a major functionality improvement and should go on the branch.

Comment 11

[Peter Lubczynski]

Full page plugins don't have a DOM yet so it's not possible to hook up DOM
listeners. :( 

However, when bug 90256 is fixed with a synthetic document, full-page plugins
should inherit this fix.

Simon, can I get a super review?

Comment 12

[rubydoo123]

added impact and nsbeta1+

Comment 13

[Simon Fraser [no longer active]]

Do we want this for MachO builds too? If so, you need defined(XP_MAC) ||
defined(XP_MACOSX).

Comment 14

[Peter Lubczynski]

...but Simon, none of the other Mac-only section in this file are
defined(XP_MACOSX)?? How can plugins work on Mach-O with Paint() and the timer
in an #ifdef XP_MAC?

Comment 15

[Mike Pinkerton (not reading bugmail)]

well then it sounds like we need to patch the rest of the file as well.

Comment 16

[Brian Nesse (gone)]

I expect there is a lot of plugin oriented work that needs to be done and/or
re-visited for the mach-o build... There may even be a bug for that already... I
vaguely remember something assigned to beard...

We can start the process by adding the XP_MACOSX check on this code as it has no
dependencies on any other #ifdef'ed code.

Comment 17

[Peter Lubczynski]

Attachment: patch v.1.1

This patch is the same as the last except all the #ifdef XP_MAC has been
changed to #if defined(XP_MAC) || defined(XP_MACOSX). It doesn't really do
anything different right now becuase plugins don't seem to work at all on Mac
Mozilla Mach-O daily builds. I think some changes in the Chimera branch need to
be merged into the trunk.

Comment 18

[Brian Nesse (gone)]

Comment on attachment 89808 [details] [diff] [review]
patch v.1.1

Yes, I expect that the Chimera branch will be a good place to start from,
though there may be some Cocoa specific fixes there. r=bnesse.

Comment 19

[Peter Lubczynski]

I've filed bug 155256 on myself for merging Chimera changes needed to run
plugins into Mach-O Mozilla.

Comment 20

[Simon Fraser [no longer active]]

Comment on attachment 89808 [details] [diff] [review]
patch v.1.1

sr=sfraser

Comment 21

[Peter Lubczynski]

patch in trunk, marking FIXED.

Comment 22

[shrirang khanzode]

fix looks goodon trunk0708. checked out flash, qktime, shockwave , keyboard, 
mouse events, context menus. 

Comment 23

[Paul Wyskoczka]

Adding adt1.0.1 on behalf of the adt.  Please get drivers approval and check the
fix into the branch.

Comment 24

[chris hofmann]

Comment on attachment 89808 [details] [diff] [review]
patch v.1.1

a=chofmann for 1.0.1

Comment 25

[chris hofmann]

add the fixed1.0.1 keyword after checking into the branch

Comment 26

[Peter Lubczynski]

patch on branch

Comment 27

[R.K.Aa.]

*** Bug 163147 has been marked as a duplicate of this bug. ***

Comment 28

[shrirang khanzode]

working great on 0823 branch builds on os9.x and os x.