Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

fix($browser): don’t use history api when only the hash changes #9406

Closed
wants to merge 1 commit into from

Conversation

tbosch
Copy link
Contributor

@tbosch tbosch commented Oct 3, 2014

IE10/11 have the following problem: When changing the url hash
via history.pushState() and then reverting the hash via direct
changes to location.href (or via a link) does not fire a
hashchange nor popstate event.

This commit changes the default behavior as follows:
Uses location.href/location.replace if the new url differs from
the previous url only in the hash fragment or the browser
does not support history API.
Use history.pushState/ history.replaceState otherwise.

Fixes #9143

IE10/11 have the following problem: When changing the url hash
via `history.pushState()` and then reverting the hash via direct
changes to `location.href` (or via a link) does not fire a 
`hashchange` nor `popstate` event.

This commit changes the default behavior as follows:
Uses `location.href`/`location.replace` if the new url differs from
the previous url only in the hash fragment or the browser
does not support history API.
Use `history.pushState`/ `history.replaceState` otherwise.

Fixes angular#9143
@tbosch
Copy link
Contributor Author

tbosch commented Oct 3, 2014

@IgorMinar Could you review this?

@tbosch
Copy link
Contributor Author

tbosch commented Oct 3, 2014

You can use the last plunker in the example and SauceLabs to verify the bug and also that my commit fixes it (by including a locally built angular version).

@tbosch
Copy link
Contributor Author

tbosch commented Oct 3, 2014

Fixes #8869 as well.

@mmccordhp
Copy link

This also fixes the case where you modify by hand the hash in the browser's url field.

@@ -445,6 +445,17 @@ describe('browser', function() {
expect(locationReplace).not.toHaveBeenCalled();
});

it('should set location.href when the url only changed in the hash fragment', function() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather:
should set location.href and not use pushState when ... to please IE10/11

@tbosch tbosch closed this Oct 3, 2014
@tbosch tbosch deleted the fix/msielocation branch October 3, 2014 23:05
tbosch added a commit that referenced this pull request Oct 3, 2014
IE10/11 have the following problem: When changing the url hash
via `history.pushState()` and then reverting the hash via direct
changes to `location.href` (or via a link) does not fire a
`hashchange` nor `popstate` event.

This commit changes the default behavior as follows:
Uses `location.href`/`location.replace` if the new url differs from
the previous url only in the hash fragment or the browser
does not support history API.
Use `history.pushState`/ `history.replaceState` otherwise.

Fixes #9143
Closes #9406
tbosch added a commit to tbosch/angular.js that referenced this pull request Oct 7, 2014
IE10/11 have the following problem: When changing the url hash
via `history.pushState()` and then reverting the hash via direct
changes to `location.href` (or via a link) does not fire a
`hashchange` nor `popstate` event.

This commit changes the default behavior as follows:
Uses `location.href`/`location.replace` if the new url differs from
the previous url only in the hash fragment or the browser
does not support history API.
Use `history.pushState`/ `history.replaceState` otherwise.

Fixes angular#9143
Closes angular#9406
tbosch added a commit that referenced this pull request Oct 7, 2014
IE10/11 have the following problem: When changing the url hash
via `history.pushState()` and then reverting the hash via direct
changes to `location.href` (or via a link) does not fire a
`hashchange` nor `popstate` event.

This commit changes the default behavior as follows:
Uses `location.href`/`location.replace` if the new url differs from
the previous url only in the hash fragment or the browser
does not support history API.
Use `history.pushState`/ `history.replaceState` otherwise.

Fixes #9143
Closes #9406
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Issues in IE10/IE11 when using favorites/bookmarks twice or entering an url manually
3 participants