when draging tab to content area aEvent.screenX/Y in _onDragEnd is always 0 (breaks tab tearing)

RESOLVED FIXED in Firefox 3.6a1

Status

()

P1
normal
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: alice0775, Assigned: enndeakin)

Tracking

({regression, verified1.9.1})

Trunk
Firefox 3.6a1
x86
Windows XP
regression, verified1.9.1
Points:
---
Bug Flags:
blocking-firefox3.5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090417 Firefox/3.5.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090417 Firefox/3.5.0

After fixed Bug 466379 -  Need mouse-pointer coordinates in the dragend event ,
when draging tab to content area aEvent.screenX/Y in _onDragEnd is always 0

See https://bugzilla.mozilla.org/show_bug.cgi?id=475066#c69


Reproducible: Always

Actual Results:  
0 is always returned. 

Expected Results:  
The right coordinates are returned.
(Reporter)

Updated

10 years ago
Blocks: 466379
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

10 years ago
Flags: wanted-firefox3.5?
Keywords: regression
Version: unspecified → 3.1 Branch

Updated

10 years ago
Summary: when draging tab to content area aEvent.screenX/Y in _onDragEnd is always 0 → when draging tab to content area aEvent.screenX/Y in _onDragEnd is always 0 (breaks tab tearing)

Updated

10 years ago
Version: 3.1 Branch → Trunk
This will stop tearing off tabs into content area. See referenced comment in comment 0. Asking for blocking FF3.5.
Flags: blocking-firefox3.5?

Updated

10 years ago
Flags: wanted-firefox3.5?
Mano: can you please look into this, if you need Windows testing, co-ordinate with someone on IRC, preferably Enn.

Enn: can you please determine why _onDragEnd is returning 0 in this case?
Assignee: nobody → mano
(Assignee)

Comment 3

10 years ago
Created attachment 373717 [details] [diff] [review]
handle this when a drop occurs as well

Haven't tested this on Windows yet.
Assignee: mano → enndeakin
Status: NEW → ASSIGNED
Jim: can you help Neil out on this?
Flags: blocking-firefox3.5? → blocking-firefox3.5+
Priority: -- → P1

Comment 5

10 years ago
Created attachment 373739 [details] [diff] [review]
handle this when a drop occurs as well v2

Just a slight update for win. The drag end event in FireDragEventAtSource had values that were populated correctly.
Attachment #373717 - Attachment is obsolete: true
Attachment #373739 - Flags: review?(vladimir)
Keywords: checkin-needed
Pushed http://hg.mozilla.org/mozilla-central/rev/f365e3bc979b
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs 1.9.1 landing]
Duplicate of this bug: 489114
Pushed to 191: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f9840fdb8b01
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing]
I didn't realize this code required an sr. Who is appropriate?
Alice: has this been fixed in the latest nightly? Can you confirm?
(Reporter)

Comment 13

10 years ago
(In reply to comment #11)
> Alice: has this been fixed in the latest nightly? Can you confirm?
I can confirmed that it was fixed in the Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090421 Shiretoko/3.5b4pre ID:20090421042301.
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: --- → Firefox 3.6a1
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.