Ferrum 0.18.0 (also on main), Chrome 138 via browserless, default flatten: true.
When an iframe target is created, Contexts#subscribe_target_created looks for its parent page:
target = @contexts[context_id]&.find_target { |t| t.connected? && t.page.frame_by(id: info["targetId"]) }find_target yields every connected target, including dedicated workers. t.page builds a Page for the worker target, which sends Page.enable and raises Ferrum::BrowserError: 'Page.enable' wasn't found. The exception is raised on the subscriber's event thread, which ends. After that, no further CDP events are dispatched for the rest of the process, so the next navigation or command that waits for an event hangs until it times out.
We hit it with a page that runs web workers (an OHIF DICOM viewer) and then opens an iframe. A workaround that restricts the lookup to page/iframe targets fixes it for us:
module FindTargetSkipsWorkers
def find_target
super { |target| (target.page? || target.type == "iframe") && yield(target) }
end
end
Ferrum::Context.prepend(FindTargetSkipsWorkers)Separately: the related case where connect_worker raises TimeoutError for a worker that never answers is already rescued on main. A release with that fix would let us drop our workaround for it.
Ferrum 0.18.0 (also on
main), Chrome 138 via browserless, defaultflatten: true.When an
iframetarget is created,Contexts#subscribe_target_createdlooks for its parent page:find_targetyields every connected target, including dedicated workers.t.pagebuilds aPagefor the worker target, which sendsPage.enableand raisesFerrum::BrowserError: 'Page.enable' wasn't found. The exception is raised on the subscriber's event thread, which ends. After that, no further CDP events are dispatched for the rest of the process, so the next navigation or command that waits for an event hangs until it times out.We hit it with a page that runs web workers (an OHIF DICOM viewer) and then opens an iframe. A workaround that restricts the lookup to page/iframe targets fixes it for us:
Separately: the related case where
connect_workerraisesTimeoutErrorfor a worker that never answers is already rescued onmain. A release with that fix would let us drop our workaround for it.