Skip to content
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

Regular links not working in IE11 #1911

Open
samhammer opened this issue Nov 28, 2017 · 11 comments
Open

Regular links not working in IE11 #1911

samhammer opened this issue Nov 28, 2017 · 11 comments
Labels
ie
Projects

Comments

@samhammer
Copy link

@samhammer samhammer commented Nov 28, 2017

Version

3.0.1 (tested with vuejs 2.5.9)

Reproduction link

https://jsfiddle.net/6b7k58wh/

Steps to reproduce

  • Use Internet Explorer 11 (Tested with version 11.1176.10586.0 update version 1.0.47)
  • Navigate with a router link to a page that contains a regular link ("<a href..." )
  • Click on the regular link

What is expected?

That i am navigated to the correct page. This is working correctly in chrome and firefox.

What is actually happening?

The URL is changing but the page content stays the same. (see video on Youtube)


This was working up to vue-router 2.7.0 (with vuejs 2.4.2).

I tested with chrome and ie11:
https://www.youtube.com/watch?v=2E8uKJbrCSM

@posva

This comment has been minimized.

Copy link
Member

@posva posva commented Nov 28, 2017

You have to use router-link to navigate within the app

@posva posva closed this Nov 28, 2017
@samhammer

This comment has been minimized.

Copy link
Author

@samhammer samhammer commented Nov 28, 2017

From the documentation i know that the preferred way would be using router-link instead of regular links: https://router.vuejs.org/en/api/router-link.html

But regular links were working up to vue-router 2.7.0. Was there a breaking change recently?

We have a special case where our links are created dynamically by setting the html to a div with the v-html attribute. I made a quick test and router-links are not working there. Do you have an idea how to workaround that?

Thanks in advance!

@posva posva reopened this Nov 28, 2017
@posva

This comment has been minimized.

Copy link
Member

@posva posva commented Nov 28, 2017

The PR that added this behaviour is at #1662.
I'm not sure if this is something we want to fix but it bothers me that it was working before and it isn't now...

@posva posva added the ie label Nov 28, 2017
@vuejs vuejs deleted a comment from samhammer Nov 28, 2017
@vuejs vuejs deleted a comment from samhammer Nov 28, 2017
@jblotus

This comment has been minimized.

Copy link

@jblotus jblotus commented Nov 28, 2017

Having similar issues in IE11 and had to rollback to 2.7.0

@jblotus

This comment has been minimized.

Copy link

@jblotus jblotus commented Nov 28, 2017

In our case we have a menu fragment on the page that is not in Vue and just uses regular anchor tags which will trigger navigation change. Would be great to keep this especially for legacy applications where Vue apps are embedded partially in a page.

This works in chrome and firefox of course.

@jblotus

This comment has been minimized.

Copy link

@jblotus jblotus commented Nov 28, 2017

maybe dupe of #1849

@chrisbethelepb

This comment has been minimized.

Copy link

@chrisbethelepb chrisbethelepb commented Mar 28, 2018

Here's a workaround that worked for me:

  • Add this to your Vue app that implements the router:
      methods: {
        hashChangeHandler: function() {
          var target = window.location.hash;
          this.$router.push(target.substring(1, target.length));
        }
      },
      mounted: function() {
        // fix for IE 11
        if (!!window.MSInputMethodContext && !!document.documentMode) {
          window.addEventListener('hashchange', this.hashChangeHandler);
        }
      },
      destroyed: function() {
        // fix for IE 11
        if (!!window.MSInputMethodContext && !!document.documentMode) {
          window.removeEventListener('hashchange', this.hashChangeHandler);
        }
      }

!!window.MSInputMethodContext && !!document.documentMode is just a quick truthy check that only evaluates to true for IE 11.

Working demo: https://jsfiddle.net/5r5pmLqw/

amcsi added a commit to amcsi/jogging that referenced this issue Apr 19, 2018
@magentaFire

This comment has been minimized.

Copy link

@magentaFire magentaFire commented Jun 28, 2018

I solved it with babel: installing presets (stage-0, stage-1, stage-2, stage-3, env and es2015)
Here is how to install presets:
babel preset env
and adding them to my .babelrc:
{ "presets": ["env", "stage-0" "stage-1", "stage-2", "stage-3" , "es2015"] }

@a-le

This comment has been minimized.

Copy link

@a-le a-le commented Oct 30, 2018

Same problem here with Vue.js v2.5.16 and vue-router v3.0.1
@chrisbethelepb workarounds works for me.

Here is another implementation:

// router and IE 11 workaround. see: https://github.com/vuejs/vue-router/issues/1911
const IE11RouterFix = {
    methods: {
        hashChangeHandler: function() { this.$router.push(window.location.hash.substring(1, window.location.hash.length)); },
        isIE11: function() { return !!window.MSInputMethodContext && !!document.documentMode; }
    },
    mounted: function() { if ( this.isIE11() ) { window.addEventListener('hashchange', this.hashChangeHandler); } },
    destroyed: function() { if ( this.isIE11() ) { window.removeEventListener('hashchange', this.hashChangeHandler); } }
};

new Vue({
    /* your stuff */
    mixins: [IE11RouterFix],
});
@posva posva added this to Ignore for now (low prio, high complex) in Longterm Mar 26, 2019
@jmaicher

This comment has been minimized.

Copy link

@jmaicher jmaicher commented Apr 24, 2019

I think this is a bug that is worth fixing, especially because hash mode is the current default mode. I'm more than happy to help with a fix.

The root cause of the problem was introduced with this commit 1422eb5. As far as I understand, this was done to enable scroll position saving in hash mode. I'm not sure why this feature relies on popstate. Is there a technical reason, or is this by accident?

This change in combination with the faulty popstate event support in IE and Edge [1] broke the navigation via regular links (or manual URL changes) in said browsers. There is an open PR #1988 to fix this problem in IE11, but this ignores other affected version of IE.

The best fix, IMHO, is to revert history mode to the hashchange event and to not rely on the popstate event anymore. Then, we would need to find another way to support scroll position saving in hash mode. Otherwise we would break a feature that is already released.

Another option is to add affected browser versions to the supportsPushState exceptions https://github.com/vuejs/vue-router/blob/dev/src/util/push-state.js#L6. This would also break scroll position saving in hash mode, but only for affected browsers.

A third option is to incorporate a fix to work around the popstate event issues in IE and Edge. There are multiple proposals here and in a related issue #1849.

[1] https://developer.mozilla.org/de/docs/Web/Events/popstate#Browser_compatibility

@posva

This comment has been minimized.

Copy link
Member

@posva posva commented Apr 24, 2019

Yes, the problem was 1422eb5. That's why I couldn't merge #1988, it would have broken that feature that has been around for a long time. I didn't realize this issue could be a duplicate of #1849

There are other workarounds I thought about like listening to both events in IE 10/11 and Edge and filter out duplicates but it creates spaghetti code that I'm not happy with...

You can try working on a solution if you want

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Longterm
Ignore for now (low prio, high complex)
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.