Closed Bug 181364 Opened 22 years ago Closed 20 years ago

Dragging is broken in windowless plugins

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows 2000
defect
Not set
normal

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)

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.
--->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
future
Target Milestone: mozilla1.3alpha → Future
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
*** Bug 257816 has been marked as a duplicate of this bug. ***
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)
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 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+
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?
Yeah, I agree. I haven't heard strong arguments for this going in on the branch
yet, I certainly don't have any...
brendan, can you sr so this can get on the trunk?
Assignee: peterl-bugs → jst
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 on attachment 158909 [details] [diff] [review]
Let plugins handle drag events on all platforms.

sr=me.

/be
Attachment #158909 - Flags: superreview?(brendan) → superreview+
1.8a4+ per Asa's comment above now that we've got sr.
Status: NEW → ASSIGNED
Flags: blocking1.8a4- → blocking1.8a4+
Fixed on the trunk.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Attachment #158909 - Flags: approval1.8a4+
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?
So we've seen no comments/regressions related to this?
Nope, no negative comments or regression from this change that I'm aware of.
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+
Fixed on the brances now too.
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
*** Bug 266036 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: