Incorrect window.history.state data in IE11 #489
Comments
|
Pretty sure this is due to different behaviours in the browsers. Looking into it. |
|
I don't think this has anything to do with Aurelia. |
|
@EisenbergEffect Not sure I agree. Aurelia's router is responsible for navigation within the app and the problem occurs since it doesn't take into consideration that IE/Edge behaves differently when using location.hash to "create navigation". I do however think I could create a PR that fixes this, if you want it. |
|
Please provide :)
…On Apr 12, 2017 9:17 AM, "Jürgen Wenzel" ***@***.***> wrote:
@EisenbergEffect <https://github.com/EisenbergEffect> Not sure I agree.
Aurelia's router is responsible for navigation within the app and the
problem occurs since it doesn't take into consideration that IE/Edge
behaves differently when using location.hash to "create navigation". I do
however think I could create a PR that fixes this, if you want it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#489 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIBnbM_g30nEdYul8SO_-uanG2yu1C0ks5rvPkKgaJpZM4M7R9Z>
.
|
|
I'd also argue this shouldn't be closed until a solution is implemented. If this were normal behaviour in IE11 outside of Aurelia I'd agree that it isn't an issue However, as covered by @jwx, the role of this package is to replicate the navigation behaviour one would usually encounter when using a non-SPA site. Part of that behaviour is Closing it because you think it's nothing to do with Aurelia is a little premature IMO. |
The router doesn't handle the different behaviour in IE/Edge for history state on new entries. This fix consolidates the behaviour with Chrome etc. Depending on PR aurelia/history-browser/history-state-consolidation. Closes aurelia#489.
|
@EisenbergEffect @TomFoyster It wasn't quite as straight forward as I had hoped, but there's now two PRs that will consolidate the behaviour of IE/Edge with that of Chrome and Firefox. |
|
@jwx Thanks! We'll check them out and try to get them into the next set of releases. |
|
@jwx I appreciate your fix. I'm trying to get a repro so I can confirm that your PR does in fact fix this. Using the @TomFoyster 's above. |
The router doesn't handle the different behaviour in IE/Edge for history state on new entries. This fix consolidates the behaviour with Chrome etc. Depending on PR aurelia/history-browser/history-state-consolidation. Closes aurelia#489.
|
R.I.P. IE ? |
I'm submitting a bug report
Library Version:
"aurelia-router": "npm:aurelia-router@^1.0.0",
Operating System:
|Windows 7
Node Version:
6.10.1
NPM Version:
3.10.10
JSPM OR Webpack AND Version
JSPM 0.16.53
Browser:
Internet Explorer 11
Language:
ESNext
Current behavior:
window.history.state.window.history.state.Expected/desired behavior:
As this page view should be a new entry in window.history I shouldn't see any data stored in
window.history.stateI have tested this outside Aurelia - with 2 simple HTML pages using
replaceState()and it performs as expected in IE11.An example App to replicate this can be found;
https://github.com/TomFoyster/AureliaHistoryStateTest
The text was updated successfully, but these errors were encountered: