Closed Bug 675818 Opened 13 years ago Closed 2 years ago

Add delete button to awesome bar result matches

Categories

(Firefox :: Address Bar, enhancement, P3)

enhancement
Points:
5

Tracking

()

RESOLVED DUPLICATE of bug 1789661

People

(Reporter: Margaret, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: blocked-ux, papercut, privacy, Whiteboard: [Advo][snt-scrubbed])

Attachments

(1 file, 1 obsolete file)

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.)
Attached patch wip (obsolete) — Splinter Review
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.
Assignee: nobody → margaret.leibovic
Status: NEW → ASSIGNED
Attachment #549984 - Flags: feedback?(shorlander)
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 :-)
Blocks: 587909
Assignee: margaret.leibovic → nobody
Status: ASSIGNED → NEW
Attachment #549984 - Flags: feedback?(shorlander)
Assignee: nobody → fracture91
Severity: normal → enhancement
Status: NEW → ASSIGNED
I agree with Asa here - I've opened bug 767254 for changing the delete behavior.
Severity: enhancement → normal
Status: ASSIGNED → NEW
Target Milestone: --- → Firefox 15
Version: Trunk → 16 Branch
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: Firefox 15 → ---
Version: 16 Branch → Trunk
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.
Attachment #549984 - Attachment is obsolete: true
Depends on: 767254
Blocks: cuts-control
Keywords: privacy
See Also: → 406239, 461654
Whiteboard: [Advo]
Drew, is this work covered by your new awesomebar UI rewrite?
Flags: needinfo?(adw)
No, the new spec (bug 1181078) doesn't include a delete button.
Flags: needinfo?(adw)
Stephen, since the new spec doesn't include a delete button (comment 10) should we close this bug as wontfix?
Flags: needinfo?(shorlander)
Flags: needinfo?(shorlander)
See Also: → 1412510
Assignee: adhurle → attach-and-request
Status: ASSIGNED → NEW
Priority: -- → P3
Blocks: 1041761
Keywords: papercut
Points: --- → 5
Keywords: blocked-ux
Whiteboard: [Advo] → [Advo][snt-triaged]
Whiteboard: [Advo][snt-triaged] → [Advo][snt-triaged]
Whiteboard: [Advo][snt-triaged] → [Advo][snt-scrubbed]
Severity: normal → S3
No longer blocks: 1041761
Status: NEW → RESOLVED
Closed: 2 years ago
Duplicate of bug: urlbar-result-menu
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: