Serendipity Forums

With 2.0 I have a strange experience with a specific Firefox instance/profile where buttons with class="additional_info" are not working in the backend, for example in New Entry the "Entry metadata" and "Advanced Options" buttons for the div class="additional_info" where clicking doesn't even change the arrow icon. Or in Configuration all buttons associated with a fieldset class="additional_info", where clicking changes the arrow icon but nothing else happens. The "Toggle expand all" button however works and and expands all sections.

It works in other browser profiles, so I suspected some extension like Adblock or Disconnect, but starting the browser in safe-mode still had the same effect. I created another browser profile and installed all the same extensions, but also that one works.

Inspecting with Firebug revealed that on the working buttons the additional_info class is removed to show the section or fieldset, but is not removed for the non-working case so they stay hidden.

There must be some setting in the non-working Firefox instance that causes this, but I have no idea what.

Any suggestions?

Have you tried purging the cache of your browser? Maybe the javasript file that does the toggling does not properly work?

Also, you seem to be resourceful, have you tried using Firebug to instpect network traffic and see if there are errors loading the javascript? Or checked the javscript console for error messages?

AHA! Clicking on such button throws a "TypeError: localStorage is null" exception, for example in index.php line 757 where localStorage.setItem() is called.That is due to the config's dom.storage.enabled being set to false, setting that to true it works.

Apparently s9y lacks a check whether local storage is available or not and either choose a different storage method or at least warn the user.

erAck wrote:That is due to the config's dom.storage.enabled being set to false, setting that to true it works.

Apparently s9y lacks a check whether local storage is available or not and either choose a different storage method or at least warn the user.

As far as I know, that is a setting which has to be explicitly disabled in Firefox using about:config. That is something not every average user will even be able to do. Meaning most FF users will have localStorage available.

Usually, localStorage is only used in the backend JS to store the state of a collapsible element, so it should still be usable if localStorage is not available. We'll need to check if there are instances where this is not true.

YL

True, local storage has to be explicitly disabled, but this already happens if you disallow cookies in Firefox. Which I have, along with the Cookie Monster extension to allow cookies from whitelisted sites. Also, it may be that extensions like Better Privacy disable local storage automatically.

I just committed a fix for this, should work even if localStorage is disabled in 2.0.1. (Although you'll obviously not have the ability to “store” the collapsed/expanded state for collapsible elements in the backend. That's not possible w/o using localStorage or cookies.)

YL

Hey, thanks a lot

The next least permanent storage possibility would be the sessionStorage btw, but I realize that may not be worth the effort.

sessionStorage is pointless unless you use it to stora data that only needs to “live” for that particular session. That would definitely be an overhead for the things we currently use localStorage for.

YL