1106559 - Improve the search preference UI (add ability to edit keywords, reorder/remove engines, restore defaults)

Status: VERIFIED FIXED

(Firefox :: Search, defect)

Description

[Landry Breuil (:gaston)]

Seen in latest 34.0 beta, 34.0 rc1 and rc2 - there's no way to add/modify search keywords. There's also no way to reorder the search engines in the new prefs pane.

Comment 1

[Landry Breuil (:gaston)]

As pointed out by :RattyAway on irc, one can set browser.search.showOneOffButtons to false in about:config to get the previous search engine manager back.

Comment 2

[Florian Quèze [:florian]]

(In reply to Landry Breuil (:gaston) from comment #1)
> As pointed out by :RattyAway on irc, one can set
> browser.search.showOneOffButtons to false in about:config to get the
> previous search engine manager back.

You can also just load chrome://browser/content/search/engineManager.xul in a tab.

Comment 4

[Florian Quèze [:florian]]

Attachment: Patch v1

The theming still needs love, but apart from that I think it's ready for review.

Comment 5

[Florian Quèze [:florian]]

https://tbpl.mozilla.org/?tree=Try&rev=9af2f97e8483

Comment 6

[Florian Quèze [:florian]]

Attachment: Strings only

Approval Request Comment
[Feature/regressing bug #]: bug 1088660. 
[User impact if declined]: No way to edit search keywords in Firefox 35/36.
[Describe test coverage new/current, TBPL]: N/A, string only patch.
[Risks and why]: N/A
[String/UUID change made/needed]: This adds strings, after discussing with gavin/Pike/flod/chofmann this is the right thing to do for 35.

Comment 8

[Florian Quèze [:florian]]

Comment on attachment 8535295 [details] [diff] [review]
Strings only

https://hg.mozilla.org/integration/fx-team/rev/1e535a5222fb
https://hg.mozilla.org/releases/mozilla-aurora/rev/f4f2674e969f
https://hg.mozilla.org/releases/mozilla-beta/rev/c0961e36ccaf

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/1e535a5222fb

Comment 10

[Alice0775 White]

Not yet fixed in Nightly as well as Beta, Aurora.

Comment 11

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 13

[Ton [:Tonnes]]

>> +<!ENTITY restoreDefaultSearchEngines.accesskey "d">
>> +<!ENTITY removeEngine.accesskey                "r">

This may sound like nitpicking and isn't vital here, but please use matching cases for access keys in general to avoid unintended current or future behavior and sometimes confusing localizers (and note this when reviewing).

Comment 14

[Florian Quèze [:florian]]

Attachment: Interdiff between attachment 8534637 and the second version of the patch

Attaching an interdiff of the additional change for easier review by felipe.

Comment 15

[Florian Quèze [:florian]]

Attachment: Patch v2

I'll do the in-content UI version of this in a follow-up.

Dão, I think Felipe isn't fully comfortable reviewing the theming changes here; would you like to do a quick review of them?

Comment 16

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8536906 [details] [diff] [review]
Patch v2

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

::: browser/components/preferences/search.js
@@ +82,5 @@
>  
> +  onTreeKeyPress: function(aEvent) {
> +    let index = gEngineView.selectedIndex;
> +    let tree = document.getElementById("engineList");
> +    if (aEvent.charCode == KeyEvent.DOM_VK_SPACE) {

Add a comment here explaining what is VK_SPACE doing

@@ +88,5 @@
> +      gEngineView.setCellValue(index, tree.columns.getFirstColumn(),
> +                               newValue.toString());
> +    }
> +    else {
> +      let isMac = ("nsILocalFileMac" in Components.interfaces);

Use Services.appinfo.OS ?

Comment 17

[Dão Gottwald [:dao]]

Comment on attachment 8536906 [details] [diff] [review]
Patch v2

>--- /dev/null
>+++ b/browser/themes/linux/preferences/search.css

>+.searchengine-menuitem > .menu-iconic-left {
>+  display: -moz-box;
>+}

Use the menuitem-with-favicon class?

>+#engineList treechildren::-moz-tree-checkbox {
>+  list-style-image: url("chrome://browser/skin/checkbox.png");
>+  -moz-image-region: rect(0, 16px, 16px, 0);
>+}

This checkbox looks awfully alien over here. Why not just keep the standard appearance? It's not clear to me why these checkboxes should be different.

>+#engineList treechildren::-moz-tree-row {
>+  height: 20px;
>+}

Can you explain what this is trying to do?

Comment 18

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [:dao] from comment #17)
> >+#engineList treechildren::-moz-tree-checkbox {
> >+  list-style-image: url("chrome://browser/skin/checkbox.png");
> >+  -moz-image-region: rect(0, 16px, 16px, 0);
> >+}
> 
> This checkbox looks awfully alien over here. Why not just keep the standard
> appearance? It's not clear to me why these checkboxes should be different.

So I missed that you switched from a richlist to a classic tree. I'm not sure that's a great choice. Is there any way we can use the standard checkbox appearance there?

Comment 19

[Florian Quèze [:florian]]

(In reply to Dão Gottwald [:dao] from comment #18)

> Is there any way we can use the standard checkbox appearance there?

No, see bug 462618.

Comment 20

[Florian Quèze [:florian]]

(In reply to Dão Gottwald [:dao] from comment #17)
> Comment on attachment 8536906 [details] [diff] [review]
> Patch v2
> 
> >--- /dev/null
> >+++ b/browser/themes/linux/preferences/search.css
> 
> >+.searchengine-menuitem > .menu-iconic-left {
> >+  display: -moz-box;
> >+}
> 
> Use the menuitem-with-favicon class?

If I mxr that class, the only 2 CSS rules I find are:
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.css#510
510   .menuitem-with-favicon > .menu-iconic-left > .menu-iconic-icon {
511     image-rendering: -moz-crisp-edges;
512   }

and
http://mxr.mozilla.org/mozilla-central/source/toolkit/content/xul.css#370
370   :-moz-any(menuitem[type], .menuitem-with-favicon) > .menu-iconic-left {
371     visibility: visible;
372   }

I'm afraid neither of these rules will help with "display".


> >+#engineList treechildren::-moz-tree-row {
> >+  height: 20px;
> >+}
> 
> Can you explain what this is trying to do?

It's copied from http://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/engineManager.css#14
It ensures the height of the tree rows is large enough for a 16x16px provider icon to be displayed.

Comment 21

[Dão Gottwald [:dao]]

(In reply to Florian Quèze [:florian] [:flo] from comment #20)
> > >+.searchengine-menuitem > .menu-iconic-left {
> > >+  display: -moz-box;
> > >+}
> > 
> > Use the menuitem-with-favicon class?
> 
> If I mxr that class, the only 2 CSS rules I find are:
> http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.
> css#510
> 510   .menuitem-with-favicon > .menu-iconic-left > .menu-iconic-icon {
> 511     image-rendering: -moz-crisp-edges;
> 512   }
> 
> and
> http://mxr.mozilla.org/mozilla-central/source/toolkit/content/xul.css#370
> 370   :-moz-any(menuitem[type], .menuitem-with-favicon) > .menu-iconic-left {
> 371     visibility: visible;
> 372   }
> 
> I'm afraid neither of these rules will help with "display".

So why is this code needed in the first place? I blindly assumed you wanted to work around the fact that we normally hide menu-iconic-left on GTK.

> > >+#engineList treechildren::-moz-tree-row {
> > >+  height: 20px;
> > >+}
> > 
> > Can you explain what this is trying to do?
> 
> It's copied from
> http://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/
> engineManager.css#14
> It ensures the height of the tree rows is large enough for a 16x16px
> provider icon to be displayed.

Does it work like a min-height here? I.e. will the rows grow for larger text?

> > Is there any way we can use the standard checkbox appearance there?
> 
> No, see bug 462618.

Can we use an unboxed check mark then, like we do in other XUL trees? Mimicking a real checkbox and failing half-way looks rather cheap.

Comment 22

[Florian Quèze [:florian]]

(In reply to Dão Gottwald [:dao] from comment #21)
> (In reply to Florian Quèze [:florian] [:flo] from comment #20)
> > > >+.searchengine-menuitem > .menu-iconic-left {
> > > >+  display: -moz-box;
> > > >+}
> > > 
> > > Use the menuitem-with-favicon class?
> > 
> > If I mxr that class, the only 2 CSS rules I find are:
> > http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.
> > css#510
> > 510   .menuitem-with-favicon > .menu-iconic-left > .menu-iconic-icon {
> > 511     image-rendering: -moz-crisp-edges;
> > 512   }
> > 
> > and
> > http://mxr.mozilla.org/mozilla-central/source/toolkit/content/xul.css#370
> > 370   :-moz-any(menuitem[type], .menuitem-with-favicon) > .menu-iconic-left {
> > 371     visibility: visible;
> > 372   }
> > 
> > I'm afraid neither of these rules will help with "display".
> 
> So why is this code needed in the first place? I blindly assumed you wanted
> to work around the fact that we normally hide menu-iconic-left on GTK.

I work around http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/linux/global/menu.css#151
151 menulist > menupopup > menuitem > .menu-iconic-left,
152 menulist > menupopup > menu > .menu-iconic-left {
153   display: none;
154 }


> > It's copied from
> > http://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/
> > engineManager.css#14
> > It ensures the height of the tree rows is large enough for a 16x16px
> > provider icon to be displayed.
> 
> Does it work like a min-height here? I.e. will the rows grow for larger text?

I think so. It's just ported from the existing engine manager.

> > > Is there any way we can use the standard checkbox appearance there?
> > 
> > No, see bug 462618.
> 
> Can we use an unboxed check mark then, like we do in other XUL trees?

The check mark we use in other XUL trees (afaik only the session restore one) is absolutely awful. Bug 462618 was actually filed because UX wanted these checkboxes to look native. UX also asked for native checkboxes here, and provided the images I needed.

However, I'm happy to use your suggestion of unboxed check marks for the in-content version.

> Mimicking a real checkbox and failing half-way looks rather cheap.

On Windows and Mac I think these checkboxes will look like the native ones in most cases.

Comment 23

[Dão Gottwald [:dao]]

(In reply to Florian Quèze [:florian] [:flo] from comment #22)
> I work around
> http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/linux/global/
> menu.css#151
> 151 menulist > menupopup > menuitem > .menu-iconic-left,
> 152 menulist > menupopup > menu > .menu-iconic-left {
> 153   display: none;
> 154 }

Have you tried to find out what the purpose of that rule is? Does it exist only on Linux and if so, why?

> > Does it work like a min-height here? I.e. will the rows grow for larger text?
> 
> I think so. It's just ported from the existing engine manager.

Could you please test this?

> > Can we use an unboxed check mark then, like we do in other XUL trees?
> 
> The check mark we use in other XUL trees (afaik only the session restore
> one) is absolutely awful.

You mean the particular check mark image is awful, or that there's no box around it? The former can be fixed easily. I'd be careful with statements like "absolutely awful", because what I saw when opening the preferences window with this patch applied looked quite a bit more jarring than e.g. about:sessionrestore...

> > Mimicking a real checkbox and failing half-way looks rather cheap.
> 
> On Windows and Mac I think these checkboxes will look like the native ones
> in most cases.

Besides most cases, there's a long tail of other cases on Windows, and then there's Linux (also a tier 1 platform). I don't think this meets our quality bar there.

Comment 24

[Florian Quèze [:florian]]

(In reply to Dão Gottwald [:dao] from comment #23)
> (In reply to Florian Quèze [:florian] [:flo] from comment #22)
> > I work around
> > http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/linux/global/
> > menu.css#151
> > 151 menulist > menupopup > menuitem > .menu-iconic-left,
> > 152 menulist > menupopup > menu > .menu-iconic-left {
> > 153   display: none;
> > 154 }
> 
> Have you tried to find out what the purpose of that rule is?

It's already part of the first revision in hg. I don't think this is worth digging in CVS history right now.

> Does it exist only on Linux and if so, why?

Linux only, I don't know why.

> > > Does it work like a min-height here? I.e. will the rows grow for larger text?
> > 
> > I think so. It's just ported from the existing engine manager.
> 
> Could you please test this?

I will, and will change it to min-height if it's better.

> > > Can we use an unboxed check mark then, like we do in other XUL trees?
> > 
> > The check mark we use in other XUL trees (afaik only the session restore
> > one) is absolutely awful.
> 
> You mean the particular check mark image is awful, or that there's no box
> around it?

I mean the particular check mark image. And more specifically mixing that image in the same preference pane as a native checkbox. I'm not that annoyed with the sessionrestore appearance as there's no native checkbox next to the tree there (and probably also because I got used to it after a while).

> what I saw when opening the preferences
> window with this patch applied looked quite a bit more jarring than e.g.
> about:sessionrestore...

A screenshot would have been appreciated if there's something we can improve.

> > > Mimicking a real checkbox and failing half-way looks rather cheap.
> > 
> > On Windows and Mac I think these checkboxes will look like the native ones
> > in most cases.
> 
> Besides most cases, there's a long tail of other cases on Windows, and then
> there's Linux (also a tier 1 platform). I don't think this meets our quality
> bar there.

The goal here is to restore in 35 some functionality that's missing in 34. The patch here is relatively large and I would like to have QA spend some time on it soon before we uplift it to beta. I think we all agree that the checkbox appearance isn't ideal, but if we want to polish it, I think follow-up patches riding the trains will be better. Also, I'm following your advice of unboxed checkboxes for the in-content version (and it does look better there; thanks for the idea! :-)), so I think long-term you'll have something that looks like you want.

Comment 25

[Dão Gottwald [:dao]]

(In reply to Florian Quèze [:florian] [:flo] from comment #24)
> (In reply to Dão Gottwald [:dao] from comment #23)
> > (In reply to Florian Quèze [:florian] [:flo] from comment #22)
> > > I work around
> > > http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/linux/global/
> > > menu.css#151
> > > 151 menulist > menupopup > menuitem > .menu-iconic-left,
> > > 152 menulist > menupopup > menu > .menu-iconic-left {
> > > 153   display: none;
> > > 154 }
> > 
> > Have you tried to find out what the purpose of that rule is?
> 
> It's already part of the first revision in hg. I don't think this is worth
> digging in CVS history right now.

You can alternatively file a bug on it (and reference it in a CSS comment).

> > > > Can we use an unboxed check mark then, like we do in other XUL trees?
> > > 
> > > The check mark we use in other XUL trees (afaik only the session restore
> > > one) is absolutely awful.
> > 
> > You mean the particular check mark image is awful, or that there's no box
> > around it?
> 
> I mean the particular check mark image.

Could you please file a bug on that?

> > what I saw when opening the preferences
> > window with this patch applied looked quite a bit more jarring than e.g.
> > about:sessionrestore...
> 
> A screenshot would have been appreciated if there's something we can improve.

I'll attach a screenshot, but you can't really improve it using a static checkbox image. If you try to tweak it for my OS theme (Ubuntu default theme), you'll automatically make it worse for others. So this approach is pretty much a non-starter on Linux. Can you please rip out this part of the patch?

Comment 26

[Florian Quèze [:florian]]

(In reply to Florian Quèze [:florian] [:flo] from comment #24)

> > > > Does it work like a min-height here? I.e. will the rows grow for larger text?
> > > 
> > > I think so. It's just ported from the existing engine manager.
> > 
> > Could you please test this?
> 
> I will, and will change it to min-height if it's better.

min-height indeed works better here.

Comment 27

[Florian Quèze [:florian]]

(In reply to Dão Gottwald [:dao] from comment #25)
> Can you please rip out this part of the patch?

What do you suggest we do instead?

Comment 28

[Florian Quèze [:florian]]

(In reply to Florian Quèze [:florian] [:flo] from comment #27)
> (In reply to Dão Gottwald [:dao] from comment #25)
> > Can you please rip out this part of the patch?
> 
> What do you suggest we do instead?

Are you saying http://i.imgur.com/Pz2zfq8.png is better than http://i.imgur.com/xtsDG0P.png?

Comment 29

[Dão Gottwald [:dao]]

(In reply to Florian Quèze [:florian] [:flo] from comment #28)
> (In reply to Florian Quèze [:florian] [:flo] from comment #27)
> > (In reply to Dão Gottwald [:dao] from comment #25)
> > > Can you please rip out this part of the patch?
> > 
> > What do you suggest we do instead?
> 
> Are you saying http://i.imgur.com/Pz2zfq8.png is better than
> http://i.imgur.com/xtsDG0P.png?

Yes. Even if we don't improve the checkmark image (which we should), it looks more intentional than the pseudo checkboxes that quite obviously don't match the native checkbox in that window.

Comment 30

[Florian Quèze [:florian]]

(In reply to Dão Gottwald [:dao] from comment #25)
> (In reply to Florian Quèze [:florian] [:flo] from comment #24)
> > (In reply to Dão Gottwald [:dao] from comment #23)
> > > (In reply to Florian Quèze [:florian] [:flo] from comment #22)
> > > > I work around
> > > > http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/linux/global/
> > > > menu.css#151
> > > > 151 menulist > menupopup > menuitem > .menu-iconic-left,
> > > > 152 menulist > menupopup > menu > .menu-iconic-left {
> > > > 153   display: none;
> > > > 154 }
> > > 
> > > Have you tried to find out what the purpose of that rule is?
> > 
> > It's already part of the first revision in hg. I don't think this is worth
> > digging in CVS history right now.
> 
> You can alternatively file a bug on it (and reference it in a CSS comment).

Filed bug 1112310.

> > > > > Can we use an unboxed check mark then, like we do in other XUL trees?
> > > > 
> > > > The check mark we use in other XUL trees (afaik only the session restore
> > > > one) is absolutely awful.
> > > 
> > > You mean the particular check mark image is awful, or that there's no box
> > > around it?
> > 
> > I mean the particular check mark image.
> 
> Could you please file a bug on that?

Filed bug 1112306.

Comment 31

[Florian Quèze [:florian]]

Attachment: Patch v3

Comment 32

[Florian Quèze [:florian]]

Attachment: in-content version of the patch

Comment 33

[Dão Gottwald [:dao]]

Comment on attachment 8537436 [details] [diff] [review]
Patch v3

>--- a/browser/components/preferences/preferences.xul
>+++ b/browser/components/preferences/preferences.xul
>@@ -12,16 +12,17 @@
> <!-- XXX This should be in applications.xul, but bug 393953 means putting it
>    - there causes the Applications pane not to work the first time you open
>    - the Preferences dialog in a browsing session, so we work around the problem
>    - by putting it here instead.
>    -->
> <?xml-stylesheet href="chrome://browser/content/preferences/handlers.css"?>
> <?xml-stylesheet href="chrome://browser/skin/preferences/applications.css"?>
> <?xml-stylesheet href="chrome://browser/content/preferences/search.css"?>
>+<?xml-stylesheet href="chrome://browser/skin/preferences/search.css"?>

chrome://browser/content/preferences/search.css should be removed here.

Since we don't plan on using checkbox.png elsewhere and this is dying code, I'd prefer if you put that image in chrome://browser/skin/preferences/ instead of chrome://browser/skin/.

Comment 34

[Florian Quèze [:florian]]

https://hg.mozilla.org/integration/fx-team/rev/0171c1c791cd
https://hg.mozilla.org/integration/fx-team/rev/3d579d5a1f96

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0171c1c791cd
https://hg.mozilla.org/mozilla-central/rev/3d579d5a1f96

Comment 36

[Florian Quèze [:florian]]

Comment on attachment 8537436 [details] [diff] [review]
Patch v3

Approval Request Comment
[Feature/regressing bug #]: preference UI for the new search UI; regression in 34
[User impact if declined]: impossible to set search keywords, remove or move search engines.
[Describe test coverage new/current, TBPL]: currently on central. I'll coordinate with QA to check if they prefer the patch to bake a few days on central before landing on aurora/beta or if they prefer the patch to land everywhere asap.
[Risks and why]: moderate (the patch is relatively large, but also self contained), but I think acceptable at this point.
[String/UUID change made/needed]: the strings have landed earlier (comment 8).

Comment 37

[Florian Quèze [:florian]]

Comment on attachment 8537446 [details] [diff] [review]
in-content version of the patch

Approval Request Comment
[Feature/regressing bug #]: new search UI
[User impact if declined]: impossible to add search keywords, move or remove search engines from the in-content preferences (ie. high impact on aurora where it's pref'ed on, and low impact on beta where it's off by default).
[Describe test coverage new/current, TBPL]: will coordinate with QA.
[Risks and why]: acceptable: self contained change in a UI that isn't enabled on release yet.
[String/UUID change made/needed]: none.

We need this on aurora; it's not required on beta, but given that it's low risk there, I think we should take it there too for the sake of consistency.

Comment 38

[Sylvestre Ledru [:Sylvestre]]

Tracking in case Lukas wants it.

Comment 39

[Petruta Horea [:phorea], Desktop Test Engineering]

We tested the improved UI today using Nightly 37.0a1 2014-12-18 under Windows 7 64-bit, Windows 8.1 32-bit, Mac OS X 10.9.5 and Ubuntu 12.04 LTS 32-bit and spotted several issues as well as possible improvements:
- Typing the space character in the keyword field of a search engine, disables that search engine
- No notification when trying to add the same keyword for two search engines - the textarea from the second one remains on focus
- Artifact when editing a keyword, the keyword is displayed under the text-area
- Unnecessary scrollbar when entering about:preferences from url and then going to Search section (same if removing all search engines)
- The options to move search engines position and to add/edit keywords are not visible enough

Detailed testing and steps to reproduce as well as some other improvements ideas at https://etherpad.mozilla.org/Fx34b4-Search

Please check the etherpad and let us know what needs to be logged.

Comment 40

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6a72715d7035
https://hg.mozilla.org/releases/mozilla-aurora/rev/6aa407bf00ef

https://hg.mozilla.org/releases/mozilla-beta/rev/1c41baddf78f
https://hg.mozilla.org/releases/mozilla-beta/rev/d70d976bf024

Comment 41

[Florian Quèze [:florian]]

(In reply to Petruta Rasa [QA] [:petruta] from comment #39)
> We tested the improved UI today using Nightly 37.0a1 2014-12-18 under
> Windows 7 64-bit, Windows 8.1 32-bit, Mac OS X 10.9.5 and Ubuntu 12.04 LTS
> 32-bit and spotted several issues as well as possible improvements:
> - Typing the space character in the keyword field of a search engine,
> disables that search engine

This appears both with the standalone dialog and with the in-content version; I would like to fix it for 35.

> - No notification when trying to add the same keyword for two search engines
> - the textarea from the second one remains on focus
> - Artifact when editing a keyword, the keyword is displayed under the
> text-area
> - Unnecessary scrollbar when entering about:preferences from url and then
> going to Search section (same if removing all search engines)

These issues seem to be only for the in-content version; we should fix them, but that's less urgent.

> - The options to move search engines position and to add/edit keywords are
> not visible enough

I'm not sure if it's a bug, or if it's expected that only advanced users would need these features, and they would be able to discover them. You can still file a bug and needinfo UX people to get confirmation.


> Detailed testing and steps to reproduce as well as some other improvements
> ideas at https://etherpad.mozilla.org/Fx34b4-Search
> 
> Please check the etherpad and let us know what needs to be logged.

Several good bugs to file, thanks! I added a few comments in the pad.

Assuming you haven't done it yet, could you please also test the preferences in a separate dialog (set browser.preferences.inContent to false from about:config), as that's what's going to be visible by default in Firefox 35?

Comment 42

[Tim Nguyen :ntim]

Release Note Request (optional, but appreciated)
[Why is this notable]: Many search features were restored
[Suggested wording]: More features in new search UI.
[Links (documentation, blog post, etc)]:

Comment 43

[Petruta Horea [:phorea], Desktop Test Engineering]

Verified the preferences in a separate dialog in Firefox 35 RC build.

Comment 44

[Petruta Horea [:phorea], Desktop Test Engineering]

Verified as fixed under Ubuntu 12.04 LTS 32-bit, Windows 7 64-bit and Mac OS X 10.9.5, versions 36 and 37.