Open Bug 275193 Opened 20 years ago Updated 3 years ago

Clear Search Button

Categories

(Firefox :: Search, enhancement, P5)

Product:
Firefox
Component:
Search
Type:
enhancement

Tracking

()

People

(Reporter: fommil, Unassigned)

References

Details

(Whiteboard: [fxsearch])

Attachments

(1 file, 1 obsolete file)

Search field in Firefox and Safari
7.43 KB, image/png
Details 
hi there,

i recently started using Thunderbird for my mail and the search bar has a little
clear button which appears when you start typing in the box. its *very* handy
for clearing the search bar without having to resort to key shortcuts.

i'd strongly reccomend that firefox encorporates this very minor feature. its
such a small enhancement, requiring an extension would be ridiculous [and the
code will already be there in the thunderbird tree ;-)].

the annoyance of clearing the search bar is something everyone i know who uses
firefox has shared.
Going to think about this.

If we add this, we lose a bit of space, and people already think the search bar
is too small.  Making things a little bigger might be an option, need to think
about that.

There's some other misc things, such as the clear button has a function in tbird
(reset the view to not be filtered) where its not necessary here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
well, why don't you allow the search bar width to be resized? that way people
could make it as small or as large as they liked. failing that... i'd personally
be fine with adding the width of the "clear" icon onto the current search bar
width; i find my location bar is a lot wider than it needs to be anyway.

i really think the clear button is a good idea. like i said; clearing that
search box is something that annoys everyone who uses firefox whom i have spoken
with. especially on X11 systems were selecting the text will place it into the
clipboard. the keyboard shortcut C-k Delete is not as user friendly as a button
which appears only when needed.

btw... i noticed there is no easy way to *remove* a search engine from the
search bar. is that intentional?
(In reply to comment #1)
> Going to think about this.

Thank you, Thunderbird recently made some changes to the quick-search, only
displaying the Clear button when text is entered. It will not solve the space
issue, but it would be a nice enhancement to the search widget.
Assignee: p_ch → nobody
Severity: normal → enhancement
Summary: WISH: Clear Search Button → Clear Search Button
Version: 1.0 Branch → Trunk
Here's another possibility to consider: on Safari, for example, the search text does not follow along when new tabs are opened.

This shouldn't take up any more real estate. As anyone who uses Linux knows, it's difficult to use the highlight and middle-click-to-paste when there's already existing text in a window; you either have to first erase what's there or paste your term to the front/back of the existing text then erase what you don't need. Safari's option is nice because the search text stays with the tab where it was originally typed but not new tabs.
1 Launch app
2 Search field: enter some text

No "x" to reset search field, as in:
OmniWeb 5.6
Safari 3.1.1

Seen:
2.0.0.8, 10.3.9 7W98, PowerBook G4/1.25G

3.0rc3, 10.5.3 9D34, iMac Core Duo/1.83G
3.0rc3, 10.4.10 8R4061a, MacBook Pro/2.2G
This is one of those little things that would make browsing much better.
See also bug 253331 for clearing the search time after a couple of seconds while staying in idle.
Blocks: 923099
Extracted from the video.  OmniWeb search field looks like that of Safari.
Attachment #324837 - Attachment is obsolete: true
Priority: -- → P4
Whiteboard: [fxsearch]
Rank: 45
Severity: normal → N/A
Rank: 45
Priority: P4 → P5

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..

(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.

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?

: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"?

(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.

Thanks :standard8 for your honesty.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: