Closed
Bug 386099
Opened 18 years ago
Closed 17 years ago
when drag leaves places-based personal toolbar, clear the drop indicator
Categories
(Firefox :: Bookmarks & History, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: moco, Assigned: waynegwoods)
References
Details
Attachments
(1 file)
5.68 KB,
patch
|
Details | Diff | Splinter Review |
when drag leaves places based personal toolbar, clear the drop indicator
steps to reproduce:
1) from the url bar, drag the favicon.
2) when you drag over the personal toolbar, you'll get the drop indicator (it's currently ugly and purple, see bug #382893)
3) continue dragging and leave the personal toolbar area.
expected results: the drop indicator disappears when you drag out.
actual results: the drop indicator is not cleared, and remains.
I see this on Windows, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/2007062612 Minefield/3.0a6pre
christine, do you see it on mac?
Flags: blocking-firefox3?
Updated•18 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Updated•18 years ago
|
Target Milestone: --- → Firefox 3 M9
Assignee | ||
Comment 1•18 years ago
|
||
Yeah, it's Mac too (though my name's not Christine ;) )
onDragExit is calling a timer to turn off the drag indicator:
http://mxr.mozilla.org/seamonkey/source/browser/components/places/content/toolbar.xml#823
I can confirm that it gets that far, at least, but it doesn't seem to be working for some reason. I haven't investigated why, yet.
As explained in the code, it uses a delay-timer to avoid the flicker effect of the indicator being switched off every time it exits one element even if it's passing into another bookmarks toolbar element.
However in tabs, we just check if the new location is also a valid part of the tab bar and don't switch off the indicator if it is (bug 333791). Is there any reason we couldn't scrap the timer and go with that approach for the bookmarks toolbar? I'm sure I could get a patch together quickly...
OS: Windows XP → All
Hardware: PC → All
Assignee | ||
Comment 2•18 years ago
|
||
This works by simply switching off the indicator in onDragExit, rather than using a timer. It adds checks similar to the tab dnd code in order to avoid flicker. I built and tested it on Mac, but temporarily added favicons to the toolbar to test out how it'd behave over other elements.
Updated•18 years ago
|
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Assignee | ||
Comment 3•18 years ago
|
||
Seems to have been fixed between 20070919 and 20070920, at least on Mac. Need to confirm at least with Windows first...
Comment 5•18 years ago
|
||
yep, i can't reproduce either.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Comment 6•18 years ago
|
||
This does work on Mac, but is still broken on Win XP. Once a drag has passed over the BT, the indicator remains present, no matter where the mouse goes, until the drop is complete.
Status: RESOLVED → REOPENED
OS: All → Windows XP
Hardware: All → PC
Resolution: WORKSFORME → ---
Reporter | ||
Comment 7•18 years ago
|
||
I still see this on windows xp, as well.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101704 Minefield/3.0a9pre
Assignee | ||
Comment 8•18 years ago
|
||
I assume the timer code still needs to be fixed on XP?
Anyway, even if it is fixed, wouldn't it be better to go with the "tab dnd" method of checking if it's over the bookmarks bar and scrapping the timer use, as done in this patch? Anyone want to make a call on that? :)
Updated•18 years ago
|
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Updated•18 years ago
|
Summary: when drag leaves places based personal toolbar, clear the drop indicator → when drag leaves places-based personal toolbar, clear the drop indicator
Updated•18 years ago
|
Updated•18 years ago
|
Priority: -- → P4
Comment 12•18 years ago
|
||
Wayne, sorry for the delay in looking at this. Can you verify that the patch is not rotted, and I'll review asap.
Assignee | ||
Comment 13•18 years ago
|
||
No worries on the delay. Shortly after I posted my home computer died and I still have nothing to build on. Hoping the situation will be rectified within the next couple of weeks and then I'll get back to you :)
Comment 14•18 years ago
|
||
Not going to continue to block on this. If you disagree with this decision, please renominate with reasons why we can't ship with this in final
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Whiteboard: [has patch][needs review dietrich]
Updated•17 years ago
|
Target Milestone: Firefox 3 beta3 → ---
Comment 15•17 years ago
|
||
Has this been fixed by bug 389931?
Comment 16•17 years ago
|
||
WFM
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042606 Minefield/3.0pre
Updated•17 years ago
|
Status: REOPENED → RESOLVED
Closed: 18 years ago → 17 years ago
Depends on: 389931
Resolution: --- → WORKSFORME
Whiteboard: [has patch][needs review dietrich]
Updated•17 years ago
|
Attachment #280131 -
Flags: review?(dietrich)
Comment 17•16 years ago
|
||
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".
In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.
Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.
Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in
before you can comment on or make changes to this bug.
Description
•