Closed
Bug 1306308
Opened 8 years ago
Closed 8 years ago
[One-off searches] Awesomebar results don't show the correct search engine when searching with search engine keywords
Categories
(Firefox :: Search, defect, P1)
Firefox
Search
Tracking
()
VERIFIED
FIXED
Firefox 52
Tracking | Status | |
---|---|---|
firefox49 | --- | unaffected |
firefox50 | --- | unaffected |
firefox51 | --- | verified |
firefox52 | --- | verified |
People
(Reporter: cirdeiliviu, Assigned: adw)
References
Details
(Keywords: regression, Whiteboard: [fxsearch])
Attachments
(3 files)
168.62 KB,
image/jpeg
|
Details | |
58 bytes,
text/x-review-board-request
|
mak
:
review+
|
Details |
1.92 KB,
patch
|
gchang
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
[Affected versions]:
Nightly 52.0a1 Build ID 20160928030201
[Affected platforms]:
All (Windows 10, Mac 10.12, Ubuntu 16.04)
[Steps to reproduce]:
1. Open Firefox with a new profile.
2. Go to about:preferences#search.
3. Add a keyword for one search engine(e.g for Bing add "bn" keyword).
4. In Awesomebar type the keyword from step 3 and a search term (e.g "bn mozilla").
5. Inspect the results from the dropdown.
[Expected result]:
Results from Awesomebar should state that the search will be performed with "Bing" (e.g. "mozilla - Search with Bing").
[Actual result]
Results from Awesomebar state that the search will be performed with Google even if the search is performed with Bing. Note that the Bing icon is present, just the text seems to be wrong.
[Regression Range]
Pushlog: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=46045ec8a4aa09a341b7209170089ade3c27c1a5&tochange=555caa0082c342c60830261ecba4c4068122207e
Regressed by bug 1180944.
Updated•8 years ago
|
Assignee | ||
Comment 1•8 years ago
|
||
Question to figure out: does this affect Aurora too or only Nightly?
Reporter | ||
Comment 2•8 years ago
|
||
I was surprised to see this, but it affects Aurora too, even if the preference for on-off-searches is turned off.
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → adw
Status: NEW → ASSIGNED
Comment hidden (mozreview-request) |
Assignee | ||
Comment 4•8 years ago
|
||
urlbar's overrideSearchEngineName is too defensive. It should not return an engine name when there is no selected one-off button because it will clobber searchengines embedded in mozactions as in this case.
Assignee | ||
Comment 5•8 years ago
|
||
(In reply to Liviu Cirdei [:liviucirdei] from comment #2)
> I was surprised to see this, but it affects Aurora too, even if the
> preference for on-off-searches is turned off.
I can see how it might be surprising, but the one-off searches work touched quite a bit of the underlying urlbar and autocomplete code, even though the final user-facing result is preffed off. So it's possible there are other non-Nightly regressions -- hopefully not! :-)
Comment 6•8 years ago
|
||
mozreview-review |
Comment on attachment 8801451 [details]
Bug 1306308 - [One-off searches] Awesomebar results don't show the correct search engine when searching with search engine keywords.
https://reviewboard.mozilla.org/r/86200/#review85280
::: browser/base/content/urlbarBindings.xml:1696
(Diff revision 1)
> <!-- Result listitems call this to determine which search engine they
> should show in their labels and include in their url attributes. -->
> <property name="overrideSearchEngineName" readonly="true">
> <getter><![CDATA[
> - // When building the popup, autocomplete reuses an item at index i if
> - // that item's url attribute matches the controller's value at index
> + let button = this.oneOffSearchButtons.selectedButton;
> + return button && button.engine ? button.engine.name : null;
return button && button.engine && button.engine.name;
Attachment #8801451 -
Flags: review?(mak77) → review+
Comment hidden (mozreview-request) |
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7ef1bb323867
[One-off searches] Awesomebar results don't show the correct search engine when searching with search engine keywords. r=mak
Comment 9•8 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
Assignee | ||
Comment 10•8 years ago
|
||
Approval Request Comment
[Feature/regressing bug #]:
One-off searches in the urlbar, bug 1180944. That feature is disabled on non-Nightly, but its supporting code changes are shipping on all branches starting in 51, and they caused this regression.
[User impact if declined]:
Search engine keywords can't be used from the urlbar
[Describe test coverage new/current, TreeHerder]:
Manually tested
[Risks and why]:
Low risk, very tiny and straightforward patch
[String/UUID change made/needed]:
None
Attachment #8802343 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 11•8 years ago
|
||
(In reply to Drew Willcoxon :adw from comment #10)
> [User impact if declined]:
> Search engine keywords can't be used from the urlbar
Sorry, they *work* correctly, they just aren't *shown* right in the urlbar popup. e.g., the popup will say "Search with Google" when it should say "Search with Bing"
Comment 12•8 years ago
|
||
Comment on attachment 8802343 [details] [diff] [review]
Aurora 51 patch
Fix a regression related to awesomebar. Take it in 51 aurora.
Attachment #8802343 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 13•8 years ago
|
||
I have reproduced this bug with Nightly 52.0a1 (2016-09-29) (64-bit) on Windows 7 , 64 Bit !
This bug's fix is verified with latest Nightly
Build ID : 20161019030208
User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
[bugday-20161019]
Comment 14•8 years ago
|
||
bugherder uplift |
Comment 15•8 years ago
|
||
bugherder uplift |
Reporter | ||
Comment 16•8 years ago
|
||
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID 20161020004015
Version 51.0a2
The fix is also verified on Aurora 51.
I tested on Windows 10, Mac 10.11 and Ubuntu 16.04.
Updated•6 years ago
|
Flags: in-qa-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•