Closed Bug 1224150 Opened 9 years ago Closed 9 years ago

Downgrading to FF 44 and upgrading back to FF 45 loses the search settings saved after the downgrade

Categories

(Firefox :: Search, defect, P1)

defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox45 --- affected

People

(Reporter: sbadau, Unassigned)

References

Details

(Whiteboard: [fxsearch])

Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20151111030207

Steps to reproduce:
1. Install the latest Nightly 45.0a1
2. Launch Nightly 45.0a1
3. Go to Preferences -> Advanced -> Update -> check Never Check for updates
4. Install Nightly 44.0a1
5. Launch Nightly 44.0a1 (on the same Firefox profile that was used in step 2)
6. In the Search toolbar, click on the magnifying glass and select "Change Search Settings"
7. Click on the "Add more search engines..." link
8. Install the YouTube search engine and make it the default search engine
9. Update to the latest Nightly (Open Menu -> Open Help menu -> About Nightly -> Check for updates -> Update to 45.0a1 -> restart Nightly to Update).
10. Perform a search

Expected results:
The search should be done using the YouTube search engine.

Actual results:
The search is done using Google.
Blocks: 1203167
I don't know that we support downgrading Firefox in that way. Kev, Florian?
Afaik, we should always allow to downgrade at least one version, if a user hits a startup crash or similar issues that disallow using firefox (it happened in the past with intel graphics drivers), he must be able to go back 1 version until we can fix the problem.
Most migration code is written to always allow at least one downgrade.
Priority: -- → P1
Whiteboard: [fxsearch]
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20151112030238

This problem is also reproduced on Mac Os X.
We do allow downgrading, but not this specific case.

While working on bug 1203167, I ensured that if someone uses Fx44, then upgrades to 45, and then downgrades to 44, all the settings that had been set in Firefox 44 are still available in Firefox 44 (and they are also migrated to Firefox 45 of course). However, if someone changes search settings in Firefox 45, Firefox 44 won't be able to see them.

Fixing the case in comment 0 would require overwriting the search settings set by Firefox 45 (but ignored by Firefox 44) with the settings saved by Firefox 44. It could probably be achieved by removing (or renaming away) the new search.json.mozlz4 file before the search service is started, but I don't think it's a good idea. If we do decide to do it, I think it should be limited to 1 version and be backed out after that, to address only the startup case you mentioned, and not make us more hijacking prone. Losing some search settings when moving back and forth between versions isn't terrible though, so I'm going to wontfix this bug for now.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Summary: Downgrading to FF 44 and upgrading back to FF 45 breaks the search engine → Downgrading to FF 44 and upgrading back to FF 45 loses the search settings saved after the downgrade
Tried following scenario:

1. Install Nightly 44 and create a new profile.
2. Add new search engine and set it the default search engine, for e.g. Youtube.
3. Upgrade to Nightly 45 -> default search engine is Youtube.
4. Install new engine, like Facebook Search engine, and set it the default engine.
5. Downgrade to Nightly 44--> default search engine is Youtube(this is ok)
6. Set default search engine eBay.
7. Upgrade to Nightly 45.

Expected:
 Default search engine should be eBay.

Actual:
 Default search engine is Facebook.


In this case shouldn't the settings done in FF 44 be visible in FF 45?
Like I said in comment 4, I don't think that case matters (if some specific users get really frustrated by this, I think we can tell them to go remove the search.json.mozlz4 file from the profile by hand to force another conversion of the old data to the new format).
You need to log in before you can comment on or make changes to this bug.