Open Cara-Jo opened 9 years ago
+1
:+1:
What is the suggestion here? To include a thin web server w/ deck.js? To not use replaceState
? Document this as a warning?
I will confess up front to not having looked at how you use replaceState()
, therefore not knowing offhand the implications of removing it, but it seems like Chrome has now made it a dead letter, and not using it is the right thing to do. Unless this kind of API retreat becomes a massive trend and JavaScript from file://
URLs becomes practically impossible, I think the thin web server option is too complex. It's an extra moving part that will be a pain in the butt across platforms, having its own dependencies, etc.
If the alternatives to replaceState()
end up ballooning history in weird ways or being unacceptable for other reasons, that's cool, but absent compelling considerations there I think nuking it is the right thing to do.
Workaround: Open deck.js, go to line ~340 and change window.history.replaceStats({}, "", hashPath); to try{window.history.replaceStats({}, "", hashPath);}catch(err){if (!err.message.startsWith("Failed to execute 'replaceState' on 'History'")){throw new Error(err.message);}}
Note that it is a nasty fix. Better would be to handle only this specific error (but current chrome won't work with "instanceof SecurityError") and in case of any other error just throw it through...
+1
@tlberglund @sarperlman Can this be closed?
Well, we don't have write access to this repo, so we can't close it ourselves, but good catch all the same! This was fixed in Chrome at some point in the past few months.
Chrome updated and fixed a 'security' hole that no longer allows local sites (in the case of a slide deck) to use the 'replicateState'.
The Chrome error lists the following files as the issue:
All files are being hosted locally on my machine since these slides are sometimes used in places that do not have internet.
They work in IE, Safari, and Firefox as well as in Chrome only after running a local webserver.