In IE11 windows 8 call to window.localStorage was throwing out an access denied error. Using try and catch manages the issue and allows the script to execute in IE 11 in desktop mode.
I think it is a problem with IE11 rather than the way Silverstripe is implementing the preview via an iframe from what I have been reading. http://blogs.msdn.com/b/ieinternals/archive/2009/09/16/bugs-in-ie8-support-for-html5-postmessage-sessionstorage-and-localstorage.aspx. It seems that the way IE11 deals with localStorage is broken in certain cases but I am not 100% certain of the cause yet as I have not been able to find a definitive answer. I only noticed it was a problem when a new client said they couldn't view the admin screen properly in IE11. I took a look in IE11 and I was experiencing the same problem which makes the admin interface layout screw up and the preview doesn't work due the error mentioned in the first post.
Instead of the original code I submitted I have amended it and added an additional function to test more robustly to see if localStorage is available and can be accessed properly. It is a copy of the code on a blog post Mathias Bynens has written about detecting if localStorage is available and can be used: https://mathiasbynens.be/notes/localstorage-pattern
I have added a console.warn as you suggested if localStorage is not available so that at least you get a warning if localStorage tests fail.
I have tested this on Windows 8.1: Firefox, Chrome & Mac: Firefox, Safari, Chrome and it seems to work as expected. On IE11 it displays the admin area correctly now but obviously doesn't save the preview settings between page loads if localStorage is not available.
It's important to test different databases. It's important to test
different versions of PHP. But we don't need to test all possible
versions of each tested in a cartesian product.
This patch ensures that there are 4 builds that cover:
- PHP 5.4, 5.5, 5.6
- MySQL, PostgreSQL and SQLite
- PDO and each db-specific connector
- Behat and non
Our build time is an impediment: frequently we're slowed down waiting for
test runs to complete. In this context, running allowed-failure builds
that everyone ignores is just a waste.
I'd love to see HHVM work, but that's going to require that someone
actually gets the build to pass. At that point, we can add it back into
the build matrix.
I'm working on a PHP7 branch that will hopefully also fix our nightly
builds. Once I get that going, I'll add those two back, but not have
'allow failures'
Even if we decide, at some point in the future, that supporting nightly
doesn't make sense, I see the *only* value of Travis is maintaining our
green tick. We either care about builds or we don't: I've never seen a
'grey area' build result in anything other than embarrassment and
technical debt.
Let's decide what matters to us and treat it like it matters to us:
it's part of the build or not.
API CHANGE: Debug::showError(), Debug::showLines(), Debug::log(), and Debug::header() removed
NEW: Logging provided
ZendLog has been removed and monolog introduced instead as a dependency.
The “ErrorLogger” injection point is now the used as the logger that
errors are fed into, and implements PSR-3’s Psr\Log\LoggerInterface.
The SS_ERROR_LOG setting expect a Monolog Logger to be provided as the
ErrorLogger.
DebugView writes straight to STDOUT. It would be much more flexible if
it returns a string instead.
It’s possible that DebugView should be scuttled in favour of a 3rd party
library, but in the meantime, this change makes it more useful for the
logging changes.
