Weird Promise in UIWebView in iOS >= 9.3.3

[Pada-V]

Version

v2.2.4

Detail

Like the source code comments described, Promise became weird in UIWebView in iOS >= 9.3.3.When you have a input or textarea element and use v-model or input event to create a two-way binding, then scroll the page at the same time as typing,the page events do not respond except native events.Under these circumstances,

if (isIOS) { setTimeout(noop); }

can't solve the problem,but

setTimeout(function() {
        p.then(nextTickHandler).catch(logError);
}, 0);

doing well.I think setTimeout recovers more easily than Promise does.So setTimeout can avoid hanging up by JavaScriptCore after scrolling,the event queue will not be blocked.

Other relevant

The timeupdate event of audio and video also have a similar situation.
WKWebView performs well in this situation.

This is my opinion.(In my case, I used vue-cli, standard mode.)Is this correct?Or is there any other way to solve the problem?

BTW,can anyone tell me why there are two lines of the same relace in 'vue.esm.js'(line 150-151)?

[vue-bot]

Hello, your issue has been closed because it does not conform to our issue requirements. Please use the Issue Helper to create an issue - thank you!

[LinusBorg]

I'll re-open this even though it's not meeting the issue standards since I assume this is meant as a discussion start to see how to solve this?

the goal of the issue is not quite clear to me.

[Pada-V]

First of all,thank you for your reopening.

I think it would be a good thing if this could solve the problem or better solution to avoid the problem except for not using these directives could be discussed.If this problem could be solved in the next release is better.

I solved this problem by using 'setInterval' when I was updating an audio time. And '.lazy' can avoid this problem when using 'v-model'.But if we need to know the data updates in real time,we need to use 'setTimeout' and 'input' event,this is too cumbersome and not elegant.

[yyx990803]

The description is not very clear - are you saying after the scroll+type together the queue stops working altogether (i.e. nothing updates anymore)?

We use Promise whenever it is available, because the microtask queue gets flushed earlier than the timer queue. Ideally, we want to fallback to setTimeout in UIWebView in iOS >9.3, but the tricky part is there is no reliable way to detect that environment at all. The empty setTimeout hack seems to work in most cases, I've never run into the case you described before, so please try to provide a reproduction with steps if your answer to the question above is yes.

[Pada-V]

My answer is yes, so I prepared a demo and did a few tests again, but this time everything seems to be all right. I realized it was my misunderstanding.Unlike before this time I removed the other library and used vue only, so I think it might be other libraries that indirectly cause this problem. My team leader found that if we removed babel-polyfill from our project can solve the problem.

One of the conditions for babel-polyfill to decides whether to use native Promise or not is isNode || typeof PromiseRejectionEvent == 'function'. In mobile phone (some of my testers that I've tested), PromiseRejectionEvent is undefined, so Promise was rewritten. ( vuex requires a Promise polyfill in some browser )

It was my carelessness, I didn't keep looking for the reason. vue is great. I'm sorry to have taken up your valuable time. Thank you for your reply. ^_^

[yyx990803]

Cool, good to know! Maybe you can file an issue for Babel regarding the polyfill behavior.