Drag and drop (d&d) shows wrong target in trees (mail folders, bookmarks, etc.)

RESOLVED FIXED in mozilla1.8beta2

Status

()

--
major
RESOLVED FIXED
14 years ago
11 years ago

People

(Reporter: bc, Assigned: bzbarsky)

Tracking

({regression})

Trunk
mozilla1.8beta2
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
Starting with today's (2005-04-15) build, when I attempt to drag a message from
one folder to another the highlighted folder does not track the mouse but is
offset from the mouse by approximately 7 rows.
(Reporter)

Updated

14 years ago
Version: unspecified → Trunk

Comment 1

14 years ago
This is a major regression that occured between 20050414 and 20050415. It seems
that there are a number of bugs in this timeframe involving mouse position. The
check-in for bug 289792 is very suspicious here.
Severity: normal → major
Keywords: regression

Comment 2

14 years ago
Created attachment 180898 [details]
Screen capture illustrating the issue

Notice the mouse pointer is several rows higher than the highlighted folder.
Depends on: 289792
*** Bug 290629 has been marked as a duplicate of this bug. ***
Same sysmtom, same regression is reported to Bug 290629 for Mozilla Application
Suite MailNews.

Comment 5

14 years ago
If it exists in both, then it is a core bug.
Component: Mail Window Front End → MailNews: Backend
Product: Thunderbird → Core
Assignee: mscott → nobody
Component: MailNews: Backend → Build Config
QA Contact: build-config
Bugzilla's collision detection just totally fucked up.  :(

Resetting the right summary and component.  This has nothing to do with mailnews.
Assignee: nobody → roc
Component: Build Config → Layout: View Rendering
QA Contact: build-config → ian
Summary: d&d mail shows wrong target folders → Drag and drop (d&d) shows wrong target in trees (mail folders, bookmarks, etc.)
*** Bug 290629 has been marked as a duplicate of this bug. ***

Comment 8

14 years ago
*** Bug 290744 has been marked as a duplicate of this bug. ***
Created attachment 180988 [details] [diff] [review]
Fix

The last hunk is what's really needed to fix this bug... The rest is dealing
with the "nscoord is PRInt32" assumptions all over the code.
Attachment #180988 - Flags: superreview?(roc)
Attachment #180988 - Flags: review?(roc)
Comment on attachment 180988 [details] [diff] [review]
Fix

boxobject APIs should deal with CSS pixels, so you might as well note that.

+  // XXXbz except what this is _really_ doing is assuming that the client
coords were in the inner box coord space and translating the into _our_ coord
space.	Is that really what we want here?
+  point += mInnerBox.TopLeft();

as discussed on IRC, this has always been incorrect. It should probably be
point -= mInnerBox.TopLeft().
Attachment #180988 - Flags: superreview?(roc)
Attachment #180988 - Flags: superreview+
Attachment #180988 - Flags: review?(roc)
Attachment #180988 - Flags: review+
Created attachment 180992 [details] [diff] [review]
Updated to comments, with d&d also fixed to handle padding

Requesting 1.8b2 approval for this regression fix
Attachment #180992 - Flags: approval1.8b2?
Comment on attachment 180992 [details] [diff] [review]
Updated to comments, with d&d also fixed to handle padding

a=brendan for 1.8b2.

/be
Attachment #180992 - Flags: approval1.8b2? → approval1.8b2+
Assignee: roc → bzbarsky
Fixed.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta2

Comment 14

14 years ago
*** Bug 291311 has been marked as a duplicate of this bug. ***

Comment 15

11 years ago
A very similar issue is now occurring in Firefox bookmarks menus (not Bookmarks Manager like in this bug).  Is there a newer bug for that?  I have searched all over the place.
You need to log in before you can comment on or make changes to this bug.