preventDefault be preventing performance entries + potential bug

[Jase Williams]

We noticed some interactions were not being recorded (despite the event handler running and using main-thread time). 

When debugging the issue it seems the event handlers were using preventDefault() when there's a value it doesn't want to deal with.

Below is a test case where you can try some letters (which generate performance entries), but if you try numbers nothing will come through (you can check the console).
https://codepen.io/jasonwilliams1/pen/qByqJRy

(My guess is there's less work happening when a number is pressed and its below the threshold? I can also get it to happen if I put a long while loop inside the number check)

As a follow up, we noticed sometimes interactions don't show until the next paint happens, even if this paint is many seconds after (this I cannot reproduce right now sadly).

So for example, still using the test case above, if you type a number (doesn't trigger a paint because numbers don't show in the input), wait 4 seconds then type a letter the interaction comes through as 4 seconds long. This is misleading because it's not related to the time the handler is taking.
Has anyone else reported behavior anything like this before?

Thanks
Jason

[Barry Pollard]

Hi Jason,

As discussed offline, this looks to be due to the 16ms minimum (even if you try to set this to 0), for security reasons, so very small events beneath that threshold will not be reported.

Thanks,

Barry

[Jase Williams]

Thanks Barry

That certainly does explain the first issue, where the preventDefault could mean less work is happening on those key presses so they fall below the threshold. I think this can also be confirmed by setting a long while loop inside those blocks and the entries do eventually show.

I’m still struggling to understand the second issue, it seems like Chromium is just taking the last interaction timestamp with the next paint time stamp and using that as an interaction time.

For instance I can type into a textbox a number (which won’t paint anything) wait 10 seconds, then type a letter which paints and I have a 10 second interaction.

This is misleading because the main thread wasn’t “held” for 10 seconds, in fact it was idle, but the algorithm seems to naively calculate it like that because there was no paint in between.

This looks like a bug but I’m unable to create a test case.

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/36d60c18-07b3-4fa5-b38c-366c9de1760bn%40googlegroups.com.