WebPageProxy::createNewPage() runs in the UIProcess when web content asks to open a new window (e.g. window.open() or a target=_blank navigation that the client accepts). On iOS, a picker UI (such as a <select> option picker, date picker, or other content-view presented UI) can be open and visually anchored over the current page’s chrome at the moment a new page is requested. Before this patch, createNewPage() proceeded to configure and swap in the new page (setOpenedByDOM(), origin/app-initiated state, etc.) without first dismissing any picker that the outgoing/current content view still owns. The invariant being violated is that transient, page-anchored UI must be torn down before another page can take over the view, so that no picker outlives the page context that spawned it. Because the picker was left presented across the page transition, an attacker could arrange for the picker (or the spacing/layout it forces) to remain on screen while the address bar and page content were replaced, producing a mismatch between the URL shown and the content/UI actually displayed — i.e. address bar spoofing.

The fix adds a call, right before newPage->setOpenedByDOM(), to obtain the current PageClient and invoke dismissAnyOpenPicker(), which on iOS forwards to the content view’s dismissPickersIfNeededWithReason: using PickerDismissalReason::ViewRemoved. A new virtual PageClient::dismissAnyOpenPicker() is introduced with an empty default (no-op on non-iOS ports), and PageClientImpl (iOS) overrides it to actually dismiss pickers. This restores the invariant that opening a new page first dismisses page-anchored picker UI, closing the window during which stale UI could be composited over a page whose URL had changed.

This is a UI-integrity (spoofing) issue confined to the iOS UIProcess presentation layer, not a memory-safety bug; there is no corruption primitive, no attacker-controlled read/write, and no path to code execution shown by the diff. The realistic impact is deceiving the user about the origin of displayed content, which strengthens phishing and social-engineering attacks but does not by itself compromise the process. Severity is medium precisely because it undermines a security-relevant UI guarantee (the address bar) without granting execution or data-theft primitives on its own.