Closed Bug 1119250 Opened 10 years ago Closed 9 years ago

Remove the old searchbar UI

Categories

(Firefox :: Search, defect, P5)

Product:
Firefox
Component:
Search
Type:
defect
Points:
5

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 43
Tracking Flags:
Tracking Status
firefox38 --- wontfix
firefox38.0.5 --- wontfix
firefox39 --- wontfix
firefox40 --- wontfix
firefox41 --- wontfix
firefox42 --- wontfix
firefox43 --- verified

People

(Reporter: florian, Assigned: florian)

References

Details

(Whiteboard: [ui][fxsearch])

Attachments

(6 files)

Part 1 - remove the pref
7.44 KB, patch
mossop
: review+
Details | Diff | Splinter Review
Part 2 - merge the two searchbar bindings
14.63 KB, patch
mossop
: review+
Details | Diff | Splinter Review
Part 3 - remove the old drop down
34.41 KB, patch
mossop
: review+
Details | Diff | Splinter Review
Part 4 - remove the oneoffui attribute
27.59 KB, patch
mossop
: review+
Details | Diff | Splinter Review
Part 5 - remove the old engine manager dialog
30.26 KB, patch
mossop
: review+
Details | Diff | Splinter Review
Part 6 - move the panel binding to search.xml
38.19 KB, patch
mossop
: review+
Details | Diff | Splinter Review 
Bug 1088660 introduced a new searchbar UI behind a preference because it was only shipped to en-US for Firefox 34.

In Firefox 35, we shipped the new UI localized into several locales (bug 1107278) and it's enabled and localized for everybody starting in Firefox 36 (bug 1103190).

We can now remove the old UI and the browser.search.showOneOffButtons preference.

Realistically it's probably too late already to do this for 37, so targetting 38 here.

Estimating to 5 points because it's not a pure code removal. Some XBL bindings that we half-forked using inheritance need to be merged, some CSS needs to be cleaned up.
Flags: firefox-backlog+
This should not removed until resovled all dependencies regression of new search UI.
Flags: qe-verify?
Flags: qe-verify? → qe-verify-
Flags: qe-verify- → qe-verify+
Priority: -- → P5
Whiteboard: [fxsearch][searchui]
Blocks: 1160076
Rank: 55
Whiteboard: [fxsearch][searchui] → [ui][fxsearch]
Will this happen in the very near future? If so, I can start removing the old ui in bug 1171344. I don't see the point of implementing logic to pref-off the one off buttons there if the pref is going to be removed soon anyway.
Flags: needinfo?(florian)
(In reply to Nihanth Subramanya [:nhnt11] from comment #3)
> I can start removing the old ui in bug 1171344.
I mean in about:{home,newtab} of course.
(In reply to Nihanth Subramanya [:nhnt11] from comment #3)
> Will this happen in the very near future?

Not very likely, unless maybe if you want us to work on it together in Whistler? ;)

> If so, I can start removing the
> old ui in bug 1171344. I don't see the point of implementing logic to
> pref-off the one off buttons there if the pref is going to be removed soon
> anyway.

Do not bother with the pref for about:home and about:newtab.

The reason for having the pref was that we were landing en-US hardcoded strings on stringfrozen branches.
Flags: needinfo?(florian)
Here is a vote from only an user. 

Please do NOT remove this setting. Reason is that with browser.search.showOneOffButtons set to false, you can change the standard search engine with just one click. 

In the new UI with the buttons, the search engine is only changed temporarily for the current tab, and the new search engine is immediately called with the current search text (if there is any). In order to change the standard search engine for all tabs, you will have to go to search engine settings, open the configuration page, and change the standard search engine there.
This, in my opinion, adds unnecessary complexity to an otherwise easy configuration (which was one of the reasons I use Firefox). 

Furthermore, I often use the search feature in the right-click context menu (selecting a word and search for it using the standard search engine). This comes in handy if, for example, you want to translate a single word into another language. Just select the word and search for it in the dictionary search engine. The results will then open in a new tab. That is very convenient. 

Now, with the new UI, I will have to change the standard search engine in settings first.

Which means that I have to go away from the page I was reading to the search engine configuration page, re-configure the standard search engine, then I'll have to go back to the page I was reading, search for my word, examine the results, then I will have to go to the search engine configuration page again to change my standard back to the previous search engine. 

With the old UI, I only have to switch to the dictionary while being able to stay on the page I wanted to read, do my search, read the results and then switch back to my previous standard with only one click. 

To make a long story short: That new UI is nice but it adds more complexity to the program in the way it is currently implemented. 

My suggestion for the new search UI would be: 
1. If you change the search engine for the current tab, it should also be changed for its right-click context menu. 
2. After the change, the new search engine should not be opened in the current tab (if at all) but only in a new one.

Thank you for reading that much text and kind regards,
Gerd
(In reply to Gerd from comment #6)

> you can change the standard search engine with just one click.

You can change the default engine for all tabs by focusing the searchbox and pressing ctrl + up/down keys (command + up/down on Mac).

> Furthermore, I often use the search feature in the right-click context menu
> (selecting a word and search for it using the standard search engine). This
> comes in handy if, for example, you want to translate a single word into
> another language. Just select the word and search for it in the dictionary
> search engine. The results will then open in a new tab. That is very
> convenient.

It seems to me that what you really want is a "Dictionary Lookup" context menu item. I would be surprised if there weren't add-ons providing this feature.
QA Contact: petruta.rasa
The set of changes is large, I split it in 6 smaller patches. After applying each patch, Firefox can be built and the new searchbar UI works.
Attachment #8657144 - Flags: review?(dtownsend)
Attachment #8657144 - Attachment is patch: true

        Attachment #8657145 -
        Flags: review?(dtownsend)

    
    

    
  


  

        Attachment #8657147 -
        Flags: review?(dtownsend)

    
    

    
  


  

        Attachment #8657148 -
        Flags: review?(dtownsend)

    
    

    
  


  
The binding of the searchbar panel was in urlbarbindings.xml because historically it was the same binding for the panels of both the urlbar and the searchbar. The searchbar-specific panel binding being in urlbarbindings.xml rather than search.xml (where all the code interdependent with it lives) has confused several people since we introduced the new UI and keeps being a pain. I remember I had promised to someone (not sure who) that I would fix that at the same time as removing the bindings of the old UI.

        Attachment #8657155 -
        Flags: review?(dtownsend)

    
    

    
  
UITour.jsm still has some dead code related to the old search UI. I don't know that code very well, so if the tests pass (they do locally), I would prefer handling the UITour cleanup in a follow-up.

        Attachment #8657150 -
        Flags: review?(dtownsend) → review+

        Attachment #8657155 -
        Flags: review?(dtownsend) → review+

        Attachment #8657144 -
        Flags: review?(dtownsend) → review+

    
    

    
  
Comment on attachment 8657148 [details] [diff] [review]
Part 4 - remove the oneoffui attribute

Review of attachment 8657148 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/uitour/test/browser_UITour.js
@@ +222,5 @@
>      waitForElementToBeVisible(highlight, () => {
>  
>        let searchbar = document.getElementById("searchbar");
> +      done();
> +      return; // The oneoffui removes the menu that's being tested here.

So you should get rid of this whole test I think? Or at the very least everything after the return is useless.

        Attachment #8657148 -
        Flags: review?(dtownsend) → review+

        Attachment #8657147 -
        Flags: review?(dtownsend) → review+

        Attachment #8657145 -
        Flags: review?(dtownsend) → review+

    
  
Depends on: 1202372

    
    

    
  
¡Hola Florian!

What about https://bugzilla.mozilla.org/show_bug.cgi?id=1139655 ?

Shall it block this bug?

¡Gracias!
Flags: needinfo?(florian)

    
    

    
  
(In reply to alex_mayorga from comment #19)
> ¡Hola Florian!
> 
> What about https://bugzilla.mozilla.org/show_bug.cgi?id=1139655 ?
> 
> Shall it block this bug?

No, it's not directly related. (But I'll try to get bug 1139655 moving soon.)
Flags: needinfo?(florian)

    
  
Depends on: 1204252

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Please file(In reply to Bob49 from comment #21)
> choice of default search engine should be in the
> search bar, itself !!

Bug 1110771 will make it possible to set the default engine from the context menu.

> Should I open a new bug to offer this very wise choice or is it that those
> responsible will take into account here?

We won't take into account here things that aren't directly related to this bug (removing the code of the old searchbar UI). If you think something needs to be changed and there's no existing bug for it, please file a new bug.

(In reply to Bob49 from comment #22)
> you can not put the motors in the order you want !!

In the search settings, you can drag and drop the engines to reorder them.

    
    

    
  
Verified using Developer Edition 43.0a2 2015-09-23 that the preference browser.search.showOneOffButtons is no longer available and adding it with true value doesn't bring back the old search UI.

Environments used: Win 7 64-bit and Mac OS X 10.9.5.
Status: RESOLVED → VERIFIED

          status-firefox43:
          fixed → verified

    
    

    
  
(In reply to Petruta Rasa [QA] [:petruta] from comment #25)
> Verified using Developer Edition 43.0a2 2015-09-23 that the preference
> browser.search.showOneOffButtons is no longer available and adding it with
> true value doesn't bring back the old search UI.
I meant false :)

Forgot to mention that everything looks ok after updating Nightly 43.0a1 with a profile where the pref is false to a newer version with the fix landed.

    
  
Target Milestone: Firefox 38 → Firefox 43

    
    

    
      
  

    
    

    
  
(In reply to Yaron from comment #23)
> How about adding "Set last selected engine as your default Search Engine"
> (checkbox) to the Searchbar's dropdown?
That would, indeed, be a good idea.

    
    

    
      
  

    
    

    
      
  

    
    

    
  
I did not think it would be possible!.. But the addon Classic Theme Restorer gives the old interface... 

Although this addon does not interest me more than that, using it only on the Nightly (Fx 46 at present), it will make people happy.

And even if we know it will not last forever ... with the end of XUL.

According version of Firefox, I use the old and new without difficulty, even if preference for the former ..

    
    

    
      
  

    
    

    
  
(In reply to Saul Dobney from comment #32)
The case you describe is bug 1109851.

    
    

    
      
  

    
    

    
  
This having landed, browser.search.showOneOffButtons is now gone as of FF43.
It is particularly frustrating that this is not documented in the release notes?

(This seems to be a regular problem in Firefox).

Is it appropriate to open another bug to have the documentation updated? Googling for "showOneOffButtons" doesn't find much explanation of the removal of this feature from Firefox, so it's pretty hard for users to figure out what is going on.

What is the right place to ask questions about the new search bar UI?

In the old UI, I could use keyboard navigation to select a search engine. For instance, to search wikipedia for "foobar" by typing foobar" and then Alt-Down and either press 'W' or continuing Up/Down to select Wikipedia. Losing that is a major productivity blow -- is there an analog in the new UI?

Having to primarily identify search engines by icon is a big lose. It's OK for some regularly-used search engines, but not for obscure ones where the icons are not memorable.

Also, when was the right time to have raised this? When FF37 released and the new search interface landed, I was upset but I found showOneOffButtons and it satisfied me, so I went no further. Should I have known that showOneOffButtons would only be temporary (how? Is that documented somewhere?) and lobbied to improve the interface? Is it too late now?

Although Bob49 suggests Classic Theme Restorer brings it back, unfortunately it brings back the mouse-UI without the rapid keyboard access UI, so it's actually worse than the new search interface. (It also changes the keyboard command, under OSX, from Option-Up/Down to Cmd-Up/Down, and leaves you flying blind as to the ordering when you Up/Down).

I am an upset user. I know this is not the right place for upset user feedback on developer decisions, but where is the right place? Thanks.

    
    

    
  
(In reply to John Hawkinson from comment #35)
>
> Is it appropriate to open another bug to have the documentation updated?
> Googling for "showOneOffButtons" doesn't find much explanation of the
> removal of this feature from Firefox, so it's pretty hard for users to
> figure out what is going on.

As far as I can tell, showOneOffButtons wasn't intended as a user-visible toggle for the feature. I imagine it was used as a fallback, to flip Firefox back to the old search UI via a hotfix or something if critical problems were found in the new search input.

In my experience, we generally don't document prefs that aren't exposed to the user via some UI. The Mozillazine community documents some of these[1], however.

> In the old UI, I could use keyboard navigation to select a search engine.
> For instance, to search wikipedia for "foobar" by typing foobar" and then
> Alt-Down and either press 'W' or continuing Up/Down to select Wikipedia.
> Losing that is a major productivity blow -- is there an analog in the new UI?

I can select Wikipedia using my keyboard using the following steps on Windows:

1. Ctrl-k to select the search input
2. Type search query
3. Ctrl-Cursor Down/Up to change the search provider
4. Enter to search

Steps 2 and 3 can be flipped.

Alternatively, I can also hit the up cursor after typing my search to choose a search provider at the bottom of the panel, and hit enter. This has the added advantage of not changing my default search provider. I've found myself using this latter pattern almost exclusively, and I quite like it.

> What is the right place to ask questions about the new search bar UI?
> ...
> I am an upset user. I know this is not the right place for upset user
> feedback on developer decisions, but where is the right place? Thanks.

The firefox-dev mailing list is probably what you're looking for: https://wiki.mozilla.org/Firefox/firefox-dev

[1]: http://kb.mozillazine.org/Browser.cache.disk.enable, for example.

    
    

    
  
Thanks, Mike.

> As far as I can tell, showOneOffButtons wasn't intended as a user-visible
> toggle for the feature.

Unfortunately, it became one. Users like me would find the new feature
problematic, so we would google and find one of the myriad of pages
explaining showOneOffButtons solved the problem. So we would customize
and think "Firefix meets our needs with a bit of configuration. Awesome!
No need to provide feedback or advocacy."

This seems to be a recurring issue in Firefox. Obviously it is larger than
this one feature/bug/issue.

> I can select Wikipedia using my keyboard using the following steps on
> Windows:
> 
> 1. Ctrl-k to select the search input
> 2. Type search query
> 3. Ctrl-Cursor Down/Up to change the search provider
> 4. Enter to search

Right. The problem is that Step 3 is for me is eleven Cmd-Down's or
twenty Alt-Down's. Neither of which is really satisfactory. Being
able to hit Alt-Down 'W' in the old search was fast and easy. The new
way feels horribly cumbersome.

> Alternatively, I can also hit the up cursor after typing my search to choose

This is better (at least for Wikipedia)  -- for me that's 5 Up
arrows. Better than 11 or 20, for sure, but not great. And not so good
for things in the middle of the list/alphabet.

Maybe my problem is better boiled down to: "new UI not so great
with large numbers of search enginers (I have 32)."

Thanks.

    
    

    
  
(In reply to John Hawkinson from comment #37)
> 
> > I can select Wikipedia using my keyboard using the following steps on
> > Windows:
> > 
> > 1. Ctrl-k to select the search input
> > 2. Type search query
> > 3. Ctrl-Cursor Down/Up to change the search provider
> > 4. Enter to search
> 
> Right. The problem is that Step 3 is for me is eleven Cmd-Down's or
> twenty Alt-Down's. Neither of which is really satisfactory. Being
> able to hit Alt-Down 'W' in the old search was fast and easy. The new
> way feels horribly cumbersome.

I think that's a legitimate enhancement bug that we should file.

I've filed that for you as bug 1233810.

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Please keep in mind Bugzilla's etiquette, and the fact that you're sending emails to hundreds of people every time you complain.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Especially don't abuse of flags like NEEDINFO.
Flags: needinfo?(florian)

    
    

    
      
  

    
    

    
  
(In reply to John Hawkinson from comment #35)
First, thanks for staying respectful in the way you worded your comment, despite your frustration :-).

> Is it appropriate to open another bug to have the documentation updated?

If there is documentation pointing to the showOneOffButtons pref (I hope not), yes it would be appropriate to file a bug to get it updated/cleaned.

> Googling for "showOneOffButtons" doesn't find much explanation of the
> removal of this feature from Firefox

This preference has never been meant to be a 'feature'. It existed only so that Firefox 34 could ship with the new searchbar UI in en-US, and other locales could keep the old UI until the new strings were translated.

> What is the right place to ask questions about the new search bar UI?

firefox-dev, as Mike pointed, is a good place. If some use case isn't covered, filing a new bug on bugzilla is also a good place.

> In the old UI, I could use keyboard navigation to select a search engine.
> For instance, to search wikipedia for "foobar" by typing foobar" and then
> Alt-Down and either press 'W' or continuing Up/Down to select Wikipedia.
> Losing that is a major productivity blow -- is there an analog in the new UI?

This is the first time I hear about the 'type first letter of engine name' case.

The solution Mike proposed (using ctrl+up/down) works if you want to use the engine for several searches. If you want to select the engine for only one search, I would suggest using the tab key.

> Also, when was the right time to have raised this?

The earlier we get feedback, the more likely we are to be able to take it into account. We did pay a lot of attention to the feedback we received about the search UI in Firefox 34,35,36, and tweaked the way keyboard navigation works for Firefox 38 (that was in February 2015).

> Is it too late now?

It's not too late to file enhancement requests (and thanks Mike for filing one for the case raised in your comment :-)), but we are significantly less likely to act quickly on them than we would have been a year ago.

    
    

    
      
  

    
    

    
  
I understand using control up/down and that works ok to select search engine, although was easier before when the whole list was presented instead of having to up/down thru the list one-at-a-time to find the one you want (and no way to jump to a certain letter that I can see).  Additionally, I no longer can *easily* see which search engine is selected.  Firefox used to display the icon of the currently selected search engine in the search bar, now it has some magnifying glass with what looks like a color-inverted medical marijuana dispensary symbol. Is there a way to change that back to display the currently selected search engine?   I realize I can also determine it by right clicking on highlighted text and seeing what pops up, but that's slow.  

(I remember running into this problem with a new version around a year ago, searching, finding the browser.search.showOneOffButtons fix... and now a year later it's back, and that fix doesn't work anymore.   I can live with it as is, but it's certainly not as convenient to use.  Not sure why someone would think this is better, is anything actually easier this way, or does it only add complexity?)

    
    

    
  
Sorry, can't edit my previous post, one more thing.  Is there a way to select the search engine with a mouse?  Seems it's only possible with control up/down.  If I try to select with a mouse it automatically runs a search on whatever is already in the search bar, but I want to select it so I can highlight text/right click/search.

    
    

    
  
(In reply to Craig from comment #46)
> Sorry, can't edit my previous post, one more thing.  Is there a way to
> select the search engine with a mouse?  Seems it's only possible with
> control up/down.  If I try to select with a mouse it automatically runs a
> search on whatever is already in the search bar, but I want to select it so
> I can highlight text/right click/search.

The new searchbar UI is designed so that the user types the query first, and then selects the engine. Selecting the engine before searching is not supported (we discussed it in bug 1110820 and the user experience team decided that supporting this case would cause inconsistencies in the UI).

If you want to go back to the old UI, you can install the Classic Theme Restorer add-on: https://addons.mozilla.org/firefox/addon/classicthemerestorer/

    
    

    
  
(In reply to Florian Quèze [:florian] [:flo] from comment #47)
> The new searchbar UI is designed so that the user types the query first, and
> then selects the engine. Selecting the engine before searching is not
> supported.

So, if I understand correctly, there is no way in the new UI to get search suggestions from Wikipedia if my default search engine is Google?

> If you want to go back to the old UI, you can install the Classic Theme
> Restorer add-on:
> https://addons.mozilla.org/firefox/addon/classicthemerestorer

Which will stop working sometime in 2016, am I correct?

    
    

    
  
(In reply to Florian Quèze [:florian] [:flo] from comment #47)
> (In reply to Craig from comment #46)
> > Sorry, can't edit my previous post, one more thing.  Is there a way to
> > select the search engine with a mouse?  Seems it's only possible with
> > control up/down.  If I try to select with a mouse it automatically runs a
> > search on whatever is already in the search bar, but I want to select it so
> > I can highlight text/right click/search.
> 
> The new searchbar UI is designed so that the user types the query first, and
> then selects the engine. Selecting the engine before searching is not
> supported (we discussed it in bug 1110820 and the user experience team
> decided that supporting this case would cause inconsistencies in the UI).

I'm revering to highlight with mouse on the page /right click/search. Not typing the query.  There does not seem to be a way to select the search engine after selecting the text, the only search choice presented is the currently selected one.  This can be pre-selected by using control up/down in the search bar.  However my question is if there is a way to do it with a mouse.   

I'm not referring to typing a query.  I understand the new method and can deal with it.

Still don't understand why change the icon to a mag glass instead of the currently selected search engine tho, doesn't improve anything at all.

    
    

    
      
  

    
    

    
  
Florian Quèze's OP of Bug 1088660 (which introduced the new search UI) stated:
> The current search bar encourages me to google "wikipedia keyword" instead
> of searching "keyword" directly with the wikipedia search engine, because if
> I select the wikipedia engine, I'll still have it selected for the next
> search.
> 
> I'm going to work here on the implementation of a prototype to improve
> one-off searches. 

1) Does anybody find it strange that Florian Quèze stating that he doesn't like the old UI does not count as advocacy, but the numerous individuals stating on this thread, now that it has been *forced* upon us, that they don't like the *new* UI, are repeatedly hidden, and thus dismissed, as "advocacy".

2) Why was continued inclusion of the old UI marked as a bug in the first place, when people were still using it? A quick google search on the preference "browser.search.showOneOffButtons" would have revealed that it was widely used to retain it.

Both of these questions are relevant both to the development of this UI, and to the wider issue of the transparency and user-responsiveness of the Firefox development process.

    
    

    
  
(In reply to hrafn42nz from comment #51)
> 1) Does anybody find it strange that Florian Quèze stating that he doesn't
> like the old UI does not count as advocacy, but the numerous individuals
> stating on this thread, now that it has been *forced* upon us, that they
> don't like the *new* UI, are repeatedly hidden, and thus dismissed, as
> "advocacy".

Like many others you're missing a point: the person implementing a change is not the person taking the decision to make that change. This definitely wasn't a one-person decision.

If you want to continue the discussion, Mike in comment 36 already pointed out channels more apt than Bugzilla. 

> The firefox-dev mailing list is probably what you're looking for:
> https://wiki.mozilla.org/Firefox/firefox-dev

    
    

    
  
Just a note, and maybe we should to public the statistics, like the bug 836758 comment 127.
Depends on: 1130210

    
    

    
  
(In reply to Francesco Lodolo [:flod] from comment #52)
> Like many others you're missing a point: the person implementing a change is
> not the person taking the decision to make that change. This definitely
> wasn't a one-person decision.
And that decision process is publicly viewable *where*? All that we-the-users can see is a developer who appears to have (i) no liking for the old UI, (ii) little understanding of how users used the old UI and (iii) little sympathy for users who preferred the old UI, playing a fairly ubiquitous role in determining its replacement. I'm not seeing much transparency or end-user-focus here.

> If you want to continue the discussion, Mike in comment 36 already pointed
> out channels more apt than Bugzilla. 
> 
> > The firefox-dev mailing list is probably what you're looking for:
> > https://wiki.mozilla.org/Firefox/firefox-dev

firefox-dev appears to be a high-volume (without any apparent ability to restrict the feed to only specific topics) wide-ranging developer-on-developer-focused (as opposed to developer-on-user) and high-level-specific-feature-independent. It does not appear to be even remotely "apt" for an "upset user" to voice their specific complaints over changes to specific functionality.

The closest-to-apt forum would appear to be Mozillazine's 'Firefox Features' forum (which incidentally has a popular thread titled "The new Search engine functions are AWFUL!", whose second entry is a browser.search.showOneOffButtons how-to). This forum however appears to suffer from the inverse problem to firefox-dev, in that it appears to be all users, no developers. There appear to be no forums where users and developers interact. Does anybody see that this might be the causal "bug", of which this latest ruckus is merely a symptom?

    
    

    
  
> "apt" for an "upset user" to voice their specific complaints over
> changes to specific functionality.

That's what http://input.mozilla.org seems to be made for. I don't know though if developers read that because it doesn't have the feature for conversation.

    
    

    
  
(In reply to dalokmarcinak from comment #55)
> That's what http://input.mozilla.org seems to be made for. I don't know
> though if developers read that because it doesn't have the feature for
> conversation.
If developers don't read it, then what's the point of having it? I would point out that a search on it of "search + ui" for the last 5-ish months (the maximum period it would give) yields 95% 'sad' feedback. That probably should have been a red flag for doing away with the old ui.

    
    

    
  
(In reply to hrafn42nz from comment #56)
> If developers don't read it, then what's the point of having it? I would
> point out that a search on it of "search + ui" for the last 5-ish months
> (the maximum period it would give) yields 95% 'sad' feedback. That probably
> should have been a red flag for doing away with the old ui.

Please note that satisfied people usually don't have the urge to voice their opinion.

    
    

    
      
  

    
    

    
      
  

    
  
Depends on: 1243295

    
    

    
  
Status: VERIFIED FIXED???

In lists and tables, text works better than icons. 

Our local security/privacy policy includes the following: 

- Remove default searchplugins. 
- Use custom searchplugins. 
- Remove favicons from searchplugins: use text instead. 

Impact of Mozilla's decision to remove text descriptions from the search-bar:

1. The search-bar shows empty favicons only (no text). 
   The search-bar is therefore unusable. 
2. Remove the search-bar, and use the address-bar as search-bar.
   This is how apple's safari and google's chrome work.
3. Remove the useful searchplugins, 
   because they are not selectable from the address-bar. 

Alternative to the above: 
Use GNU IceCat 38.

    
    

    
  
(In reply to Florian Quèze [:florian] [:flo] from comment #47)
> If you want to go back to the old UI, you can install the Classic Theme
> Restorer add-on:
> https://addons.mozilla.org/firefox/addon/classicthemerestorer/

Not possible any more after Firefox 56. Any solutions?

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: