New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 824157 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Expose Origins in addition to URLs in //content/public APIs

Project Member Reported by csharrison@chromium.org, Mar 21 2018

Issue description

The two main ones that would help are:
 - NavigationHandle::GetOrigin
 - WebContents::GetLastCommittedOrigin

See example CL which would use these APIs here [1]. In general, exposing Origins would encourage usage of url::Origin over GURL::GetOrigin, and improve performance to avoid unnecessary conversions (or memory bloat via storing the Origin when it is available elsewhere).

[1]: https://chromium-review.googlesource.com/c/chromium/src/+/970908 

 
Cc: clamy@chromium.org ericrobinson@chromium.org

Comment 2 by nasko@chromium.org, Mar 21 2018

Cc: creis@chromium.org alex...@chromium.org
I can understand the utility of WebContents::GetLastCommittedOrigin, but I'm not clear on NavigationHandle::GetOrigin. The latter can only be available at DidFinishNavigation time, at which point we already have the data as NavigationHandle::GetRenderFrameHost()::GetLastCommittedOrigin(), so exposing it directly through the handle is just syntactic shortcut.
My idea was to just expose it with the exact same semantics as GetURL. For instance, originally the tab-under code wanted to disallow navigations from *starting* if they are cross origin with the top level WebContents.

This required looking at the Origin of the URL, before commit time.
We already have RenderFrameHost::GetLastCommittedOrigin(), so if we expose GetLastCommittedOrigin() in other places, we might want to match semantics of the RFH call to avoid confusion.  Namely, RenderFrameHost::GetLastCommittedOrigin() is not the same as RenderFrameHost::GetLastCommittedURL().GetOrigin() -- they differ in about:blank cases (where the origin is inherited), sandboxed documents, unique origins, etc.

For WebContents, I don't know how much value there would be in WebContents::GetLastCommittedOrigin() over WebContents::GetMainFrame()->GetLastCommittedOrigin().  The latter is arguably better in the OOPIF world, because it makes it explicit that you want the main frame's origin and don't care about other frames, and we've been trying to remove some other APIs from WebContents that have implicitly assumed they apply to the main frame, leading to OOPIF bugs (e.g.,  issue 666525 ).
Yes, the whole reason I am making this bug is to get people to avoid using GetLastCommittedURL().GetOrigin() since it is usually not what you want (and doesn't enforce nice type properties since it returns a GURL).

My preference would be to implement WebContents::GetLastCommittedURL to just forward to the main rfh, though I do see your point about being explicit. The downside of having to access the RFH is just API clarity. Will people know the content API enough to know that that's the canonical way to get the current top-level origin?
Status: WontFix (was: Assigned)
I'm increasingly convinced that just reaching into the RFH is always the best move.

Sign in to add a comment