User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 When I was using the firefox 3.6.x I was able to delete the url from history using delete key in location bar. For example, I click the location bar, then select the link by using (down) arrow key and then remove link via delete key. However, when I want to do same with firefox 4.0b11, I cannot achive this. Because, it thinks that I want to switch to that tab, so it does not let me remove the link. Moreover, since I am already in the tab, switching to that tab is just meaningless, useless thing. Therefore firefox needs to understand that I am already that tab, and switching to that tab is not a real option. When this is done, my original problem will probably be solved. Reproducible: Always Steps to Reproduce: 1. click the location bar 2. press down arrow key 3. try to delete link from history by pressing delete key Actual Results: it does not delete the link from history and tries to switch to that tab which does not make sense. Expected Results: delete the link from history it should not try to switch to tab which firefox already shows.

The 'switch to tab' entry is not a real link, it doesn't come from the history database. It's created from the name of the tab. That's why you can't delete it. If the url was present in history, then you would see it twice : once as a link, and once as a a 'switch to tab'. You can delete the first, but not the second. Removing the 'switch to tab' when you're already on it, is bug 555694.

Ok, I understand how "switch to tab" works, however the entry exists in my history when I check it using "ctrl+shift+h" key combination. And moreover, although there is an entry in history, I only see "switch to tab" not another copy as you said. So I am not able to delete it. However, I think when "bug 555694" is resolved, my problem will be resolved too. Thanks for information.

(In reply to comment #1) > If the url was present in history, then you would see it twice : once as a > link, and once as a a 'switch to tab'. You can delete the first, but not the > second. This is simply untrue. Only the switch to tab appears the normal entry doesn't. So it doesn't work.

I tried it with an existing url : showed once when typing, then twice after it was loaded. Then I deleted the link from the pulldown, and verified that it was really deleted from history (it was). Afterwards, the link would show once (if the original tab was still open), even after it was deleted from history) or none (if the original tab was closed).

http://www.youtube.com/watch?v=AAZraX7x-iw (watch video in 720p and fullscreen, otherwise it is hard to see it.) I uploaded the record of my desktop while trying to delete the url. So I can only see 'switch to tab' entry. Are we using two different versions? mine is 4.0b12.

I think, there is a misunderstanding. This bug is still valid. What I was telling is this: when I am in the current tab and want to delete the url, since it offers me to switch to current tab which I already am in, I cannot delete the url which is annoying. For better understaning, I can write the scenario: - open a link in firefox. - decide that it is useless and it should not stay in my history - use ctrl+L combination to focus location bar - press down arrow - try to delete url but only 'switch to tab' comes and therefore cannot delete the url. So since this bug still valid, I think it shouldn't be marked as "resolved"

reopening due to comment 6

I suppose the issue is that we now only show "switch to tab" entries if the tab is open, and don't show the normal entries. I thought deleting the "switch to tab" entry deleted the underlying history result, but maybe that's not the case.

I think Location Bar was the right component, the backend just gets the removal command, this is probably something in the urlbar binding. Btw, it's a valid bug.

My understanding is that a) the backend is not returning the "normal" result (because there's a switch to tab result), so it doesn't appear in the list to delete at all. And deleting the "switch to tab" result does not delete the related history entry. But I don't remember how any of this code works, so maybe I'm missing something.

(In reply to comment #11) > My understanding is that a) the backend is not returning the "normal" result > (because there's a switch to tab result), so it doesn't appear in the list to > delete at all. And deleting the "switch to tab" result does not delete the > related history entry. Deleting the "switch to tab" entry (pressing delete when the row is selected) does indeed delete the history entry (and does nothing to the "switch to tab" entry, that keeps being available as long as the tab is open). I don't see any issue here (at least in FF4.0 stable). However, there might be a perception problem. It may be pertinent to find a better visual feedback to show the user the history entry as been deleted (show "switch to tab" entries that do not have a corresponding history entry in another color, or dimmed for example ?).

(In reply to comment #12) > Deleting the "switch to tab" entry (pressing delete when the row is selected) > does indeed delete the history entry (and does nothing to the "switch to tab" > entry, that keeps being available as long as the tab is open). I don't see any > issue here (at least in FF4.0 stable). ah, this is indeed expected. > However, there might be a perception problem. It may be pertinent to find a > better visual feedback to show the user the history entry as been deleted (show > "switch to tab" entries that do not have a corresponding history entry in > another color, or dimmed for example ?). I'm not sure how to solve this since even if we remove the entry it would reappear at the next search. Plus removing the entry would have a similar percpetion issue: "is gone, what why now is it back again?" Just using a color is probably not going to communicate anything about history, the user should then remember how to associate colors to information, that sounds like weird. Maybe we could add a history icon like we do for the star in the popup.

I'm no usability expert, but I think a history icon would be good. It might clutter a bit the already crowded awesome bar popup, however. Note that I'm not bothered at all by the current behaviour/feedback. I initially wanted to show this worked exactly how intended, and that the issue was more a usability concert that a technical one.