Does this actually do anything?

Yes, this executes when all Flutter scrollables are at their boundary. For example:

1. User has a ListView scrolled to the bottom
2. User scrolls down again
3. ListView calls respond(allowPlatformDefault: true) since it's at boundary
4. No widget calls respond(allowPlatformDefault: false)
5. shouldScrollParent becomes true
6. scrollParentWindow() is called to scroll the parent page

This is the intended behavior, propagate scroll to parent only when Flutter can't handle it.

I understand that this line is executed under certain conditions. But I'm trying to figure out if it has any effect. As far as I can tell, it sends a custom flutter-scroll event, but what does that event do or who is handling it?

Good question! In the previous implementation, scrollParentWindow() used postMessage to send a flutter-scroll event, which required the host page to add a message listener.
I've updated the implementation in the latest commit to use direct parent.scrollBy() instead. This works automatically for same-origin iframes without any host page code needed.
For cross-origin iframes, the browser's security restrictions prevent direct parent access, so it silently fails. This is a browser limitation with no workaround. Cross-origin iframes cannot scroll their parent page without explicit host page cooperation.

Similar to my other comment, this code is based on the assumption that Flutter apps inside iframes are always full-page.

Take the following example:

+------------------ Parent window -------------------+
|                                                    |
|                                                    |
|                                                    |
|  +-------- iframe (non-flutter host app) --------+ |
|  |                                               | |
|  |                                               | |
|  |                                               | |
|  |          +--- Flutter embedded view ----+     | |
|  |          |                              |     | |
|  |          |                              |     | |
|  |          |                              |     | |
|  |          |                              |     | |
|  |          |                              |     | |
|  |          |                              |     | |
|  |          |                              |     | |
|  |          |                              |     | |
|  |          |                              |     | |
|  |          +------------------------------+     | |
|  +-----------------------------------------------+ |
+----------------------------------------------------+

If the user is scrolling the flutter view and there's no more content to scroll, what happens?

Expectation

The non-flutter host app in the iframe should scroll.

Actual

If I'm understanding the PR correctly, the parent window will be scrolled (if it has the same origin).

Great. I tested with https://flutter-demo-07-before.web.app/parent.html, it did prove you are right. I updated the logic ti check isFullPage. After the change: https://flutter-demo-07-after.web.app/parent.html.

Please let me know if I miss anything.

So when we are in an iframe now, we always prevent default.

What's the reason we aren't always preventing default outside iframes? And why does that reason not apply to apps running inside iframes?

Outside iframes, we conditionally skip preventDefault() when a scrollable is at its boundary (allowPlatformDefault: true). This lets the browser handle the scroll.

Inside iframes, this reason doesn't apply because:
1.The Flutter app fills the entire iframe. there's no "page" within the iframe for the browser to scroll.
2."Platform default" has a different effect: outside an iframe it means "scroll this page," but inside an iframe it means "chain the scroll to the parent page".
3.Scroll chaining is the bug: allowing platform default would cause both iframe and parent to scroll simultaneously (#156985)

So we always block native behavior in iframes, then explicitly handle parent scrolling via postMessage when all Flutter scrollables are at their boundary.

Ok, I now understand the thinking behind this, thanks for explaining!

Inside iframes, this reason doesn't apply because:
1.The Flutter app fills the entire iframe. there's no "page" within the iframe for the browser to scroll.

This assumption is not valid. It's possible for an iframe to contain a flutter app that doesn't fill the entire page.

Based on what you said, I wonder if we should change the isInIframe condition. Instead of checking for an iframe, let's check if the flutter app is filling the entire page. And if it's filling the entire page, then always prevent default. What do you think?

My assumption about Flutter filling the entire iframe was too strong.
However, I still think isInIframe is the correct condition.
The core problem is scroll chaining across the iframe boundary, not whether Flutter fills the page. In both cases, the browser's scroll chaining causes the same problem: when the user scrolls over the Flutter content, both the iframe content and parent page scroll together. The size of the Flutter app doesn't change this behavior.

Let me try to break it down so that I understand exactly what's changing and what issues are being fixed (and whether we are introducing any new issues).

What we used to do:

• Conditionally preventDefault()
• Can't unconditionally preventDefault() because some apps [1] don't work correctly if we unconditionally preventDefault().

What this PR is doing:

• Inside iframes: unconditionally preventDefault() (new behavior)
• Outside iframes: conditionally preventDefault() (existing behavior)

With the new behavior in this PR, my concern is that some apps [1] will have a broken scrolling experience if they are placed inside an iframe.

I'm thinking we could minimize this breakage by changing the condition to check for full-page apps instead of checking for inside vs outside iframes.

Thanks for the detailed breakdown.
The wheel event listener is attached to _viewTarget (Flutter's root element), not the document or iframe body.
So for the scenario you described (Flutter + HTML scrollable content side-by-side in an iframe), the HTML elements won't trigger Flutter's wheel handler because the listener is scoped to _viewTarget. Please check https://issue-156985-after.web.app/hybrid_demo.html. Both (left side and right side)scroll independently, proving that HTML elements alongside Flutter are not affected by the fix.
Let me know if you have a specific scenario in mind that this doesn't cover.

main demo showing the original issue fix: https://issue-156985-after.web.app/

There's no need to check the DOM for this. We already have this information. You can do something like:

Great. I updated the logic.

Great. Updated.

One last thought here to try to avoid the scrollParentWindow:

Instead of doing event.preventDefault() and then manually scrolling the parent, we should try something like this:

if (isInIframe && isFullPage) {
  final bool shouldScrollParent =
      _lastWheelEventAllowedDefault && !_lastWheelEventHandledByWidget;
  if (!shouldScrollParent) {
    event.preventDefault();
  }
} else {
  // ...
}

I'm not sure if it would work or not, but if it works let's do it!

Great. I updated the logic and deploy to https://issue-156985-after.web.app/. It works. The code is cleaner.