Closed Bug 607728 Opened 14 years ago Closed 14 years ago

about:home broken : javascript:localStorage["search-engine"]

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: By-Tor, Unassigned)

Details

(Whiteboard: [about-home])

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101027 Firefox/4.0b8pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101027 Firefox/4.0b8pre Clicking submit on about:home results in the following: Error: uncaught exception: [Exception... "Failure" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://browser/content/aboutHome.js :: setupSearchEngine :: line 100" data: no] Reproducible: Always Actual Results: Clicking Submit results in the error. Expected Results: Search should have been executed.
Debugged a bit with Mike over IRC, the exception comes from retrieving localStorage["search-engine"].
Status: UNCONFIRMED → NEW
Ever confirmed: true
this could have happened in the past due to bug 592990 or bug 598264, so I'm a bit surprised to see it now. Did it work before? Did you do anything particular before it stopped working?
do you have a chromeappsstore.sqlite in your profile folder?
notice in the last days there have been various fixes to dom storage, I'd not want this to be a regression from there.
Yes, I do have chromeappsstore.sqlite in my profile. Deleting it doesn't seem to have any effect. I can't think of anything I did that should have affected anything. I believe it happened sometime after today's (2010-10-27) nightly.
(In reply to comment #5) > Yes, I do have chromeappsstore.sqlite in my profile. Deleting it doesn't seem > to have any effect. You should have not deleted it, it's needed, I asked because not having it would have been a problem. updating to next nightly should recreate it though and also fix the search issue. Please check. > I can't think of anything I did that should have affected > anything. I believe it happened sometime after today's (2010-10-27) nightly. Did you delete something or cleared some kind of history/cookies/anything? Any action in the browser you did differently could help me figure out what happened.
(In reply to comment #6) > You should have not deleted it, it's needed, I asked because not having it > would have been a problem. updating to next nightly should recreate it though > and also fix the search issue. Please check. It was recreated by the same build it was deleted from. > Did you delete something or cleared some kind of history/cookies/anything? Any > action in the browser you did differently could help me figure out what > happened. Yes, I routinely clean my history using Ctrl-Shift-Del, and clearing Everything. I can't think of anything different though.
Ok, then I can suspect that some recent dom storage fix regressed clear recent history to kill chromeappsstorage. Will try to reproduce that, cc-ing Honza in the meanwhile.
Bug 527667 is related to CRH and was pushed and backed out various times, could be your cleared history while it was in the tree.
(In reply to comment #9) > Bug 527667 is related to CRH and was pushed and backed out various times, could > be your cleared history while it was in the tree. It's entirely possible that I made a build while it was in the tree.
Mike, please see [1] and check for bug 527667 check-ins. But as I can see the dates seems to be incorrect. The second attempt to land that bug was made yesterday (on 27th) and was quickly (within minutes) removed due to immediate oranges. It is a complicated patch and may cause that regression. I will try to reproduce. If you can provide more detailed STR would make it simpler to find the cause. However, the new code added at the bug, should be invoked only when deleting a time range, not 'everything' as you mention in comment 7. [1] http://hg.mozilla.org/mozilla-central/log/882525a98119/dom/src/storage/nsDOMStorage.cpp
(In reply to comment #11) > It is a complicated patch and may cause that regression. I will try to > reproduce. If you can provide more detailed STR would make it simpler to find > the cause. > > However, the new code added at the bug, should be invoked only when deleting a > time range, not 'everything' as you mention in comment 7. > > > [1] > http://hg.mozilla.org/mozilla-central/log/882525a98119/dom/src/storage/nsDOMStorage.cpp I may have pulled while that patch was in. The only STR at the time was to type text into the text area on about:home and click search. As of my builds today, the problem has resolved itself. I'm not entirely sure it was that patch as the problem seemed to last after the patch was removed, although bug 527667 would seem to be the most likely culprit. I'm not sure how to proceed from here as the bug has been resolved for the time being, but, the actual cause isn't clear. A bisection would be the only way to find out for sure, but, I'm not able to do that right now.
To clarify how it solved by itself: on each new build we store the data again, you most likely had a new buildID that caused us to store fresh data. This would instead be an issue for a release since there is some time between releases. Could you try clearing data as you usually do and check after each step if the search field is still working (you have to refresh about:home after each clear step before checking if the search field works).
After clearing the data and refreshing the about:home everything works as expected. I'm guessing that rather than the buildID itself, the gecko rev change from 20101027 to 20101028 might have gotten the new data.
Anybody still experiencing this bug? If not we should close it.
Whiteboard: [about-home]
We have other bugs (bug 615785) about the page not working for common users, this case was most likely caused by profile used on trunk and doesn't look like we can handle it apart from fixing the problem that could cause us to not populate the storage (that is exactly the scope of bug 615785).
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.