Route is not resolved on hash change in IE

[uNmAnNeR]

Hello!

I found that in IE supportsPushState is true, but onpopstate will never be called. So links does not work.

Example here: https://jsfiddle.net/1bj54j8v/

[pygy]

That's super odd... What IE versions are affected?

Edit: In theory, supportsPushState is false for IE9 and true otherwise, and IE10+versions support onpopstate...

http://caniuse.com/#feat=history

[pygy]

Could you try this? It is your fiddle, but as a top level page (no iframes added by jsfiddle).

https://bl.ocks.org/pygy/raw/a067feff54d58d36f17bc6851749afe3/#/home

[uNmAnNeR]

Could you try this? It is your fiddle, but as a top level page (no iframes added by jsfiddle).

Sure. Does not work on IE 11.953.14393.0.

In theory, supportsPushState is false for IE9 and true otherwise, and IE10+versions support onpopstate...

Found this issue for all IE before Edge: http://stackoverflow.com/a/41473506

By the way, mithril 0.2.x worked fine.

[pygy]

Thanks for the details. I suppose that v0.2 uses onhashchange in hash mode, even when browsers support pushState.

[dead-claudia]

@pygy It does.

[pygy]

I gave this a crack this morning with little success (many tests are broken by the change, and the mocks do not handle "debounced async" onhashchange, which doesn't help...)

[pygy]

Sorry, I didn't mean to close this, I didn't know that just mentioning an issue in a commit message closed issues (vs "fix #xxxx" ).

[dead-claudia]

@pygy That convenience feature is usually useful in GitHub, but yeah, sometimes, it does get annoying.

[pygy]

I'm afraid the fix for this will be breaking: pygy@bd7230f#diff-08af55052ff6ecc22309ea97e4711428R101

This is impossible to implement for IE9 (and it has never been), but if we want the router to work identically in every env in hash mode, we can't cheat with replaceState() when the routed tree is mounted.

This test would have passed in non-IE browsers...

There's also pygy@bd7230f#diff-08af55052ff6ecc22309ea97e4711428R799 that must be elucidated, it may be a pushStateMock bug or a router bug.

Edit: here's the problem child in full:

if (prefix[0] !== "#") {
	o("default route doesn't break back button", function(done) {
		// impossible to do with onhashchange, "new.com" should equal "old.com"
		init("")
		$window.location.href = "http://old.com"
		$window.location.href = "http://new.com"

		route(root, "/a", {
			"/a" : {
				view: function() {
					return m("div")
				}
			}
		})

		callAsync(function() {
			o(root.firstChild.nodeName).equals("DIV")

			o(route.get()).equals("/a")

			$window.history.back()

			o($window.location.pathname).equals("/")
			o($window.location.hostname).equals("old.com")

			done()
		})
	})
}

Before this, onhashchange-based routing wasn't tested at all :-/

[dead-claudia]

@pygy That's concerning... 😟

[pygy]

@isiahmeadows Worse, I recently realised that onhashchange wasn't debounced as I thought it was due to a JSBin bug(jsbin/jsbin#3078) (and not enough cross checking on my hand)...

[andraaspar]

I ran into this recently and had to create a workaround. Just in case it helps anyone.

[dead-claudia]

I'm punting this to post-v2, but I might be able to fix it in a future patch release. Specifically, we could detect IE and see what we can do to work around the popstate bug, but it's not exactly going to be easy to do.

If someone beats me to it, I'll gladly consider merging it. 🙂

[barneycarroll]

This ticket is 3 years old, and IE is no longer a support target. I'm closing this because with the passing of time, this no longer constitutes a bug.

[dead-claudia]

@barneycarroll This needs checked against IE11 - MS still supports it: https://docs.microsoft.com/en-US/lifecycle/faq/internet-explorer-microsoft-edge

I say we should put the lid on it August 17 of this year, aligning with Microsoft 365: https://techcommunity.microsoft.com/t5/microsoft-365-blog/microsoft-365-apps-say-farewell-to-internet-explorer-11-and/ba-p/1591666#ftag=MSF278e2c0

[barneycarroll]

Excellent. Given our resources I say we just drop support now. There is no sense leaving open the window of hope and opportunity for a browser that is going to be discontinued in half a year.

[dead-claudia]

Sure, let's do that. Just not this immediate next release. How does that sound?