-
-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.state
I 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: