940446 - Broken search engines and urlbar after update to Nightly 2013-11-07, if malformed/old search plugin is installed

Status: VERIFIED FIXED

(Firefox :: Search, defect)

Description

[Semtex]

STR:

1. Create new profile and install Nightly from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-11-06-03-02-00-mozilla-central/
2. Instal (for example) this search engine: https://addons.mozilla.org/PL/firefox/addon/google-pl/?src=search
2. Set it as first one (default)
3. Update Nightly to (manual): http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-11-07-03-02-00-mozilla-central/
4. Search Engines are death, not possible to type in URLbar. 

To solve problem: close Nightly, open profile folder, delete this Google PL, Nightly will start normal, install this engine one more time-> no problems.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Steven, can you look into this one?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Thanks!

Comment 3

[Manuela Muntean [Away]]

Works for me following the STR from comment 0.

Note: I've downloaded the Nightly 32-bit builds mentioned in the STR, for the OS I've tested this with: Win 7 64bit.

Comment 4

[Semtex]

(In reply to Manuela Muntean [:Manuela] [QA] from comment #3)
> Works for me following the STR from comment 0.
> 
> Note: I've downloaded the Nightly 32-bit builds mentioned in the STR, for
> the OS I've tested this with: Win 7 64bit.

So You was able to reproduce or not?

Comment 5

[Manuela Muntean [Away]]

(In reply to Semtex from comment #4)
> (In reply to Manuela Muntean [:Manuela] [QA] from comment #3)
> > Works for me following the STR from comment 0.
> > 
> > Note: I've downloaded the Nightly 32-bit builds mentioned in the STR, for
> > the OS I've tested this with: Win 7 64bit.
> 
> So You was able to reproduce or not?

No, I didn't reproduce the issue. Works for me.

Comment 6

[Semtex]

Strange, problem was conformed here:
Post Posted 10 Nov 2013, 22:52 : http://forums.mozillazine.org/viewtopic.php?f=23&t=2769029
Posted 08 Nov 2013, 08:06 : http://forums.mozillazine.org/viewtopic.php?f=23&t=2767889
And My first post with this problem
 Posted 07 Nov 2013, 17:15 http://forums.mozillazine.org/viewtopic.php?f=23&t=2767361&p=13170011#p13170011

I've removed this issue, I thought, I've corrupted profile, but after few hours of testing I've found solution described in Comment 0.

Comment 7

[Gummi]

Still present here, I've uploaded something to trigger the bug:

Stop firefox, find the profile directory (~/.mozilla/firefox/*.default/ for example)
curl http://ix.io/917 > $MOZPROFILE/searchplugins/google-ssl.xml
Start firefox, most things are broken including the search bar and location bar.

Comment 8

[Manuela Muntean [Away]]

I've repeated the STR from comment 0.

> Stop firefox, find the profile directory (~/.mozilla/firefox/*.default/ for
> example)

Then  I did this.

> curl http://ix.io/917 > $MOZPROFILE/searchplugins/google-ssl.xml

Then I've opened a terminal, changed the current directory to the one containing the Firefox profile used for testing, and then gave this command " curl http://ix.io/917 > $MOZPROFILE/searchplugins/google-ssl.xml "

I get this error in the terminal:  The system cannot find the path specified. 

> Start firefox, most things are broken including the search bar and location
> bar.

After restarting Nightly, both searches (from URL bar and search bar) still work.

So, I still can't reproduce this issue.

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I'm seeing the same symptoms on my primary Firefox profile, with the same regression range (regressed between nightlies of the 6th and the 7th, i.e., https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9ba3faa35c96&tochange=70de5e24d79b ), on 64-bit Linux.

On startup, I see the following errors on the console (with the same regression range):

*************************
A coding exception was thrown and uncaught in a Task.

Full message: ReferenceError: file is not defined
Full stack: @resource://gre/components/nsSearchService.js:3293
TaskImpl_run@resource://gre/modules/Task.jsm:234
reject@resource://gre/modules/commonjs/sdk/core/promise.js:133
then@resource://gre/modules/commonjs/sdk/core/promise.js:52
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
reject@resource://gre/modules/commonjs/sdk/core/promise.js:134
then@resource://gre/modules/commonjs/sdk/core/promise.js:52
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
reject@resource://gre/modules/commonjs/sdk/core/promise.js:139
then@resource://gre/modules/commonjs/sdk/core/promise.js:52
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
reject@resource://gre/modules/commonjs/sdk/core/promise.js:208
TaskImpl_handleException@resource://gre/modules/Task.jsm:301
TaskImpl_run@resource://gre/modules/Task.jsm:245
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:118
then@resource://gre/modules/commonjs/sdk/core/promise.js:43
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
@resource://gre/components/nsSearchService.js:1295

*************************
*************************
A coding exception was thrown and uncaught in a Task.

Full message: ReferenceError: file is not defined
Full stack: @resource://gre/components/nsSearchService.js:3293
TaskImpl_run@resource://gre/modules/Task.jsm:234
reject@resource://gre/modules/commonjs/sdk/core/promise.js:133
then@resource://gre/modules/commonjs/sdk/core/promise.js:52
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
reject@resource://gre/modules/commonjs/sdk/core/promise.js:134
then@resource://gre/modules/commonjs/sdk/core/promise.js:52
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
reject@resource://gre/modules/commonjs/sdk/core/promise.js:139
then@resource://gre/modules/commonjs/sdk/core/promise.js:52
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
reject@resource://gre/modules/commonjs/sdk/core/promise.js:208
TaskImpl_handleException@resource://gre/modules/Task.jsm:301
TaskImpl_run@resource://gre/modules/Task.jsm:245
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:118
then@resource://gre/modules/commonjs/sdk/core/promise.js:43
resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
@resource://gre/components/nsSearchService.js:1295

*************************

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: possible patch

This fixes the problem for me, though I'm not sure if it's what was originally intended.  (And what if the exception was thrown by the osfile.path getter itself?)

Also, if this needs a test, I'm not sure where one would go.

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Oh, and with the patch, if I:

 * flip the browser.search.log pref to true in about:config
 * quit the browser
 * edit <profile-dir>/search.json to have a different build ID to force the cache to rebuild
 * start the browser again

then I see in my browser console:

_asyncLoadEnginesFromDir: Failed to load /<profile-dir>/searchplugins/google.xml!
[Exception... "/<profile-dir>/searchplugins/google.xml is not a valid search plugin."  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///home/dbaron/bin/running-firefox/components/nsSearchService.js :: FAIL :: line 267"  data: no]

so the problem is related to an old google search plugin I have lying around.

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: the old google.xml in question

Comment 13

[Steven MacLeod [:smacleod]]

Comment on attachment 8338064 [details] [diff] [review]
possible patch

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

Yeah, this change looks fine to me.

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #10)
> This fixes the problem for me, though I'm not sure if it's what was
> originally intended.  (And what if the exception was thrown by the
> osfile.path getter itself?)

I believe the exception here is just a scoping issue, since in the catch
block the "let file" from the try block isn't in scope.

Comment 14

[Steven MacLeod [:smacleod]]

Comment on attachment 8338064 [details] [diff] [review]
possible patch

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

Ah sorry, meant to mark r+ instead of f+. I'm happy with this.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #12)
> Created attachment 8338132 [details]
> the old google.xml in question

Hmm, interesting that this file exists in your profile. A Sherlock file with a .xml extension makes me wonder if the (now-removed) Sherlock migration code was broken somehow :/

Comment 16

[:Gavin Sharp [email: [e-mail]]]

And thanks for fixing, dbaron. It should be relatively easy to write an xpcshell test for this case. Steven, want to take this and do that?

Comment 17

[Steven MacLeod [:smacleod]]

(In reply to :Gavin Sharp (email [e-mail]) from comment #16)
> And thanks for fixing, dbaron. It should be relatively easy to write an
> xpcshell test for this case. Steven, want to take this and do that?

Sure, I'll do that in Bug 943571

Comment 18

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/778a10a2b497

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/778a10a2b497

Comment 20

[u279076]

Flagging for verification to do some exploratory testing around this usecase.

Comment 21

[Bogdan Maris, Desktop Test Engineering]

I was not able to reproduce the initial issue using steps from comment 0 and comment 7. I also did some exploratory around a possible regression here using the latest Aurora and various search engines. 

Semtex can you please confirm that using latest Aurora you don`t encounter this issue anymore?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/

Comment 22

[Semtex]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #21)
> I was not able to reproduce the initial issue using steps from comment 0 and
> comment 7. I also did some exploratory around a possible regression here
> using the latest Aurora and various search engines. 
> 
> Semtex can you please confirm that using latest Aurora you don`t encounter
> this issue anymore?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/

WFM on my side, good job.

Comment 23

[u279076]

(In reply to Semtex from comment #22)
> WFM on my side, good job.

Thanks!