Clear Search Button
Categories
(Firefox :: Search, enhancement, P5)
Tracking
()
People
(Reporter: fommil, Unassigned)
References
Details
(Whiteboard: [fxsearch])
Attachments
(1 file, 1 obsolete file)
|
7.43 KB,
image/png
|
Details |
Comment 1•21 years ago
|
||
| Reporter | ||
Comment 2•21 years ago
|
||
Comment 3•20 years ago
|
||
Updated•20 years ago
|
Comment 4•19 years ago
|
||
Comment 5•17 years ago
|
||
Comment 6•17 years ago
|
||
Comment 8•16 years ago
|
||
Comment 10•12 years ago
|
||
Updated•10 years ago
|
Updated•10 years ago
|
| Comment hidden (advocacy) |
Updated•5 years ago
|
Comment 16•5 years ago
|
||
When bug 275193 was opened, it was correctly classified as an "enhancement" because the goal was to make the UI consistent with other browsers, such as Safari.
The evolution of Firefox's UI in the 17 years that have since passed, however, necessitates reclassification of this as a "defect", because the absence of a clear button now represents an inconsistency with Firefox itself. In modern Firefox, the clear button appears throughout the browser's UI:
- History Sidebar search field
- Bookmarks Sidebar search field
- Synced Tabs Sidebar search field
- Library window bookmark search field
- Library window history search field
- Library window downloads search field
- Settings screen search field
- Developer tools "search HTML" field
- Developer tools "filter styles" field
- Etc..
It would be appropriate to reclassify as "defect" to correctly reflect the issue it seeks to address, which is a browser UI inconsistency that can not be resolved via add-ons, etc..
Comment 17•5 years ago
|
||
(In reply to pm from comment #16)
It would be appropriate to reclassify as "defect" to correctly reflect the issue it seeks to address, which is a browser UI inconsistency that can not be resolved via add-ons, etc..
It could be quite easily classified as either, and I think given the state of everything, it is reasonable to keep enhancement here.
Comment 18•5 years ago
|
||
Thanks Mark for your comment. To help me understand, can you please elaborate on what you mean by "the state of everything"? It's my nature to want to agree with you, but a UI inconsistency is a defect. And it's hard for me to see this as anything but a UI inconsistency, given the examples I shared above. Maybe you're suggesting the inconsistency is deliberate?
Comment 19•5 years ago
|
||
:standard8, just for full transparency, can you please help set the appropriate expectation with regard to this defect? I visited https://codetribute.mozilla.org/, selected Firefox Desktop Frontend, selected "Search" from the project dropdown, and observed that no items were displayed. So it seems that a developer that is willing and able to fix this defect may not necessarily know about it. I certainly wasn't aware of it when I opened a duplicate ticket. Is this defect's current classification a polite way of Mozilla saying "this won't be fixed"?
Comment 20•5 years ago
|
||
(In reply to pm from comment #18)
Thanks Mark for your comment. To help me understand, can you please elaborate on what you mean by "the state of everything"? It's my nature to want to agree with you, but a UI inconsistency is a defect.
I basically meant the state of this bug, what we're likely to change and how we're likely to treat it. It may be a UI inconsistency, but it has been that way for a long time. Also if you look at the definition of "Type" (linked to next to the field), it has "improvement in UI" under enhancement.
More fundamentally, the type is not likely to affect the prioritisation of this issue.
(In reply to pm from comment #19)
:standard8, just for full transparency, can you please help set the appropriate expectation with regard to this defect? I visited https://codetribute.mozilla.org ... observed that no items were displayed ... Is this defect's current classification a polite way of Mozilla saying "this won't be fixed"?
Codetribute is primarily for helping new contributors finding good first bugs (easy bugs) or bugs which a developer is willing to mentor. Only a small subset of bugs are linked to there.
Realistically to accept or make a change to the bar we would need input from our user experience (UX) team - since we would have to determine what to do with the "go" arrow and the button, and the search bar widths. The search bar is only used by a relatively small proportion of users, and this is not an issue that has been raised frequently.
Unfortunately UX is very busy at the moment, and this really isn't a high priority for a fix, so I'm afraid that whilst it would be nice to have a resolution (which is why the bug is still open), I do not think it is something we are going to look at in the near to medium future.
Comment 21•5 years ago
|
||
Thanks :standard8 for your honesty.
Comment 22•23 days ago
|
||
At some stage we added the 'x' button to the separate search bar. Not sure when that was, but calling this "works for me".
Description
•