Closed
Bug 1106559
Opened 10 years ago
Closed 10 years ago
Improve the search preference UI (add ability to edit keywords, reorder/remove engines, restore defaults)
Categories
(Firefox :: Search, defect)
Firefox
Search
Tracking
()
People
(Reporter: gaston, Assigned: florian)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: regression)
Attachments
(3 files, 3 obsolete files)
(deleted),
patch
|
Felipe
:
review+
Gavin
:
approval-mozilla-aurora+
Gavin
:
approval-mozilla-beta+
florian
:
checkin+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
dao
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Felipe
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•10 years ago
|
||
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.
Assignee | ||
Comment 2•10 years ago
|
||
(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.
Depends on: 1106055
Updated•10 years ago
|
OS: OpenBSD → All
Hardware: x86_64 → All
Version: 34 Branch → Trunk
Updated•10 years ago
|
Flags: firefox-backlog+
Assignee | ||
Comment 4•10 years ago
|
||
The theming still needs love, but apart from that I think it's ready for review.
Assignee | ||
Updated•10 years ago
|
Points: --- → 8
Flags: qe-verify+
Assignee | ||
Comment 5•10 years ago
|
||
Updated•10 years ago
|
Iteration: --- → 37.2
Assignee | ||
Comment 6•10 years ago
|
||
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.
Attachment #8535295 -
Flags: review?(felipc)
Attachment #8535295 -
Flags: approval-mozilla-beta?
Attachment #8535295 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
Attachment #8535295 -
Flags: approval-mozilla-beta?
Attachment #8535295 -
Flags: approval-mozilla-beta+
Attachment #8535295 -
Flags: approval-mozilla-aurora?
Attachment #8535295 -
Flags: approval-mozilla-aurora+
Updated•10 years ago
|
Attachment #8535295 -
Flags: review?(felipc) → review+
Assignee | ||
Comment 8•10 years ago
|
||
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
Attachment #8535295 -
Flags: checkin+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 37
Comment 10•10 years ago
|
||
Not yet fixed in Nightly as well as Beta, Aurora.
Status: RESOLVED → REOPENED
Flags: needinfo?(kwierso)
Resolution: FIXED → ---
Updated•10 years ago
|
Flags: needinfo?(florian)
Comment 11•10 years ago
|
||
[Tracking Requested - why for this release]:
status-firefox35:
--- → affected
status-firefox36:
--- → affected
status-firefox37:
--- → affected
tracking-firefox35:
--- → ?
tracking-firefox36:
--- → ?
tracking-firefox37:
--- → ?
Assignee | ||
Updated•10 years ago
|
Status: REOPENED → ASSIGNED
Flags: needinfo?(kwierso)
Flags: needinfo?(florian)
Comment 13•10 years ago
|
||
>> +<!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).
Updated•10 years ago
|
Assignee | ||
Comment 14•10 years ago
|
||
Attaching an interdiff of the additional change for easier review by felipe.
Assignee | ||
Updated•10 years ago
|
Summary: No way to change search keywords after bug 1088660 → Improve the search preference UI
Assignee | ||
Comment 15•10 years ago
|
||
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?
Flags: needinfo?(dao)
Attachment #8536906 -
Flags: review?(felipc)
Comment 16•10 years ago
|
||
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 ?
Attachment #8536906 -
Flags: review?(felipc) → review+
Updated•10 years ago
|
Attachment #8534637 -
Flags: review?(felipc)
Assignee | ||
Updated•10 years ago
|
Attachment #8534637 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Attachment #8536901 -
Attachment is obsolete: true
Comment 17•10 years ago
|
||
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?
Flags: needinfo?(dao)
Attachment #8536906 -
Flags: review-
Comment 18•10 years ago
|
||
(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?
Assignee | ||
Comment 19•10 years ago
|
||
(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.
Assignee | ||
Comment 20•10 years ago
|
||
(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•10 years ago
|
||
(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.
Assignee | ||
Comment 22•10 years ago
|
||
(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•10 years ago
|
||
(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.
Assignee | ||
Comment 24•10 years ago
|
||
(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•10 years ago
|
||
(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?
Assignee | ||
Comment 26•10 years ago
|
||
(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.
Assignee | ||
Comment 27•10 years ago
|
||
(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?
Assignee | ||
Comment 28•10 years ago
|
||
(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•10 years ago
|
||
(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.
Assignee | ||
Comment 30•10 years ago
|
||
(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.
Assignee | ||
Comment 31•10 years ago
|
||
Attachment #8536906 -
Attachment is obsolete: true
Attachment #8537436 -
Flags: review?(dao)
Assignee | ||
Comment 32•10 years ago
|
||
Attachment #8537446 -
Flags: review?(felipc)
Updated•10 years ago
|
Attachment #8537446 -
Flags: review?(felipc) → review+
Comment 33•10 years ago
|
||
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/.
Attachment #8537436 -
Flags: review?(dao) → review+
Assignee | ||
Comment 34•10 years ago
|
||
Comment 35•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0171c1c791cd
https://hg.mozilla.org/mozilla-central/rev/3d579d5a1f96
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 36•10 years ago
|
||
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).
Attachment #8537436 -
Flags: approval-mozilla-beta?
Attachment #8537436 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 37•10 years ago
|
||
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.
Attachment #8537446 -
Flags: approval-mozilla-beta?
Attachment #8537446 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
QA Contact: petruta.rasa
Updated•10 years ago
|
Attachment #8537436 -
Flags: approval-mozilla-beta?
Attachment #8537436 -
Flags: approval-mozilla-beta+
Attachment #8537436 -
Flags: approval-mozilla-aurora?
Attachment #8537436 -
Flags: approval-mozilla-aurora+
Updated•10 years ago
|
Attachment #8537446 -
Flags: approval-mozilla-beta?
Attachment #8537446 -
Flags: approval-mozilla-beta+
Attachment #8537446 -
Flags: approval-mozilla-aurora?
Attachment #8537446 -
Flags: approval-mozilla-aurora+
Comment 39•10 years ago
|
||
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•10 years ago
|
||
Assignee | ||
Comment 41•10 years ago
|
||
(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•10 years ago
|
||
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)]:
relnote-firefox:
--- → ?
Updated•10 years ago
|
Summary: Improve the search preference UI → Improve the search preference UI (add ability to edit keywords, reorder/remove engines, restore defaults)
Updated•10 years ago
|
Comment 43•10 years ago
|
||
Verified the preferences in a separate dialog in Firefox 35 RC build.
Comment 44•10 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•