Fx3b4rc1. Visit http://www.npr.org/music/ and open the history side bar (command+shift+h). If you select the entry from the history sidebar and then try to delete it using the context menu, you will not be able to. You can delete the entry if you use the context menu option without selecting first. For example, select any other entry, then right click on the npr.org entry to bring up the context menu and then you can delete it. You can always delete the entry from the Library window (Show All History...).
Flags: blocking-firefox3? → blocking-firefox3+
Keywords: polish, ue
Priority: -- → P2
can you put exact STR to reproduce?i have tried but i can delete the history entry correctly. how is your sidebar organized: by last visited, by date? is that site bookmarked/starred? what i see is that when you select the entry in the sidebar the website is visited, the visit is added in lazy mode so it will appear after some second. If you delete the entry in that time (between the selection and the new entry appear) you will delete the old visit, but immediately will appear the new visit. try selecting the entry, wait 5s, then delete. does that work?
if comment #1 applies, then mark this as a dupe of bug 421210 (Since the real problem is that is difficult selecting an item without visiting it)
After playing with various scenarios, I don't think this actually blocks. There's some wierdness around trying to delete a history entry for a page you're currently looking at, but I don't think it's a common enough user scenario to block. Hopefully will be fixed by bug 421210, someone should loop back around and check.
juan, can you still reproduce with latest nightly, clicking on the left of the favicon to select the history entry in sidebar?
I can reproduce it on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032405 Minefield/3.0b5pre This issue is reproduced only for "Today" records. Also, you need to wait for few seconds after selection record, before execute "Delete" command. Sidebar is organized "By Date and Site"
Vsevolod, please post exact Step To Reproduce your problem, and a better explanation of the un-expected result. > Also, you need to wait for few seconds after selection record, > before execute "Delete" command. What do you mean? if you wait and delete the item can be deleted, if you don't wait it is not? Do you click on the LEFT of the favicon to select the item?
Steps to reproduce: 1. Start "Flock" 2. Visit a few sites 3. In main menu click "View" -> "Sibebar" -> "History" 4. Expand any node in the list and click on some history record -> Wait for a few seconds, until tree line will be broken (see screenshot "Broken line of tree in FireFox" attached) 5. Right click on the same history item and select "Delete" option from context menu. Expected result: Selected record is deleted Actual result: Selected record is not deleted Please, explain what do you mean saying "on the LEFT"? I select record by clicking on it by left button of mouse.
I have another easy way to reproduce this bug, using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:184.108.40.206) Gecko/2008070206 Firefox/3.0.1. STR: 1. Build up some history. 2. View->Sidebar->History 3. Highlight one of the entries and hit return. 4. While the page is loading press the delete key on the keyboard. 5. When the page finished, try to delete that entry using either the Delete key on the keyboard or the Context menu "Delete" item. After I get into this state, I cannot delete an entry from the history sidebar until I close it and open it again.
I can see the same behavior on Windows XP. Still present in the latest nightlies on trunk and 1.9.1 branch. Here my steps: 1. Open the history sidebar 2. Order by date 3. Middle click on a history item to open it into a new tab 4. Immediately open the context menu of the item (Why everything is disabled?) 5. Wait until the page has been loaded 6. Try to delete the history item via the context menu With step 6 the item is not removed from the view. Closing and Opening the sidebar resolves the issue. As mentioned by Marco on IRC lets add Firefox3.1 as TM.
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Firefox 3.1
Created attachment 360950 [details] stack trace while performing STR on Linux trunk This stack trace was displayed in an alert while I was running through STR
removing tm since it's no longer used as a scheduling flag.
Target Milestone: Firefox 3.1 → ---
Any progress so far with this bug?
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
Created attachment 436888 [details] Broken history tree Same problem using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.3a4pre) Gecko/20100322 Minefield/3.7a4pre. One more thing. After unsuccessful removing the history item via the context menu: 1. Click on the history folder to fold it. 2. Click on the history folder again to unfold it. As the result the history tree is broken.
Seems to me this works now. Feel free to reopen if you're still seeing this, but please provide more detailed STR.
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.