Thanks for the report!  I can confirm on http://csreis.github.io/tests/cross-site-iframe.html when clicking "Go cross-site (complex page)" and hovering over links.  Repros on both 64.0.3282.85 and 66.0.3334.0 on Windows and Mac, only when Site Isolation is enabled.

Ken, do you know what code is involved with the status bubble, and how we could update it to support OOPIFs?

Possibly the IPC handling should to move from view to frame:

void RenderViewHostImpl::OnUpdateTargetURL(const GURL& url) {
  if (is_active_)
    delegate_->UpdateTargetURL(this, url);

A simple fix would be just to remove the "if (is_active_)" check from above. That might be prone to races, though, if you are moving the mouse between frames quickly, and both renderers try to send an update at about the same time.

It looks like it needs some plumbing changes. ChromeClientImpl::ShowMouseOverURL() triggers the RenderViewImpl to send a message, which doesn't work for an OOPIF process.

ChromeClientImpl::SetTooltip() is very similar, but has been modified to take a LocalFrame argument, and goes through RenderWidget to send an IPC.

We might need to do something similar to CursorManager to resolve races, which tracks which RenderWidgetHostView the mouse cursor is currently over, and only lets that one set the mouse cursor. Maybe we could use the same thing for status bubbles?

Removing |if (is_active_)| doesn't help, because the ViewHostMsg_UpdateTargetURL is filtered out by SwappedOutMessages::CanSendWhileSwappedOut (interestingly, it is not filtered out by Can*Handle*WhileSwappedOut, but it doesn't help us here).

Thank you for pointing out CursorManager.  One thing I want to point out is that the status bubble can be triggered both by 1) mouse hover or 2) focusing the anchor element (e.g. via keyboard, or even just calling anchor.focus() from javascript).  This leads to some interesting question, like - what should the status bubble show if a mouse hovers over one link, but another link is focused at the same time.

For now, I've wrote a browser test that fails with site-per-process, but succeeds otherwise.  WIP CL is here: https://crrev.com/c/898434

> what should the status bubble show if a mouse hovers over one link, but another link is focused at the same time

FWIW the behavior I see in both Chrome 64 and Firefox 58 is "last one wins". I.e.:

Hover over a.html link, then focus on b.html link. Status bubble changes from a.html to b.html.

Focus on a.html link, then hover over b.html link. Status bubble changes from a.html to b.html.

Thinking about this a little bit more, I think that

- the hovered/focused-link-bubble is a page-global thing, and not a widget-y or frame-y thing
    - it doesn't matter which widget the link hovering is happening in (unlike in many other IPCs handled by RenderWidgetHostImpl)
    - //content layer widgets don't handle the link-hovering at all - it just gets surfaced to the //chrome layer as a WebContentsDelegate callback

- RenderView *is* a renderer gateway to tell the browser about page-global things

So - I can fix this by just making another hole for ViewHostMsg_UpdateTargetURL::ID in SwappedOutMessages::CanSendWhileSwappedOut.  I checked that this fix works + talked to nasko@ and he is not opposed to this idea.


Races between different renderers will exist, but I think that last one wins is a good overall approach.  We'd still need to be careful about some scenarios (RV1: show link1, mouse moves over to RV2, RV2: show link2, RV1: hide my link) to make sure that RV can only hide its own link.

WIP CL @ https://chromium-review.googlesource.com/c/chromium/src/+/898434

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd707147cc193f8ea99c7258e2f2e71b857d3fb1

commit fd707147cc193f8ea99c7258e2f2e71b857d3fb1
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Wed Feb 07 19:46:13 2018

Focusing or hovering over a link in an OOPIF should show a status bubble

Bug:  807776 
Change-Id: I6219d7a8bc5a4b2fb608dfde1d0859739a35949f
Reviewed-on: https://chromium-review.googlesource.com/898434
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535104}
[modify] https://crrev.com/fd707147cc193f8ea99c7258e2f2e71b857d3fb1/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/fd707147cc193f8ea99c7258e2f2e71b857d3fb1/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/fd707147cc193f8ea99c7258e2f2e71b857d3fb1/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/fd707147cc193f8ea99c7258e2f2e71b857d3fb1/content/browser/web_contents/web_contents_impl_browsertest.cc
[modify] https://crrev.com/fd707147cc193f8ea99c7258e2f2e71b857d3fb1/content/common/swapped_out_messages.cc

Seems fixed in 66.0.3344.0.

The fix for this is not risky and is reported by users, so it will be good to merge in M65.

This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M65 branch 3325 based on comments #9 and #10. Please merge ASAP. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dae7de07ead9f9a4e9730185ce817858cdced48c

commit dae7de07ead9f9a4e9730185ce817858cdced48c
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Fri Feb 16 19:10:10 2018

Focusing or hovering over a link in an OOPIF should show a status bubble

TBR=lukasza@chromium.org

(cherry picked from commit fd707147cc193f8ea99c7258e2f2e71b857d3fb1)

Bug:  807776 
Change-Id: I6219d7a8bc5a4b2fb608dfde1d0859739a35949f
Reviewed-on: https://chromium-review.googlesource.com/898434
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#535104}
Reviewed-on: https://chromium-review.googlesource.com/924322
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#491}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/dae7de07ead9f9a4e9730185ce817858cdced48c/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/dae7de07ead9f9a4e9730185ce817858cdced48c/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/dae7de07ead9f9a4e9730185ce817858cdced48c/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/dae7de07ead9f9a4e9730185ce817858cdced48c/content/browser/web_contents/web_contents_impl_browsertest.cc
[modify] https://crrev.com/dae7de07ead9f9a4e9730185ce817858cdced48c/content/common/swapped_out_messages.cc