Closed Bug 290494 Opened 19 years ago Closed 19 years ago

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


(Core :: Web Painting, defect)

Not set





(Reporter: bc, Assigned: bzbarsky)



(Keywords: regression)


(3 files)

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.
Version: unspecified → Trunk
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
Notice the mouse pointer is several rows higher than the highlighted folder.
*** 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.
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. ***
*** Bug 290744 has been marked as a duplicate of this bug. ***
Attached patch FixSplinter Review
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]

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+
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.

Attachment #180992 - Flags: approval1.8b2? → approval1.8b2+
Assignee: roc → bzbarsky
Closed: 19 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta2
*** Bug 291311 has been marked as a duplicate of this bug. ***
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.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.