Pressing shift+del to remove an awesome bar result is extremely hard to discover, so we should add a button that lets users get rid of unwanted autocomplete matches. This is part of a larger awesome bar theme refresh: http://margaretleibovic.com/images/shorlander/AwesomeBarResults-Mockup-i01-_OSX_-v16-Selected.png (I am aware of bug 411985, but this bug is revisiting the decision that was made there.)

I pushed this to the UX branch: http://hg.mozilla.org/projects/ux/rev/fa168dc83e6f I just used some close button images that I found in the tree. There was already a white close button in pinstripe, so that matches the mock-ups, but the gnomestripe/winstripe close buttons are not white. I'm not sure what direction we want to go with those. I was also curious if we wanted hover/active states for those themes, like we do for other close buttons. Also, I put the close button on the top line of the match entry, next to the star. When we implement the rest of this theme refresh we can move those both to the center of the entry, since that xul futzing seems out of scope for this bug.

When I mouse over it and it doesn't have a hover state, it's not clera to me that clicking it will do anything. IE9's hover is to turn the x red. That red feels a bit heavy handed, but also lighter than putting a button around it. Also, if it's not just removing an item from the list, but also deleting a bookmark, then maybe we want something more "seriously, this is gonna delete this item" red like IE's.

(In reply to comment #2) > When I mouse over it and it doesn't have a hover state, it's not clera to me > that clicking it will do anything. IE9's hover is to turn the x red. That > red feels a bit heavy handed, but also lighter than putting a button around > it. I don't know if it needs to be red :) Red inside a blue selected area has other issues as well. Giving it some kind of hover will be sufficient I think. > Also, if it's not just removing an item from the list, but also deleting a > bookmark, then maybe we want something more "seriously, this is gonna delete > this item" red like IE's. I am actually not sure that this is working as intended now. Clicking the delete icon works the same as pressing Shift+Del. Shift+Del on History deletes the entry from your results by deleting the History item. However Shift+Del on a Bookmark just removes the entry from the results that you are currently viewing without deleting the bookmark. If you close the results and start a new search it goes right back to where it was. I think it should behave consistently whether you are deleting a History item or a Bookmark item. Although changing the behavior of Shift+Del is really not inside the scope of this bug.

Agreed that the delete the bookmark too is not within the scope of this bug but I think that this bug needs to take that into consideration. If it's deleting just a history item, something that was acquired passively, I don't care as much as if it's deleting a bookmark, something I was intentional about creating. If we end up making it delete both, I think the action should be a bit less subtle than if we just keep going with deleting history. Or maybe not. I'm wrong about a lot of things :-)

I agree with Asa here - I've opened bug 767254 for changing the delete behavior.

This is basically just Margaret's patch applied on top of my patch in bug 587909. Close button is positioned according to the mockup there.

Drew, is this work covered by your new awesomebar UI rewrite?

No, the new spec (bug 1181078) doesn't include a delete button.

Stephen, since the new spec doesn't include a delete button (comment 10) should we close this bug as wontfix?