Closed
Bug 407872
Opened 17 years ago
Closed 17 years ago
Deleting items from "most visited" smart bookmark folders on the toolbar doesn't work (using the context menu)
Categories
(Firefox :: Bookmarks & History, defect)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
FIXED
Firefox 3
People
(Reporter: asqueella, Assigned: mak)
References
Details
Attachments
(1 file)
1.42 KB,
patch
|
asaf
:
review+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
STR:
1. Create a new profile, wait for the home page to load
2. Click Smart Bookmarks -> Most Visited
3. Try to delete the "Minefield Start Page" item using the context menu
Actual results: no effect, even if you close the menu and re-open it.
Expected results: item deleted from history (?). Match whatever deleting the item in the places organizer does.
The only relevant bug I could find was bug 407614, but in the case of the bookmark toolbar folder, the delete functionality is truly broken (not just the view update). Note that deleting "recently bookmarked" items does work (although the menu isn't updated until you re-open it).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007121009 Minefield/3.0b2pre
Assignee | ||
Comment 1•17 years ago
|
||
i think that this has the same cause of Bug 407612
Most Visited items are history ones, since the organizer and menus are based on bookmark id, they have itemId = -1, so the menu will not be able to delete them.
the best fix would be to move out from bookmark id and distinguish items through place id, so itemId would become placeId and every item will have a valid id
Assignee | ||
Comment 2•17 years ago
|
||
also notice that the menu item is not disabled even if itemId = -1, should add a check to disable not applicable options in such a case
Updated•17 years ago
|
OS: Windows XP → All
Hardware: PC → All
Comment 9•17 years ago
|
||
I'll have to say that I think this is rather critical for FF3... I mean we have a menu item listed here that doesn't work, and positioned quite prominently, too. Think of it like this:
User updated to FF3
User sees great new "Most Visited" feature
User notices that it contains that he doesn't want to show up, maybe because it's embarrassing, maybe because it's a dupe (like the one that all GMail users get: #inbox and ?account_id=foo)
User sees absolutely nothing happening
User thinks something is broken
There are a couple of ways to fix that would make sense:
1. Disable "Delete". Easiest, but not very elegant... I'd say as long as not even this is in place, this bug is blocking FF3.
2. Delete individual history item. At least gives the user a temporary way to control the list, although deleted entries will reappear after a certain time. Also, the user will manipulate the history without even realizing it.
3. Delete item and place on blacklist for history. Will fix the issue, but not transparent as long as there's no GUI to remove blacklist items and also, the user will manipulate the history without even realizing it.
4. Flag history item as NO_MOSTVISITED and filter Most Visited list accordingly. Not transparent as long as there's no GUI for manipulating this in the places organizer. Also, deleting all history entries would eliminate the flag so entries would come back after that.
5. Create local blacklist for Most Visited and add the url to it. Would still need a GUI, though.
As long as not even #1 is there, I'm putting this on blocking‑firefox3=? , hope that's all right.
Flags: blocking-firefox3?
Assignee | ||
Comment 10•17 years ago
|
||
detect a history query parent and remove uri from history
Attachment #315983 -
Flags: review?(mano)
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → mak77
Assignee | ||
Updated•17 years ago
|
Status: NEW → ASSIGNED
Updated•17 years ago
|
Whiteboard: [has patch][needs review mano]
Comment 11•17 years ago
|
||
Comment on attachment 315983 [details] [diff] [review]
patch
r=mano
Attachment #315983 -
Flags: review?(mano)
Attachment #315983 -
Flags: review+
Attachment #315983 -
Flags: approval1.9?
Assignee | ||
Updated•17 years ago
|
Whiteboard: [has patch][needs review mano] → [has patch][has review]
Comment 12•17 years ago
|
||
Comment on attachment 315983 [details] [diff] [review]
patch
a1.9=beltzner
Attachment #315983 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Updated•17 years ago
|
Keywords: checkin-needed
Whiteboard: [has patch][has review]
Updated•17 years ago
|
Whiteboard: [has patch][has reviews]
Comment 13•17 years ago
|
||
mozilla/browser/components/places/content/controller.js 1.227
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews]
Target Milestone: --- → Firefox 3
Comment 14•15 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
•