Closed
Bug 181364
Opened 23 years ago
Closed 21 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•23 years ago
|
||
Comment 2•23 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•21 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•21 years ago
|
||
*** Bug 257816 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 6•21 years ago
|
||
Assignee | ||
Comment 7•21 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•21 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•21 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•21 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•21 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•21 years ago
|
||
brendan, can you sr so this can get on the trunk?
Assignee: peterl-bugs → jst
Comment 13•21 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•21 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•21 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•21 years ago
|
||
Fixed on the trunk.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Attachment #158909 -
Flags: approval1.8a4+
Assignee | ||
Comment 17•21 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•21 years ago
|
||
So we've seen no comments/regressions related to this?
Assignee | ||
Comment 19•21 years ago
|
||
Nope, no negative comments or regression from this change that I'm aware of.
Comment 20•21 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•21 years ago
|
||
Fixed on the brances now too.
Keywords: fixed-aviary1.0,
fixed1.7.x
Updated•21 years ago
|
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
Comment 22•21 years ago
|
||
*** Bug 266036 has been marked as a duplicate of this bug. ***
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•