Closed
Bug 181364
Opened 22 years ago
Closed 20 years ago
Dragging is broken in windowless plugins
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: dmeketa, Assigned: jst)
References
Details
(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: [PL2:NA],top100)
Attachments
(2 files)
934 bytes,
application/x-zip-compressed
|
Details | |
3.53 KB,
patch
|
bzbarsky
:
review+
brendan
:
superreview+
asa
:
approval-aviary+
asa
:
approval1.7.5+
asa
:
approval1.8a4+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 When I click and drag within a windowless plugin, the plugin should receive appropriate mouse events so that I can perform plugin-specific dragging. Instead, the very first drag within a windowless plugin works, and all subsequent drags fail; as soon as the drag has gone more than a few pixels, the cursor changes to a no-drop icon and the plugin stops receiving mouse events. I am an engineer on the Flash Player team. The Flash Player uses drag events for text selection and arbitrary ActionScript event handlers. Windowless support in our Mozilla plug-in is a new feature as I write this. Right now, in order to see this occur in the Flash Player, you will need to visit http://www.macromedia.com/software/flashplayer/special/beta/ to get the beta player. As of (most likely) about 12/12/02, the publicly released player will include Mozilla windowless support. Reproducible: Always Steps to Reproduce: 1. Install a Flash Player plugin that supports windowless mode as described in the Details. 2. Open FlashWindowlessText.html, which I will attach shortly. 3. Click and drag inside the text in the Flash plugin. 4. Repeat step 3. Actual Results: The mouse pointer soon turns to a no-drop icon and text selection stops moving. Expected Results: Should recognize that the drag is within a windowless plugin, and allow mouse events to continue flowing to the plugin via NPP_HandleEvent. This is how non-windowless plugins work. When the plugin is in *transparent* windowless mode, the plugin should only receive mouse events if the drag started inside the non-transparent region of the plugin. When the plugin is in *opaque* windowless mode, the plugin should receive mouse events for any drag that begins within its bounding box.
Reporter | ||
Comment 1•22 years ago
|
||
Comment 2•22 years ago
|
||
--->this one's mine...been talking with Deneb over e-mail.
Assignee: beppe → peterl
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.3alpha
Comment 4•20 years ago
|
||
Peter, any luck with this bug? I still see it with Mozilla 1.7/WinXp and Flash 7.0 r19
Whiteboard: [PL2:NA] → [PL2:NA],top100
Comment 5•20 years ago
|
||
*** Bug 257816 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 6•20 years ago
|
||
Assignee | ||
Comment 7•20 years ago
|
||
Comment on attachment 158909 [details] [diff] [review] Let plugins handle drag events on all platforms. Who knows what this'll break, but I've tested this with the flash player on Windows and Linux (and there's no change on the mac here), and things appear to be working just fine. I can't ever imagine us wanting to be able to drag a plugin around, so this makes sense to me. I see no other way to get this validated than checking it in and waiting for feedback...
Attachment #158909 -
Flags: superreview?(brendan)
Attachment #158909 -
Flags: review?(bzbarsky)
Comment 8•20 years ago
|
||
if results look good we should think about this for aviary 1.0 based on some feedback about the value of this fix to some sites that are beefing up flash use.
Flags: blocking1.8a4+
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
Comment 9•20 years ago
|
||
Comment on attachment 158909 [details] [diff] [review] Let plugins handle drag events on all platforms. r=bzbarsky, but I would be rather against landing this on branches without heavy testing on the trunk (like a release cycle or so).
Attachment #158909 -
Flags: review?(bzbarsky) → review+
Reporter | ||
Comment 10•20 years ago
|
||
Cool, glad to see a fix proposed. I'm happy to help test if anyone would like. I'm not familiar with Mozilla's build/release process, so could someone let me know whenever there's a build that needs testing, and where to get it?
Assignee | ||
Comment 11•20 years ago
|
||
Yeah, I agree. I haven't heard strong arguments for this going in on the branch yet, I certainly don't have any...
Comment 12•20 years ago
|
||
brendan, can you sr so this can get on the trunk?
Assignee: peterl-bugs → jst
Comment 13•20 years ago
|
||
I don't see this moving and we're trying to get a4 out the door. If this gets review in time, we can take it, but I don't think we should block on it.
Flags: blocking1.8a4+ → blocking1.8a4-
Comment 14•20 years ago
|
||
Comment on attachment 158909 [details] [diff] [review] Let plugins handle drag events on all platforms. sr=me. /be
Attachment #158909 -
Flags: superreview?(brendan) → superreview+
Assignee | ||
Comment 15•20 years ago
|
||
1.8a4+ per Asa's comment above now that we've got sr.
Status: NEW → ASSIGNED
Flags: blocking1.8a4- → blocking1.8a4+
Assignee | ||
Comment 16•20 years ago
|
||
Fixed on the trunk.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Attachment #158909 -
Flags: approval1.8a4+
Assignee | ||
Comment 17•20 years ago
|
||
Comment on attachment 158909 [details] [diff] [review] Let plugins handle drag events on all platforms. Requesting approval for branches.
Attachment #158909 -
Flags: approval1.7.x?
Attachment #158909 -
Flags: approval-aviary?
Comment 18•20 years ago
|
||
So we've seen no comments/regressions related to this?
Assignee | ||
Comment 19•20 years ago
|
||
Nope, no negative comments or regression from this change that I'm aware of.
Comment 20•20 years ago
|
||
Comment on attachment 158909 [details] [diff] [review] Let plugins handle drag events on all platforms. a=asa for branches checkins.
Attachment #158909 -
Flags: approval1.7.x?
Attachment #158909 -
Flags: approval1.7.x+
Attachment #158909 -
Flags: approval-aviary?
Attachment #158909 -
Flags: approval-aviary+
Assignee | ||
Comment 21•20 years ago
|
||
Fixed on the brances now too.
Keywords: fixed-aviary1.0,
fixed1.7.x
Updated•20 years ago
|
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
Comment 22•20 years ago
|
||
*** Bug 266036 has been marked as a duplicate of this bug. ***
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•