Bug 67583 – Make overflowchanged event asynchronous

• Component: UI Events
• Status: RESOLVED WONTFIX

[Dimitri Glazkov (Google)]

It looks like this is a non-standard event that is the only thing that's keeping us from ditching a fairly massive chunk of FrameAction/FrameActionSchedule machinery. And it's the only thing left that can still go bump in the middle of the night. What I mean by this is it's the only event handler that could still fire while querying properties that cause forced style recalc + layout.

Perhaps we could just remove it altogether?

Anders, you added it back in http://trac.webkit.org/changeset/15191. Do you remember why we need it?

[Dimitri Glazkov (Google)]

Created attachment 106362 [details]
Patch

[Anders Carlsson]

It was added to support a feature in Mail.app. I'll e-mail someone and check if it's still used.

[Anders Carlsson]

It is still used, but it can definitely be made asynchronous!

[Dimitri Glazkov (Google)]

(In reply to comment #3)
> It is still used, but it can definitely be made asynchronous!

Yay!! I thereby humbly request your review, kind sir.

This seems like a very risky change. Making scroll events asynchronous has irreparably broken apps and websites, even though it had already been asynchronous in other engines, so people assumed that content was not depending on the synchronous nature. overflowchange, however, originated in WebKit, where it had always fired synchronously, so all apps and web content using it expect it to be synchronous.

[Anders Carlsson]

(In reply to comment #5)
> This seems like a very risky change. Making scroll events asynchronous has irreparably broken apps and websites, even though it had already been asynchronous in other engines, so people assumed that content was not depending on the synchronous nature. overflowchange, however, originated in WebKit, where it had always fired synchronously, so all apps and web content using it expect it to be synchronous.

There is only one known client that uses this event, and I've verified that this patch doesn't break the client.

[Dimitri Glazkov (Google)]

Eric's reminder of r+'d patches led me back to this patch. Darin, Anders, Dan -- are we doing this or not? Let me know. I'll rebase/commit or just wontfix the bug.

[Ahmad Saleem]

It seems that this r+ patch didn't landed in Webkit (checked with Bug ID in Webkit GitHub).

Is it still applicable? Thanks!

[Darin Adler]

I don’t know, but think instead we should investigate removing the overflowchanged event.

[Darin Adler]

I believe the only client using this was macOS Mail, and if I am not mistaken it’s no longer used in the new version coming in macOS Ventura. And the TOT WebKit does not need to be compatible with older versions of macOS Mail.

[Darin Adler]

Another alternative that would be helpful but less tidy would be to make sure it’s exposed only in Mail, and not web-exposed.

[Alexey Proskuryakov]

AFAIK this code path is still runtime switchable. Not sure how long we need to support it (probably needs to be discussed elsewhere).

[Darin Adler]

If it’s runtime switchable, and off for web browsers by default, then I agree that internal Apple discussion can help us pinpoint when we can remove it entirely and this bug can be closed as "never to be fixed".

[Ahmad Saleem]

Safari 18.2 shipped with overflowchanged event removed successfully. Marking this as `RESOLVED WONTFIX`.