[oleksii-leonov]

Chromium's out-of-process PDF viewer (PdfOopif) can finish the main PDF document before swapping out its still-loading iframe, without sending frameStoppedLoading for that child. Removing the frame without signaling idle leaves the click waiting until the navigation timeout.

PdfOopif became the default on Windows/macOS/Linux in Chromium 145: https://chromium-review.googlesource.com/c/chromium/src/+/7239572

With unfixed Ferrum, Linux Chrome-for-Testing 145.0.7570.0 passes and 145.0.7571.0 times out. The first Linux stable 145 release, 145.0.7632.45, also times out. Each boundary case was checked three times.

This is feature-dependent, not limited to a browser version: enabling PdfOopif reproduces the same failure on Chrome 139 and 144; disabling it makes Chrome 145 pass. Feature controls preserve Ferrum's other defaults. The fix passes on Chrome 139 with PdfOopif enabled and both affected 145 builds above, three times each.

Recheck the existing idle predicate after removing a detached child. Keep main-frame detachment unchanged and continue waiting for loading frames or a main execution context that has been cleared.

Add an inline-PDF POST regression using the existing PDF fixture, plus deterministic CDP regressions for swap/removal and premature completion. The PDF and both child-detachment cases fail before the fix.

Validation on Chromium 155.0.8059.39: 683 examples, zero failures, four environment-dependent skips. Another 104 examples pass on Chrome 139. Full RuboCop and changed-line/branch coverage pass. RBS validation reports the same missing dependency types on unchanged upstream d7a9902; no method signatures or dependencies change here.

[route]

That was a bit too much of a unit tests which I don't like, so I went ahead, solved conflicts and removed them. Only feature tests especially for OOPIF are good!

[route]

@oleksii-leonov thanks for the investigation, the PDF case is real: on main the click raises TimeoutError after the swap detach.

I merged main into the branch, and replaced the unit specs with a feature spec: a click that adds two iframes and removes one must still wait for the other.

The new @event.set if idling? on Page.frameDetached opens a race though. Every click goes through wait_for_navigation!(0.1): it resets the event, dispatches the mouse event and waits 0.1s for a navigation to start. In that window all frames can still be idle, so any child detach releases the wait before the navigation the click triggers has even started:

<iframe src="/slow"></iframe>
<button onclick="document.querySelector('iframe').remove(); setTimeout(() => location.href = '/slow', 20)">Go</button>

page.go_to("/detach_then_navigate")
page.at_css("button").click
page.evaluate("location.pathname") # => "/detach_then_navigate" with this PR, "/slow" on main

Think of a click that closes a modal with an embedded video or drops a tracking iframe and then submits or redirects: the next finder runs against the old page.

Waking only when the detached frame was still loading (@frames.delete(id)&.idle? == false) fixes this repro and keeps the PDF fix, but it doesn't close the window, it just matches what Chrome's own frameStoppedLoading already does. The root issue is that the click treats any wake-up in that 0.1s as a finished navigation, I'd rather fix it there than in the detach handler.

I'll think about it and get back to you.