637561 - about:home does not check for disabled indexedDB

Status: RESOLVED DUPLICATE of bug 1079355

(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

resulting in an js error:

Error: localStorage is null
Source file: chrome://browser/content/aboutHome.js
Line: 181

and breaking the page


Reproducible: Always

Comment 1

[Alex Lakatos[:AlexLakatos]]

Reporter, can you please provide some clear Steps to Reproduce?
Thanks.

Comment 2

[al_9x]

Disable dom storage (dom.storage.enabled=false) then load about:home

Comment 3

[Marco Bonardo [:mak]]

iirc was discussed that the case of users disabling dom storage was pretty small and uninteresting

Comment 4

[al_9x]

Related Bug 637639: if dom storage was disabled at the time of the profile upgrade, about:home remains broken even after it is re-enabled

Comment 5

[al_9x]

(In reply to comment #3)
> iirc was discussed that the case of users disabling dom storage was pretty
> small and uninteresting

Disabling dom storage is supported in Fx, so you can't just assume it's on and fail so ungracefully when it's off

Comment 6

[Marco Bonardo [:mak]]

if you disable a feature you should expect pages using that feature to break, we don't ship with dom storage disabled

Comment 7

[al_9x]

(In reply to comment #6)
> if you disable a feature you should expect pages using that feature to break,
> we don't ship with dom storage disabled

Most pages on the internet that use dom storage degrade gracefully, checking for null.  But this is not even an internet page, internal Fx code should especially be expected to behave sanely.  You are making lame excuses for bad coding.

Comment 8

[Marco Bonardo [:mak]]

Advanced users that touch about:config are aware of problems they can hit by changing unexposed configurations and more than able to workaround those problems. A clear warning is shown when you open about:config.

The implementation could change for a future version when there will be more time to handle the security implication of the other implementations, this was the best choice to handle security implications in the original evaluated time range for the project.
Even if we'd handle null case there is no good fallback road we could take, apart showing a blank page, so would be an absolutely useless check.

If you don't like the code you're welcome to submit good coded patches rather than flame-spamming bugs.

Comment 9

[al_9x]

(In reply to comment #8)
> Even if we'd handle null case there is no good fallback road we could take,
> apart showing a blank page, so would be an absolutely useless check.
>

Sure there is a fallback, just show a google search without any snippets.  The page can work work without dom storage.

Building core internal functionality (built-in home page) around a feature that can be disabled is unwise.  Failing to gracefully handle the disabled case is doubly so.

> If you don't like the code you're welcome to submit good coded patches rather
> than flame-spamming bugs.

flame-spamming?  I submitted this bug, and have a right to address your inane excuses.

Comment 10

[Marco Bonardo [:mak]]

(In reply to comment #9)
> Sure there is a fallback, just show a google search without any snippets.  The
> page can work work without dom storage.

That's an absolutely bad fallback, if dom storage is disabled we don't even know if google is the default search engine, so we'd be showing a random page? Plus the user didn't ask to visit google, and we should not try to be smart when that could hurt the user's privacy.

Comment 11

[al_9x]

(In reply to comment #10)
> (In reply to comment #9)
> > Sure there is a fallback, just show a google search without any snippets.  The
> > page can work work without dom storage.
> 
> That's an absolutely bad fallback

No, showing a broken page is what qualifies for an "absolutely bad fallback"  A Google search-box (which doesn't actually visit google, about:home is local) is an obvious improvement over a broken page.

Comment 12

[al_9x]

even hiding the search box is better than showing a broken one

Comment 13

[al_9x]

Why is this unconfirmed?

It's not looking like this will be addressed for 4.0, but there is no excuse for not doing proper error handling and at least hiding the broken parts.

Comment 14

[Ian Nartowicz]

Do we have a bug marking the general inability to see DOM storage from chrome when this preference is false?  Previously set storage items continue to exist whatever the value of the preference, but the API pretends they don't.  Then they magically reappear later when the preference is changed.

Comment 15

[Jesse Ruderman]

Did the patch in bug 789348 fix this?

Comment 16

[Marco Bonardo [:mak]]

well, it may probably now complain about disabled indexedDB.
So, the bug as filed is fixed, but the concept is still valid, we should still handle a null indexedDB object if dom.indexedDB.enabled is false.