Closed
Bug 488984
Opened 16 years ago
Closed 16 years ago
when draging tab to content area aEvent.screenX/Y in _onDragEnd is always 0 (breaks tab tearing)
Categories
(Firefox :: General, defect, P1)
Tracking
()
RESOLVED
FIXED
Firefox 3.6a1
People
(Reporter: alice0775, Assigned: enndeakin)
References
Details
(Keywords: regression, verified1.9.1)
Attachments
(1 file, 1 obsolete file)
2.36 KB,
patch
|
vlad
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•16 years ago
|
Updated•16 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•16 years ago
|
Version: 3.1 Branch → Trunk
Comment 1•16 years ago
|
||
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•16 years ago
|
Flags: wanted-firefox3.5?
Comment 2•16 years ago
|
||
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•16 years ago
|
||
Haven't tested this on Windows yet.
Assignee: mano → enndeakin
Status: NEW → ASSIGNED
Comment 4•16 years ago
|
||
Jim: can you help Neil out on this?
Updated•16 years ago
|
Flags: blocking-firefox3.5? → blocking-firefox3.5+
Priority: -- → P1
Comment 5•16 years ago
|
||
Just a slight update for win. The drag end event in FireDragEventAtSource had values that were populated correctly.
Attachment #373717 -
Attachment is obsolete: true
Updated•16 years ago
|
Attachment #373739 -
Flags: review?(vladimir)
Attachment #373739 -
Flags: review?(vladimir) → review+
Updated•16 years ago
|
Keywords: checkin-needed
Comment 6•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs 1.9.1 landing]
Comment 8•16 years ago
|
||
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing]
Comment 9•16 years ago
|
||
Where's the sr?
Comment 10•16 years ago
|
||
I didn't realize this code required an sr. Who is appropriate?
Comment 11•16 years ago
|
||
Alice: has this been fixed in the latest nightly? Can you confirm?
Comment 12•16 years ago
|
||
roc, probably.
Reporter | ||
Comment 13•16 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.
Updated•16 years ago
|
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: --- → Firefox 3.6a1
Updated•15 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•