7

I realized today that I could not edit tag filters from the sidebar on the home page. Clicking the 'edit' link beside the "Favorite Tags" header simply did nothing. Experimenting with disabling various browser addons did not help. I traced the problem to a line in the Firefox console "TypeError: localStorage is null (full.en.js:139)". Temporarily enabling "localStorage" in Firefox fixed the problem. However, I'm sure this is a bug, because whether localStorage is enabled or not, the tag filter works perfectly (indicating that the tags are not stored in localStorage), and as I later found I can edit the tags fine from the other UI for them on the user preferences page.

Improve this question
16
  • I can't reproduce this using FireFox 26 or 27 with localStorage disabled. What OS are you using? Any other steps to reproduce?
    – Oded
    Feb 4, 2014 at 17:29
  • Thanks for replying. I'm using the current Firefox ESR (24.3) on Windows. The setting in about:config is dom.storage.enabled. With this set to false, window.localStorage is definitely null. I'm not sure if it should be but it is.
    – Boann
    Feb 5, 2014 at 11:50
  • I understand - however, I am not getting the same error as you with the newer versions. To confirm - with the ESR version, when local storage is disabled, you get the JS error in the console?
    – Oded
    Feb 5, 2014 at 11:55
  • Yes, "TypeError: localStorage is null" @ full.en.js:139. All addons are disabled. I set up a minimal HTML file with "<script>document.write(window.localStorage);</script>", which outputs "[object Storage]" or "null" depending on the dom.storage.enabled setting. Perhaps Firefox 25/26+ behaves differently there.
    – Boann
    Feb 5, 2014 at 12:05
  • There's a portable one, if that helps.
    – Boann
    Feb 5, 2014 at 12:18
  • I am still unable to reproduce - using 24.3, local storage disabled. Not seeing any error messages.
    – Oded
    Feb 5, 2014 at 13:32
  • I've just realized I'm able to reproduce the problem in one copy of Firefox and not in another (even though both are the same version, on the same computer, and are configured mostly the same). I'm sorry. I'll experiment and get back to you.
    – Boann
    Feb 5, 2014 at 13:39
  • Oded, I have found another condition necessary to cause the problem: I have an overridden user agent string. My native user agent is "Mozilla/5.0 (Windows NT 5.2; rv:24.0) Gecko/20100101 Firefox/24.0" but I have overridden it to "Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0" (only difference is the NT version -- Win 2003 vs Win 7). Originally I was using the UAControl addon to do this but I'm getting the same behavior after ditching the addon and simply setting general.useragent.override. Any other override string is fine though.
    – Boann
    Feb 5, 2014 at 15:05
  • E.g., using the fake NT 6.1 string but with one extra space added between two tokens, the problem goes away. Only that exact overridden string causes the problem. Obviously I don't expect a SO fix for something this obscure, but have you any idea what's causing it, as it's freaking me out? Fearing some weird, highly targeted virus I went to another (should be clean) computer, downloaded a clean copy of Firefox from the above link, disabled DOM storage and set that exact user agent string and bang! the tag editing bug returns! On both machines I have only Win2003 though. :[
    – Boann
    Feb 5, 2014 at 15:05
  • I can't think of anything - we do feature detection here, not user agent detection.
    – Oded
    Feb 5, 2014 at 15:15
  • I have found the difference: with the Win 7 user agent, the head section of the page source includes "<script>StackExchange.using("gps", function () { StackExchange.gps.track("homepage.visit", {}, true); });</script>", which is the code that's getting upset by the disabled DOM storage, causing the JavaScript error that is stopping JavaScript execution, thus causing the tag editing to break. If I send any other user agent then that GPS/track thingie is not included in the response. Could this different page header be coming from some StackExchange cache server with a stale entry?
    – Boann
    Feb 5, 2014 at 15:34
  • Hah. That does explain things - we are doing some a/b testing there and amongst others use the user agent to put people into buckets. Looks like you are hitting a different bucket with each user agent. Strangely we to test !window.localStorage, but looks like either FF 24.3 doesn't work correctly with it when disabled, or we need to add a test for disabled localStorage (not sure if that's possible).
    – Oded
    Feb 5, 2014 at 15:40
  • I'm now almost certain the offending statement is this one: var b=localStorage[c]; which is on line 139 (I don't know what it looks like unminified though). That particular function doesn't have any check that localStorage is defined.
    – Boann
    Feb 5, 2014 at 15:58
  • 1
    I have the same problem with Firefox 35.0 on ubuntu 14.04. On some few pages I don't have problems (stackoverflow), but on most stackexchange and meta pages I can't post new questions because of this problem.
    – Daniel Alder
    Jan 31, 2015 at 13:36
  • I uploaded a series of screenshots: imgur.com/HXxu2pD imgur.com/xeW9ICt imgur.com/APKhdQX imgur.com/G4rHDh0 imgur.com/cuifHS6 all together: imgur.com/a/0iLTp/embed#0
    – Daniel Alder
    Jan 31, 2015 at 16:01

1 Answer 1

Reset to default
2

Fixed in next build (build rev 2015.2.13.3072 on meta, 2015.2.13.2295 on sites).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .