Prop changes do not always trigger $watch in IE11

[fenduru]

Version

2.5.16

Reproduction link

https://jsfiddle.net/50wL7mdz/242700/

Steps to reproduce

Open JSFiddle in IE11, and scroll the scrollbar up and down rapidly. Observe the console warns that occur when a prop update was missed

What is expected?

The $watch should be fired for every scroll event

What is actually happening?

Vue is handling subsequent scroll events before the watch is firing. In my use case we are integrating with another system, and it is important that we don't skip events.

---

This change is reproducible in versions >= 2.4.3 (you can change the version to 2.4.2 in the reproducer to see the correct behavior). Looking at the change log, it seems like this commit is a likely culprit.

[posva]

it's indeed skipping some callbacks. Not sure if this is easily fixable without breaking something else 🤔

[fenduru]

@posva I'm actually able to reproduce the skipped events even in Chrome if I turn on 6x slowdown CPU throttling. Practically though this is mainly a problem in IE11 because falling back to setTimeout introduces a minimum of 10ms delay. Also, in the case of scroll events, it is triggering many layouts/paints before the prop is updated in Vue resulting in a huge lag in my app. I do not think it is correct to defer application updates in a setTimeout.

With 2.4.2:

With 2.5.16

I'm happy to submit a PR once we have an idea of how we want to solve this.

I actually wonder if 844a540 is just paving over a more fundamental problem

[fenduru]

@posva @yyx990803 and thoughts on how we want to approach this? I'm eager to start working on a PR because this is severely impacting my application

[posva]

I'm sorry, it's not something I know how to help you with 😞

[fenduru]

@posva what needs to be done in order to move this forward?

[fenduru]

@yyx990803 what needs to be done here? I'm more than happy to contribute

[donnysim]

I had a similar case on chrome when loading images (dont remember about other browsers) month or so ago on vue 2.5. Images had a loader while they're being read from file, but the images would not be loaded as long as youre scrolling the page (so if you keep scrolling up and down without a stop, the loaders would never disappear). Sadly didnt have much time to dig deeper, but I thought that it's just one of thoses "it's javascript" situations. The image loading was initiated within setTimeout so I'm guessing it's part of the reason. Could try reproducing it again maybe.

[fenduru]

@sodatea I'm willing to work on this, however I need a small amount of guidance on what the core team wants to see here (at a high level). In my opinion 844a540 is incorrect and should be reverted, however I suspect that will not be well received.

[Justineo]

It’s likely to be reverted in 2.6 according to discussion under several related issues.

[fenduru]

@Justineo is there a specific issue tracking that discussion? Also could we label this with "nextTick related" label to make sure it is considered alongside the other nextTick issues?

[fenduru]

This is really hurting my app - we have a v-model that keeps track of scroll position and renders based on it. In IE, using setTimeout causes the scroll events to always "cut in line" before the setTimeout, resulting in the view never updating until you stop scrolling. Right now we are resorting to circumventing vue here for rendering and updating the scroll position, since it is just not shippable like this.

Are there any updates on the status of the 2.6 discussion regarding the $nextTick debacle? There seems to be some radio silence. Can this please labeled with nextTick related as well?

CC @Justineo @posva @yyx990803

[sirlancelot]

Does changing macroTimerFunc to use requestAnimationFrame() instead of setTimeout fix the issue? Does it open a different can of worms?

[fenduru]

Looks like #8450 will fix this