637639 - if dom storage is disabled when the profile is upgraded, about:home remains broken even after dom storage is re-enabled

Status: NEW

(Firefox :: General, defect)

Description

[al_9x]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

localStorage["search-engine"] remains null in about:home

Error: gSearchEngine is null
Source File: chrome://browser/content/aboutHome.js
Line: 184

and the search from about:home doesn't work

As a workaround, how do you fix about:home, after the fact.

Reproducible: Always

Steps to Reproduce:
1. create a new profile in 3.6.13
2. set dom.storage.enabled=false
3. upgrade the profile to 4.0b12
4. initially about:home is broken due to bug 637561
Error: localStorage is null
Source File: chrome://browser/content/aboutHome.js
Line: 181
5. set dom.storage.enabled=true and reload about:home
6. the page remains broken
Error: gSearchEngine is null
Source File: chrome://browser/content/aboutHome.js
Line: 184

Comment 1

[Shawn Wilsher :sdwilsh]

If this gets confirmed, I think this might be a hardblocker.

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

It is confirmed for sure, it happens because we update the dom storage contents only on upgrade, if it's disabled we cannot update it.
I think it doesn't block though. Dom storage supports being disabled for testing purposes (for example if a web dev wants to test his webapp/page with dom storage enabled/disabled) and must be explicitly disabled in about:config. So this issue would hurt a pretty minimal part of our technical users base (it is also expected that web devs have separate profiles for testing).
Fixing this could be pretty much hard at this stage, I for sure would like to evaluate alternative approaches to about:home in next versions, but nothing that could be done in the FX4 timeframe.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking, adding some flags so the sumo guys are aware (see comment 2) and would obviously accept a patch if one came up.

Comment 4

[al_9x]

Please post a workaround, it should be possible to run some code in the error console to fix this, after the fact.

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Resetting the browser.startup.homepage_override.buildID pref and restarting browser should fix this (after dom storage has been enabled clearly).

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks like the problem is well understood. I don't see a reason to keep qawanted for now. The workaround works fine.

Comment 7

[[e-mail]]

Same probleme very anoying pls post a fix soon

Comment 8

[Max Waterman]

My father is seeing this issue with FF5 (5.0.1) on MS Windows XP/SP3. I am pretty certain he hasn't fiddled with the about:config to turn off the dom storage at any time (though some plugin or some such might have done something like this, I suppose), and it is currently enabled.
I tried resetting the browser.startup.homepage_override.buildID pref and it has no effect.
Could someone please suggest a clean step-by-step workaround (that avoids having to use a new account)?
Thanks.

Comment 9

[[:Cww]]

Try the steps in the last post in this thread: https://support.mozilla.com/en-US/questions/847458

Comment 10

[Max Waterman]

(In reply to [:Cww] from comment #9)
> Try the steps in the last post in this thread:
> https://support.mozilla.com/en-US/questions/847458

That worked for me, thanks - though the instructions are missing the (perhaps obvious) final step of going back to 'about:home'.

I'm not sure how the above affects this bug, but I'll leave that for others to figure out.