This definitely makes sense for the cursor update timer (an old code path).  It should just coalesce the cursor update work to the next frame.

The hover and active timers both intend to take more than a frame though.  The main use of the hover timer is when scrolling a page with the mouse under it.  IIRC we want to wait for 100ms of no scrolling.  That said, when the 100ms timer expires we should perhaps be triggering a frame-aligned update (instead of updating immediately).

Re: hover. As far as I can tell, the only parts of the codepath using this timer are fullscreen and detaching the layout object for a hovered node.

Re: active. Right, I should have clarified, but we'd need to still store some timestamp and compare when generating the next frame.

Code-wise, what does "driven by BeginFrame updates" amount to? I'm working on changes to fullscreen to synchronize state changes and events with animation frames, and it's possible I should use the same mechanism? (As it is, I've introduced a Document::enqueueAnimationFrameTask that's run after the animation frame-aligned events.)

It essentially comes down to integrating your code into a specific stage in the document lifecycle[1] (sadly that enum is missing a couple of stages like animation). Assuming Document::enqueueAnimationFrameTask is driven by PageAnimator, it sounds like a good way to achieve this.

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/DocumentLifecycle.h?rcl=1480306658&l=46

https://codereview.chromium.org/2536643002 depends on earlier unfinished CLs and doesn't have tests, but shows the general idea, it's part of ScriptedAnimationController, but I see that's triggered by PageAnimator::serviceScriptedAnimations so that might also work.

It's not defined by the specs, but I think it'd be good if the resize event is fired before the fullscreenchange events, since this is the actual order of things.

That seems like a good starting point. I think we want to be a bit selective about which tasks we allow in there since they're generally running on the critical path, but I think that's a definitely a big improvement over randomly firing timers.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This still needs to happen.

David, Chris, Lan
I guess this bug also refers to the same problem for hover states we were looking into.

I think this is identical, lets merge this into the newer bug