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.
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
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
*** Bug 146916 has been marked as a duplicate of this bug. ***
*** Bug 136116 has been marked as a duplicate of this bug. ***
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?
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
Created attachment 89302 [details] [diff] [review] possible patch? This patch seems to fix the drag probelms for me on Carbon and Classic builds.
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.
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
*** Bug 144827 has been marked as a duplicate of this bug. ***
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
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?
Whiteboard: [PL RTM]
Target Milestone: mozilla1.2beta → mozilla1.0.1
added impact and nsbeta1+
Whiteboard: [PL RTM] → [ADT2 RTM][PL RTM]
Do we want this for MachO builds too? If so, you need defined(XP_MAC) || defined(XP_MACOSX).
...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.
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+
I've filed bug 155256 on myself for merging Chimera changes needed to run plugins into Mach-O Mozilla.
Comment on attachment 89808 [details] [diff] [review] patch v.1.1 sr=sfraser
Attachment #89808 - Flags: superreview+
patch in trunk, marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
fix looks goodon trunk0708. checked out flash, qktime, shockwave , keyboard, mouse events, context menus.
Status: RESOLVED → VERIFIED
Whiteboard: [ADT2 RTM][PL RTM] → [ADT2 RTM][PL RTM][verified-trunk]
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 on attachment 89808 [details] [diff] [review] patch v.1.1 a=chofmann for 1.0.1
Attachment #89808 - Flags: approval+
add the fixed1.0.1 keyword after checking into the branch
Keywords: mozilla1.0.1 → mozilla1.0.1+
patch on branch
Keywords: approval, mozilla1.0.1+ → fixed1.0.1
*** Bug 163147 has been marked as a duplicate of this bug. ***
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.