Firefox 52 ESR click handlers do not work

[karlblackburn]

Version

2.6.2

Reproduction link

https://jsfiddle.net/pzumygcq//

Steps to reproduce

• Download and install Firefox 52 ESR. Unsure if it is broken on other old versions of Firefox.
• Click on show button (this is important, click handlers work if they are bound when currentFlushTimestamp is 0).
• This will show a second button, this button will increment the count variable every time it is clicked, except Firefox52 ESR

What is expected?

count variable will increment

What is actually happening?

Click handler is not firing. I've done some digging into the vue.js code and it seems due to this part of the code being incorrect, or at least the timestamp Firefox has for the event is incorrect:

handler = original._wrapper = function (e) { if (e.timeStamp >= attachedTimestamp) { return original.apply(this, arguments) } };

On this version of Firefox, e.timeStamp is less than attachedTimestamp

---

Our application is built on vue.js but we have a lot of users who use Firefox 52 ESR for it's compatibility with Silverlight and upgrading is not an option right now.

Some further things I found when digging:
document.createEvent('Event').timeStamp returns 1549471218936000 which means that vue will think that the event time is based on Date.now() rather than performance.now().

[DimPaDev]

I have encountered the same problem in my nw.js application (chromium 72). In my case the problem occurs only when a particular vue instance is injected to a document element of a different window of the application. Otherwise it works just fine. This problem persists in these versions : 2.6.0, 2.6.1, 2.6.2.
The last version without this problem was the 2.5.22.
So it doesn't seem to be related to just a specific version of FF, but with the upgrade to vuejs 2.6.x. If this is a different issue though, I could open a different issue.

[yyx990803]

@DimPaDev they have the same root cause from what I know. Events in different pages in a multi-page nw.js app would have different timestamp starting points since they are relative to page load. But I would file that as a separate issue.

[yyx990803]

For the cause of this issue - FF 52 ESR is providing very weird event.timeStamp values... seems to be a problem in FF itself, trying to see if we can have a workaround... otherwise we may have to just whitelist it.

[joaomlemos]

Hey!

I'm facing a similiar issue with timestamp in a CEF build for Windows - I have found this ticket on CEF that reports the same issue https://bitbucket.org/chromiumembedded/cef/issues/2749/osr-results-in-weird-eventtimestamp-values

Any idea on a possible workaround ?

I have something like this:

<div @click="something()">
   <span class="__title">Something</span>
</div>

clicking in Something does not fire the click handler.

Looking at

if (
        // no bubbling, should always fire.
        // this is just a safety net in case event.timeStamp is unreliable in
        // certain weird environments...
        e.target === e.currentTarget ||
        // event is fired after handler attachment
        e.timeStamp >= attachedTimestamp ||
        // #9462 bail for iOS 9 bug: event.timeStamp is 0 after history.pushState
        e.timeStamp === 0 ||
        // #9448 bail if event is fired in another document in a multi-page
        // electron/nw.js app, since event.timeStamp will be using a different
        // starting reference
        e.target.ownerDocument !== document
      ) {
        return original.apply(this, arguments)
      }

fails in all the conditions. Given the issue with the timestamp, e.timeStamp >= attachedTimestamp will also fail.

I'm wondering if we can add an extra condition to validate if the e.target is a child element of e.currentTarget ?