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

VERIFIED FIXED in mozilla1.0.1

Status

()

P3
normal
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: peterlubczynski-bugs, Assigned: peterl-bugs)

Tracking

Trunk
mozilla1.0.1
PowerPC
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT2 RTM][PL RTM][verified-trunk], URL)

Attachments

(1 attachment, 1 obsolete attachment)

7.52 KB, patch
bnesse
: review+
sfraser_bugs
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
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.
OS: Mac System 9.x → All
Summary: [flash] Mac Classic: dragging causes too much to be dragged → [flash] Mac: dragging Flash causes too much to be dragged
(Reporter)

Updated

17 years ago
Summary: [flash] Mac: dragging Flash causes too much to be dragged → [flash] Mac: Flash "drags" like an image would if you put the browser in the background and bring it to the foreground again
(Reporter)

Comment 2

17 years ago
*** Bug 146916 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 3

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

Comment 4

17 years ago
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?

Updated

17 years ago
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta
(Reporter)

Comment 5

17 years ago
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.
Status: NEW → ASSIGNED
(Reporter)

Comment 6

17 years ago
Created attachment 89302 [details] [diff] [review]
possible patch?

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

Comment 7

17 years ago
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.

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

Comment 8

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

Comment 9

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

r=bnesse. Does this need to happen for full page plugins too?
Attachment #89302 - Flags: review+
This is a major functionality improvement and should go on the branch.
Keywords: adt1.0.1, mozilla1.0.1
(Reporter)

Comment 11

17 years ago
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?
Keywords: review
Whiteboard: [PL RTM]
Target Milestone: mozilla1.2beta → mozilla1.0.1

Comment 12

17 years ago
added impact and nsbeta1+
Keywords: nsbeta1+
Whiteboard: [PL RTM] → [ADT2 RTM][PL RTM]

Comment 13

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

Comment 14

17 years ago
...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?
well then it sounds like we need to patch the rest of the file as well.
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.
(Reporter)

Comment 17

17 years ago
Created attachment 89808 [details] [diff] [review]
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.
Attachment #89302 - Attachment is obsolete: true
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.
Attachment #89808 - Flags: review+
(Reporter)

Comment 19

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

Comment 20

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

sr=sfraser
Attachment #89808 - Flags: superreview+
(Reporter)

Comment 21

17 years ago
patch in trunk, marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Updated

17 years ago
Keywords: review → approval, verifyme

Comment 22

17 years ago
fix looks goodon trunk0708. checked out flash, qktime, shockwave , keyboard, 
mouse events, context menus. 
Status: RESOLVED → VERIFIED
Keywords: verifyme
Whiteboard: [ADT2 RTM][PL RTM] → [ADT2 RTM][PL RTM][verified-trunk]

Comment 23

17 years ago
Adding adt1.0.1 on behalf of the adt.  Please get drivers approval and check the
fix into the branch.
Keywords: adt1.0.1 → adt1.0.1+

Comment 24

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

a=chofmann for 1.0.1
Attachment #89808 - Flags: approval+

Comment 25

17 years ago
add the fixed1.0.1 keyword after checking into the branch
Keywords: mozilla1.0.1 → mozilla1.0.1+
(Reporter)

Comment 26

17 years ago
patch on branch
Keywords: approval, mozilla1.0.1+ → fixed1.0.1

Comment 27

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

Comment 28

17 years ago
working great on 0823 branch builds on os9.x and os x.
Keywords: fixed1.0.1 → verified1.0.1
You need to log in before you can comment on or make changes to this bug.