Alternatively in Step #4, use the "HTTP Same Origin" link to navigate the frame to a different page on the same origin, which reproduces the problem regardless of the state of siteisolation.

On navigation, PasswordInputType::OnDetachWithLayoutObject() fires and decrements the password count.

That, in turn, calls into SendSensitiveInputVisibility() and that schedules a task to run SendSensitiveInputVisibilityInternal(). Between the time of scheduling the task and the target method running, the Document::Shutdown() method runs and clears frame_, such that SendSensitiveInputVisibilityInternal exits at the check:

  if (!GetFrame())
    return;

...without calling mojo::MakeRequest.

---
In terms of fixing... I don't know if there's a way we could cache off the Service interface at the point of scheduling the task? Or perhaps VisiblePasswordObserver should use one of the Navigation events to call RenderFrameHasNoVisiblePasswordFields in the same way as it does when a renderframe crashes?

Hrm. Maybe we ought to consider this intentional?

SSLManager::DidCommitProvisionalLoad(const LoadCommittedDetails& details) {
  if (!details.is_main_frame) {
    // If it wasn't a main-frame navigation, then carry over content
    // status flags. (For example, the mixed content flag shouldn't
    // clear because of a frame navigation.)

We also tell the user that the page contains a non-secure form or image after it no longer does (https://www.bayden.com/test/mixedcontent/), and we do the same thing for top-level non-secure images that are dynamically-removed without a cross-page navigation.