commit | 3105e285474d034c4ab701f716a64cc1b46f6358 | [log] [tgz] |
---|---|---|
author | Dominic Farolino <dom@chromium.org> | Fri Dec 09 21:35:37 2022 |
committer | Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Dec 09 21:35:37 2022 |
tree | 676dbfbe78175ef29a06ca0bfcdc4ca523b3c0b1 | |
parent | deafffb54a081e4cc93b506f2c4a820cbae4451f [diff] |
Reland "Fenced Frames: [1/N] Fledge `runAdAuction()` yields a FencedFrameConfig" This is a reland of commit dc890a7fe32e2f7eeb4bb96d56582b9780d56c8f. This CL fixes a compile error that was caused by an intervening CL that landed before this CL landed last time, which introduced another use of a symbol that this CL removed. Original change's description: > Fenced Frames: [1/N] Fledge `runAdAuction()` yields a FencedFrameConfig > > In order to make `runAdAuction()` return a promise to a > FencedFrameConfig object, we must make IPCs that land directly in Blink > consume a `blink.mojom.FencedFrameConfig`, which is mapped to > blink::FencedFrame::RedactedFencedFrameConfig. > > As-is, only the blink.mojom.FencedFrameConfig => > RedactedFencedFrameConfig shared type mapping exists; all of the members > rely on the auto-generated `Ptr` types, which try and use the Blink > variants for IPCs that land in Blink. The type mapping is defined for > the non-Blink variant types (i.e., usages of > `blink::mojom::PotentiallyOpaqueFooPtr`, instead of > `blink::mojom::blink::PotentiallyOpaqueFooPtr`) which does not work for > auto-generated types that try and map themselves inside of Blink. > > The two solutions for this are: > 1.) Typemap all sub-structs/unions/enums inside > blink.mojom.FencedFrameConfig all the way down > 2.) Don't use shared type maps for RedactedFencedFrameConfig, and > instead generate one type map for the default Chromium types and > one for the Blink types > > (1) Feels slightly simpler, and has other performance benefits that will > act as a good follow-up to comments in https://crrev.com/c/3862583. > > This involves type mapping many sub-types, which will be done over a > series of CLs. This CL does several things: > - Moves fenced_frame_config.mojom to "mojo_platform" from "mojo_core", > in preparation for making ad_auction_service.mojom depend on it [1] > - Moves the blink.mojom.{ReportingDestination, FencedFrameReporting} > types into fenced_frame_config.mojom from fenced_frame.mojom, and > makes the former stop importing the latter > - Typemaps the ReportingDestination enum to > blink::FencedFrame::ReportingDestination > - Typemap the FencedFrameReporting struct to the exported > blink::FencedFrame::FencedFrameReporting struct > - Modify various places to use the type mapped values > > The typemappings above are "shared", and use the default Chromium types. > Since we need to convert some of these types to Blink types before > exposure to the Web Platform, this CL: > > - Introduces blink::FencedFrameReporting, which is similar to > blink::FencedFrame::FencedFrameReporting but uses Blink types > - Make DocumentLoader::fenced_frame_reporting_ an > `absl::optional<blink::FencedFrameReporting>` instead of a > `blink::mojom::blink::FencedFrameReportingPtr` > - Removes WebFencedFrameReporting, and stores > blink::FencedFrame::FencedFrameReporting directly on > WebNavigationParams > - Converts from blink::FF::FFReporting <=> blink::FFReporting in > DocumentLoader & FrameLoader as per usual > > Before this CL, we had: > - blink::mojom::blink::FencedFrameReportingPtr > - blink::WebFencedFrameReporting > > After this CL, we have: > - blink::FencedFrame::FencedFrameReporting > - blink::FencedFrameReporting > > Subsequent CLs will add type mappings for the other sub-types in > preparation for making RedactedFencedFrameConfig able to be sent > directly to Blink. > > [1]: Note that *eventually* fenced_frame_config.mojom will need to > import frame_policy.mojom, which is in "mojo_core". That's going to > be the driving factor to move all of the auction & fenced frames > stuff back into core, but before the M110 branch date I want to > touch as few lines of code as possible, which is why I'm opting to > move fenced_frame_config.mojom to "platform" in the short-term. > > Bug: 1347953 > Change-Id: I9a78e21514013f3581ab3c6635e6e5b149451f4d > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4081454 > Reviewed-by: Daniel Cheng <dcheng@chromium.org> > Owners-Override: Daniel Cheng <dcheng@chromium.org> > Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> > Commit-Queue: Dominic Farolino <dom@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1081583} Bug: 1347953 Change-Id: I57588798ac32c255aba3e7878e6f2b9aa11658ab Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4090129 Reviewed-by: Garrett Tanzer <gtanzer@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Reviewed-by: Alexander Timin <altimin@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/main@{#1081653}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
To check out the source code locally, don't use git clone
! Instead, follow the instructions on how to get the code.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure .
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.
If you found a bug, please file it at https://crbug.com/new.