Expose Origins in addition to URLs in //content/public APIs |
|||
Issue descriptionThe 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
,
Mar 21 2018
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.
,
Mar 21 2018
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.
,
Mar 21 2018
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 ).
,
Mar 21 2018
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?
,
Jun 8 2018
I'm increasingly convinced that just reaching into the RFH is always the best move. |
|||
►
Sign in to add a comment |
|||
Comment 1 by csharrison@chromium.org
, Mar 21 2018