when using history mode in IE9 and fallback:false, page will flash before refresh

[hxlniada]

Version

2.7.0

Reproduction link

the problematic code is at src/history/base.js line 64

transitionTo (location: RawLocation, onComplete?: Function, onAbort?: Function) {
   const route = this.router.match(location, this.current)
   this.confirmTransition(route, () => {
     this.updateRoute(route) // problem here
     onComplete && onComplete(route)
     this.ensureURL()

     // fire ready cbs once
     if (!this.ready) {
       this.ready = true
       this.readyCbs.forEach(cb => { cb(route) })
     }
   }, err => {
     if (onAbort) {
       onAbort(err)
     }
     if (err && !this.ready) {
       this.ready = true
       this.readyErrorCbs.forEach(cb => { cb(err) })
     }
   })
 }

when in ie9 history mode and set fallback:false, after page inited, all of the router change should work like a regular a page jump(just like location.href or location.replace (code is at ./src/util/push-state.js line 53))

window.location[replace ? 'replace' : 'assign'](url)

thats say, this.updateRoute(route) shouldn't be invoked when invoke history.push(except the time before page inited)

because this.updateRoute(route) will render the target component, and highlight the target router-link.

for example when I am at the home link('/'), then

1. I click the nav tab help link('/help');
2. then the code invoke this.updateRoute(route);
3. the help nav is highlighted and the help page shown.;
4. after a while, the code run into ./src/util/push-state.js and invoke the window.location method, the page will jump to the target link. after server response, page refreshed.

the step 3 should not happen in this story, we should just jump, otherwise the page will flash: show the targe page, highlight the target link, then after server response, do those task again. isn't it terrible?

Steps to reproduce

ie9, history mode, fallback: false

What is expected?

page won't show as if is't just a page jump(like location.href or location.replace)

What is actually happening?

page show before server response, lead to a page flash(like location.reload()), looks really terrible

---

[posva]

That's how it's intended to work. Use hash mode if you don't want to change pages at every request

[hxlniada]

@posva oh no... my big brother, I want to use server render. and I can't use hash mode because I use hash to link to anchors.

why closing this so quickly

[hxlniada]

@posva when with history and fallback false in ie9, it suppose to run as regular page jump(otherwise it works really strange), can you reopen this issue? I will push a pr to fix this bug when I have time. thanks

[hxlniada]

If it works like single page app in ie9 with fallback:false and history mode, why this fallback:false even exist?

[LinusBorg]

As posva said, this is expected behaviour. The docs say:

Setting [fallback] to false essentially makes every router-link navigation a full page refresh in IE9.

History mode can't work in IE9, so you can choose between hashmode or complete page reloads as a fallback.

There's no way to fix this.

[hxlniada]

@LinusBorg @posva oh no no no, sorry for my poor english. let me describe this problem again.
When working in ie9 with history mode and fallback:false option.
Logically it works corret currently
But it works strange: click on a link, the page render immediatelly, and then it refresh, just like i invoke location.reload() programlly.works like a page flash.

[LinusBorg]

Okay, then for that we need a demo / reproduction. Or you just send a PR. But I haven't seen this behaviour yet.

[hxlniada]

@LinusBorg would you reopen this issue? It's hard to reproduction a history api fallback. Maybe someone is facing the same problem.

[LinusBorg]

I would like to re-open this, but so far, I only have you saying "it's flashing, and that's wrong".

Without a reproduction / demo, I can't verify that it's a bug, nor bebug it.

If you are sure you can come up with a PR, just send one :)

I will re-open this, but if there's nothing coming in the next couple of days, it will be closed again because I still can't say if this really is a bug.

[hxlniada]

@LinusBorg all right, thank you

I have updated my issue description. If you still don't what I say. I will try to solve this problem.

But I don't know how to know the page inited state(after the router firset rendered (maybe this.ready?)

[hxlniada]

@posva @LinusBorg have updated my issue description, is it clear now?

I have send my pr, please check it. thanks.