If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Search activity startup crash @ java.lang.IllegalArgumentException: Couldn''t find search engine for identifier: yahoo at org.mozilla.search.providers.SearchEngineManager.createEngine(SearchEngineManager.java)

VERIFIED FIXED in Firefox 35

Status

()

Firefox for Android
Search Activity
--
critical
VERIFIED FIXED
3 years ago
a year ago

People

(Reporter: Thomas Stache, Assigned: Margaret)

Tracking

(Blocks: 1 bug, {crash, steps-wanted})

Trunk
Firefox 35
All
Android
crash, steps-wanted
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox35 verified, fennec35+)

Details

(crash signature)

Attachments

(2 attachments)

Comment hidden (empty)
(Reporter)

Comment 1

3 years ago
https://crash-stats.mozilla.com/report/index/79667d99-04c5-495b-b3a6-2ecb92140909
(Reporter)

Comment 2

3 years ago
https://crash-stats.mozilla.com/report/index/f9e4ef78-f8c9-442e-a254-d6dc92140909
Any steps to reproduce?
Status: UNCONFIRMED → NEW
Crash Signature: [@ java.lang.IllegalArgumentException: Couldn''t find search engine for identifier: yahoo at org.mozilla.search.providers.SearchEngineManager.createEngine(SearchEngineManager.java)]
Ever confirmed: true
Was this what Margaret was discussing about in IRC channel?
Severity: normal → critical
tracking-fennec: --- → ?
status-firefox35: --- → affected
Keywords: crash, steps-wanted
Hardware: Other → All

Updated

3 years ago
Summary: Search activity startup crash → Search activity startup crash @ java.lang.IllegalArgumentException: Couldn''t find search engine for identifier: yahoo at org.mozilla.search.providers.SearchEngineManager.createEngine(SearchEngineManager.java)
(Assignee)

Comment 5

3 years ago
Yes, this must be happening in a locale that doesn't include yahoo in its search plugins. Once bug 1024527 is fixed, localizers will be able to indicate a default search engine, which should solve this.

However, perhaps instead of crashing we should just end up in a no-engine-selected state, so at least the user can go into settings to try to pick a different engine.
Assignee: nobody → margaret.leibovic
Blocks: 1017135
(Reporter)

Comment 6

3 years ago
(In reply to Kevin Brosnan [:kbrosnan] from comment #3)
> Any steps to reproduce?

Just launch the search activity from the Firefox widget or the Android "Google Now gesture".
(Reporter)

Comment 7

3 years ago
Aren't Fennec nightlies en-us? (can't check, as the device is not with me)
The Android install is indeed de-de, however.
(Assignee)

Updated

3 years ago
Blocks: 1065306
(Assignee)

Updated

3 years ago
Blocks: 1024527
(Assignee)

Comment 8

3 years ago
Created attachment 8487094 [details] [diff] [review]
Don't crash if the default engine isn't found

The search activity will be pretty useless in this case, but at least the user can still go to settings to choose a valid search engine.

We should never hit this case in real localized builds, but this will be good for pre-release testers and localizers.
Attachment #8487094 - Flags: review?(nalexander)

Updated

3 years ago
Status: NEW → ASSIGNED
Comment on attachment 8487094 [details] [diff] [review]
Don't crash if the default engine isn't found

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

This looks fine to me.  Ship it!

::: mobile/android/search/java/org/mozilla/search/providers/SearchEngineManager.java
@@ +109,5 @@
>  
>              @Override
>              protected void onPostExecute(SearchEngine engine) {
>                  // Only touch engine on the main thread.
>                  SearchEngineManager.this.engine = engine;

Should we be setting this at all?
Attachment #8487094 - Flags: review?(nalexander) → review+
(Assignee)

Comment 10

3 years ago
(In reply to Nick Alexander :nalexander from comment #9)
> Comment on attachment 8487094 [details] [diff] [review]
> Don't crash if the default engine isn't found
> 
> Review of attachment 8487094 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This looks fine to me.  Ship it!
> 
> :::
> mobile/android/search/java/org/mozilla/search/providers/SearchEngineManager.
> java
> @@ +109,5 @@
> >  
> >              @Override
> >              protected void onPostExecute(SearchEngine engine) {
> >                  // Only touch engine on the main thread.
> >                  SearchEngineManager.this.engine = engine;
> 
> Should we be setting this at all?

I suppose there's not much reason to if it's null.
(Assignee)

Comment 11

3 years ago
https://hg.mozilla.org/integration/fx-team/rev/29475f2d0097
https://github.com/mozilla/fennec-search/commit/df76b06ce5912b53c9a537abfc2361db801c4f04
https://hg.mozilla.org/mozilla-central/rev/29475f2d0097
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
tracking-fennec: ? → 35+
This remains the #2 top crash for Firefox for Android 35.0a1 however there are 0 reports involving a build generated after September 10. 

Thomas, since you reported this crash originally, could you please update to the latest Nightly and verify this is resolved?
Flags: needinfo?(ts.bugzilla)
(Reporter)

Comment 14

3 years ago
Created attachment 8489565 [details]
Screenshot of search engine settings without a selection

The startup crash is gone. The screenshot shows what Margaret said would happen: Search starts without an active engine. There is no indication what's wrong, though. You can initiate searches, but just nothing happens.

This is Nightly 20140911. What I do not understand is why this is a locale issue? Nightly is running in en-US, the screenshot shows that the Search Activity is running in English. Why does it not find/select Yahoo?
Flags: needinfo?(ts.bugzilla)
Thanks Thomas, I'm marking this bug verified fixed based on your confirmation that the startup crash is gone. Crash stats seem to support this as well.

I'll leave it to Margaret to address your concerns raised in your second paragraph.
Status: RESOLVED → VERIFIED
status-firefox35: affected → verified
(Reporter)

Comment 16

3 years ago
(from comment #14)
> What I do not understand is why this is a locale
> issue? Nightly is running in en-US, the screenshot shows that the Search
> Activity is running in English. Why does it not find/select Yahoo?

Margaret, can you tell if the locale dependency makes sense (please see quote)?
Flags: needinfo?(margaret.leibovic)
(Assignee)

Comment 17

3 years ago
(In reply to Thomas Stache from comment #16)
> (from comment #14)
> > What I do not understand is why this is a locale
> > issue? Nightly is running in en-US, the screenshot shows that the Search
> > Activity is running in English. Why does it not find/select Yahoo?
> 
> Margaret, can you tell if the locale dependency makes sense (please see
> quote)?

The screenshot actually shows the search activity running in German (I see Amazon.de), or at least BrowserLocaleManager is returing German as the locale when it fetches search engines. The strings were in English because of bug 1024527, but if localizers have been able to start working on translating them, they should start to appear in German. Can you file a separate bug for us to investigate this? It sounds like there is a bug in our locale switching logic.
Flags: needinfo?(margaret.leibovic)
(Assignee)

Comment 18

3 years ago
(In reply to :Margaret Leibovic from comment #17)
> (In reply to Thomas Stache from comment #16)
> > (from comment #14)
> > > What I do not understand is why this is a locale
> > > issue? Nightly is running in en-US, the screenshot shows that the Search
> > > Activity is running in English. Why does it not find/select Yahoo?
> > 
> > Margaret, can you tell if the locale dependency makes sense (please see
> > quote)?
> 
> The screenshot actually shows the search activity running in German (I see
> Amazon.de), or at least BrowserLocaleManager is returing German as the
> locale when it fetches search engines. The strings were in English because
> of bug 1024527, but if localizers have been able to start working on
> translating them, they should start to appear in German. Can you file a
> separate bug for us to investigate this? It sounds like there is a bug in
> our locale switching logic.

FYI, Aaron filed bug 1068127 about this, we can use that bug to track fixing this.
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.