Handling same document drag navigations

[Alison Gale]

Hey all,

I've been working on the Split View feature (#side-by-side) and a followup to allow dragging a single link into a WebContents to navigate (#open-dragged-links-same-tab). I'm looking into a crash (crbug.com/457493437) that occurs when performing a same-document fragment navigation due to no origin window being provided in the FrameLoadRequest (link).

Daniel suggested reaching out to this group to ask whether this navigation should be considered as initiated by the page? Or should it be considered a user-initiated navigation? 

Alison

--

Alison Gale Senior Software Engineer Google Chrome

[Daniel Cheng]

In an ideal world, I think these types of navigations should be treated as browser-initiated, i.e. as if the user had typed in the omnibox to navigate a page. While it's triggered by the "default action" of dropping a link, it's not really the page itself doing the navigation.

However, that plumbing doesn't exist today, and it is a bit scary–because browser-initiated navigations don't have the restrictions that renderer-initiated navigations might. I did have a CL to implement this from several years ago: https://chromium-review.googlesource.com/c/chromium/src/+/2738971 And it highlights some of the security risks/subtle plumbing issues that would still need to be dealt with today.

While it wouldn't apply cleanly to ToT, the high-level plumbing remains relevant and it's probably the route I'd recommend if there aren't other objections.

Daniel

[Alison Gale]

+Alex Tsu  for context

[Daniel Cheng]

Hi Alison,

We chatted about this in the CSA sync today. People were generally fine with making drop navigations browser-initiated, but this is going to require some work to implement properly, because we don't want to just pass the URL back from the renderer to the browser. The CL I linked in my previous reply is roughly what I think the Mojo plumbing would need to look like.

The other part of this is preserving our security restrictions. For example, we do not allow non-WebUI pages to navigate to WebUI pages. So for drop navigations, we need to be careful that a web page can't put a URL to "chrome://settings/passwords" in the drag data, and cause us to navigate to WebUI from a non-WebUI page.

Currently, this is handled ad-hoc in several places, and our final safety fallback is the fact that the navigation is (more-or-less) renderer-initiated today; if the renderer tries to initiate a navigation to a URL it shouldn't be able to access, we'll block it then. We need to make sure we don't lose this element of safety when we change things to be browser-initiated, because browser-initiated navigations have far fewer restrictions. As a "bonus", drag and drop can synthesize URLs from text in the drag data–so we need to make sure that dragging and dropping chrome://settings/passwords from a non-WebUI page is also blocked.

A lot of complexity from my previous attempts came from this "bonus" feature; since then, we actually tag the drag data with the initiating origin. Now that we have that, we should have a more robust and safe path towards blocking these types of disallowed navigations reliably.

Daniel

[Alison Gale]

Thanks for sharing the updates from the CSA sync! That seems like a reasonable solution to move forward with. You bring up good points about needing to block things like internal Chrome URLs and it would probably be good to centralize this logic to the extent possible. Fortunately the Split View functionality that hit this edge case is hidden by a flag that is separate from the regular Split View launch so we can hold off on rolling out SupportOpeningDraggedLinksInSameTab until b/457493437 is resolved. Would this be something that the security/navigation team could own? My team likely wouldn't have resources to tackle this in the immediate future and it would likely require close collaboration to ensure we get up to speed on all the background and edge cases that would need to be handled here.

Alison

[Daniel Cheng]

Hi Alison,

Would this be something that the security/navigation team could own?

I am happy to mentor/guide and/or help review CLs, but the security and navigation teams don't currently have the bandwidth to take this on. The mojo plumbing in the CL I linked previously is still a good baseline for how things should work; the main adjustments would be how/where to enforce the security boundaries, and with the drag initiator's origin being passed around now, it should be a lot simpler–you should really only need to implement filtering in the OS drag entered event.

Unfortunately, no one at Google owns drag and drop anymore. The reason the above CL never landed is because drag-and-drop has lots of edge cases and lots of platform-specific code–and it's hard to test with automation. Since the CL didn't really serve a product purpose back then other than code health, I didn't pursue it further at the time 🙃.

Daniel

[Alison Gale]

I see. I'll discuss with my team but I don't think we have Eng bandwidth to implement this now so we are discussing whether we could just have same-origin fragment navigations (or possibly all same-origin navigations) open in a new tab since it appears to happen less frequently. We would have this work in the backlog if we do have time in the future. The alternative we are considering is to not ramp up this change and just leave the existing behavior of dragging opening a link in a new tab. I'll let you know what we decide.

Alison