...plus ScreenOrientation, as it's a dependency.
This is moved into ui/display for dependency reasons, so that ui/display
can ultimately generate this data structure.
This patch moves the files / rename types / fixes up includes but
otherwise is as minimal (grimacing emoji) of a change as possible.
ScreenInfo/ScreenInfos is a weird name when placed alongside
display::Screen and probably needs to be changed, but that is not a
change for this patch.
Also, this first step leaves things in a somewhat awkward state because
DisplayList and ScreenInfos are fairly similar purposed data structures
at the moment. I would like to disambiguate them in a followup.
The end goals here are:
* Have display::Screen always generate ScreenInfos so that it is
guaranteed that the current/primary displays exist in the list
(rather than at the RHWI level, where we assert/crash/fallback
when this is not true).
* Once display::Screen generates those ScreenInfos, pipe them to the
rest of the system as the source of truth rather than trying to
reconstruct them later (e.g. RenderWidgetHostImpl::GetScreenInfos).
* Separate the data structures we need into how they are used.
* DisplayList becomes the system view of the current set of displays
and a set of observers that are watching for changes. It does not
have any notion of a "current" display because it is independent
of widgets. It is not serializable over mojo. It can be converted
to ScreenInfos but not vice versa.
* ScreenInfos becomes the "widget relative" view of the displays
which includes a "current" display for that widget. It is the
serializable primitive, used at the widget and blink levels.
* Deprecate GetScreenInfo(); use GetScreenInfos().current instead.
The specific followup steps look like:
* Replace GetDisplayList.*WithFallbacks with GetScreenInfos versions.
* Remove "current" from display::DisplayList, along with its mojo code.
* Change RenderWidgetHostViewBase::GetDisplays() to GetScreenInfos().
* Add ScreenInfos to FrameVisualProperties.
* Remove most of RWHI::GetScreenInfos in favor of getting that info from
the RWHV, which for top level frames gets it from display::Screen
(or a remote process's display::Screen for Mac shims) and for
RWHVChildFrame gets it from the visual properties.
Bug: 1182855, 1208469
Change-Id: I96787c8a64f59bd7c62a1475bb3d3d1446ada071
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2948105
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@google.com>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Mike Wasserman <msw@chromium.org>
Commit-Queue: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893601}
Move the message into blink with a callback. Progressively we will move
the implementation into blink. But moving the message first allows us to
move some of the implementation in stages.
BUG=1097816
Change-Id: Ice0c372d4a6e83edffe2191b146a25144248a476
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2302771
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#790083}
- Move cc::BrowserControlParams into CC
- Move definition of VisualProperties into blink and use a typemap
- Add typemapping for LocalSurfaceIdAllocation for blink too.
- Add mojom_traits for ScreenInfo and VisualProperties.
BUG=1097816
Change-Id: I8e0742d74438ef489020aecbb03cb6b5bbb55763
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2299525
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#789972}
In order to move more RenderWidget code into blink's WidgetBase, move
the VisualProperties IPC struct to blink.
No behavioral changes are intended with this CL.
BUG=1097816
Change-Id: Ie06908cd13292d99775d4ccf9861071214a526ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2298228
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#788680}
The use of the ScreenOrientationLockType was wrong because the lock
type is different than the actual orientation. RenderWidget translated
this before passing it into blink. Using the correct definition on the
sent value from the browser. This allows us to avoid this special
mapping and will allow us to typemap directly to WebScreenInfo in the
future.
BUG=1097816
Change-Id: I914c389b82768080f122e98cb25ef630e08fad7d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2296259
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#788265}
This is a reland of 7a213fdac0
Deflaked the test by adding a missing RunLoop and having more robust
detection in the OutgoingVisualPropertiesIPCWatcher's, similar to the
pattern we see in VisualPropertiesPropagation_VisibleViewportSize.
Original change description:
> Add window segments concept to the content layer
>
> This change adds a the window segments concept to the
> SynchronizeVisualProperties cascade. A display feature splits a view by,
> e.g., a fold or a mask - an accessor is added to RenderWidgetHostViewBase
> to provide this information during the calculation of visual properties.
> When the root render widget is split by the display feature, there are
> multiple 'window segments' that web authors will be able to use to split
> their view and have a logical separation of content (either through
> JavaScript or CSS).
>
> The root widget window segments are computed by the root
> RenderWidgetHostImpl, based on the display feature on the
> RenderWidgetHostView. The segments are then propagated to child local
> frame roots via RenderFrameProxy and CrossProcessFrameConnector via the
> new member on VisualProperties.
>
> Follow-up changes will finish hooking this information up to Blink in
> order to expose it to the web, and also integrate with the platform
> specific APIs in order to get the display feature information from the
> underlying operating system.
>
> Explainers:
> https://github.com/webscreens/window-segments/blob/master/EXPLAINER.md
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Foldables/explainer.md
>
> i2p:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/_1_ljYsaqrU/qOoHJ7MhAgAJ
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/KsPRO3hkOGw/md4jgIAaAgAJ
>
> Bug: 1039050 1039051
> Change-Id: I6805cda5946bd5379ad6dcd68e092e5d7d9be42d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2205123
> Commit-Queue: Daniel Libby <dlibby@microsoft.com>
> Reviewed-by: danakj <danakj@chromium.org>
> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#773545}
TBR=kinuko@chromium.org
Change-Id: Ieb1d01d917fc75c84d01a37c455a7f12b836875f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2229668
Commit-Queue: Daniel Libby <dlibby@microsoft.com>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#775723}
This reverts commit 7a213fdac0.
Reason for revert: The test RenderWidgetHostViewChildFrameBrowserTest.VisualPropertiesPropagation_RootWindowSegments failed quite often on "Android CFI" and android-pie-x86-rel builders, and flaky on android-asan.
See http://shortn/_a3kmhb2wuI for more details of the flakiness
Original change's description:
> Add window segments concept to the content layer
>
> This change adds a the window segments concept to the
> SynchronizeVisualProperties cascade. A display feature splits a view by,
> e.g., a fold or a mask - an accessor is added to RenderWidgetHostViewBase
> to provide this information during the calculation of visual properties.
> When the root render widget is split by the display feature, there are
> multiple 'window segments' that web authors will be able to use to split
> their view and have a logical separation of content (either through
> JavaScript or CSS).
>
> The root widget window segments are computed by the root
> RenderWidgetHostImpl, based on the display feature on the
> RenderWidgetHostView. The segments are then propagated to child local
> frame roots via RenderFrameProxy and CrossProcessFrameConnector via the
> new member on VisualProperties.
>
> Follow-up changes will finish hooking this information up to Blink in
> order to expose it to the web, and also integrate with the platform
> specific APIs in order to get the display feature information from the
> underlying operating system.
>
> Explainers:
> https://github.com/webscreens/window-segments/blob/master/EXPLAINER.md
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Foldables/explainer.md
>
> i2p:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/_1_ljYsaqrU/qOoHJ7MhAgAJ
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/KsPRO3hkOGw/md4jgIAaAgAJ
>
> Bug: 1039050 1039051
> Change-Id: I6805cda5946bd5379ad6dcd68e092e5d7d9be42d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2205123
> Commit-Queue: Daniel Libby <dlibby@microsoft.com>
> Reviewed-by: danakj <danakj@chromium.org>
> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#773545}
TBR=danakj@chromium.org,kinuko@chromium.org,dlibby@microsoft.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 1039050 1039051
Change-Id: I74b881c8548cedfe1c694dbdee1ce617491bf75b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225141
Reviewed-by: Haiyang Pan <hypan@google.com>
Commit-Queue: Haiyang Pan <hypan@google.com>
Cr-Commit-Position: refs/heads/master@{#773727}
- introduce DeviceEmulator, make it navigation-associated
- move WebDeviceEmulationParams to blink/public/common/devtools
- use base::Optional<WebDeviceEmulationParams> to represent emulation
enabled/disabled state through most interfaces.
Change-Id: Ic743a1af02019610149e1c4a765696c9d8711e5b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2092938
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#751492}
Currently the visible_viewport_size is passed to each RenderView
separately from other properties which are passed down through the
RenderWidget/local root hierarchy. This moves the property into the
standard waterfall flow.
Prior logic to determine the value was spread out between various
implementations of RenderWidgetHostViews, with
RenderWidgetHostViewChildFrame doing some tricky (and incomplete for
portals) checking to see if it is the main frame of a nested frame
tree/WebContents. Now RenderWidgetHostImpl contains the logic to decide
which visible_viewport_size to use, using the RenderWidgetHostView for
main frames (nested and top level). For child widgets it always uses
the value received from the parent.
This change may cause child widgets to receive the value a bit slower
than before as it has to bounce through the RenderWidget hierarchy to
get to them, but it will allow them to all be synchronized for display
to the user. It will also cause child frames inside a nested WebContents
to get the value of their parent instead of their own
RenderWidgetHostView, which is more correct.
Based on a previous CL that was reverted:
https://chromium-review.googlesource.com/c/chromium/src/+/1863512R=avi@chromium.org, dcheng@chromium.org, wjmaclean@chromium.org
Change-Id: Ia5b99f48266ad758592f088e13a23002d90ba05b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2083916
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749137}
Right now, top and bottom browser controls can have a shown ratio
between 0 and 1. This CL adds the ability to set a minimum height for
either. Once set, the browser controls will not completely scroll off
the screen, but will stop scrolling once the controls' visible height
reaches a min height. A minimum shown ratio is calculated in
blink::BrowserControls or cc::BrowserControlsOffsetManager using the
min-height. This minimum shown ratio is then used to limit the shown
ratio of the browser controls when scrolling.
This particular CL adds the plumbing to get the minimum height from
Java to (blink and cc) browser controls. Apart from the height and min
heights, an "animate" bit is also sent from Java to native side. If
animate is true, cc::BCOM will animate the changes to the height and/or
min height of the browser controls. The actual animation logic will be
added in an upcoming CL.
Having a minimum height will give us an area to put a persistent
Android view above the omnibox that won't scroll off.
Bug: 989148
Change-Id: I123bcd2a089e20191d5416158eb8a4fe1449d6ef
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1918262
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Jinsuk Kim <jinsukkim@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sinan Sahin <sinansahin@google.com>
Cr-Commit-Position: refs/heads/master@{#722140}
This IPC was sent in order to tell WebViews without a local main frame
about the value. Since each RenderWidget has a value for this property, we
can set the value on the WebView from there, removing the need for the IPC.
Note that the RenderWidgetHostViewChildFrame does compute some different
value for the visible_viewport_size when auto-resize is enabled, instead of
using the value that the main frame RenderWidget uses. It's unclear why
this happens. It means after this CL child frames may see a different value
(the one their RenderWidgetHost sees) on their WebView, instead of the
value from the root RenderWidgetHost directly. This will give the child
frames a more consistent view however as the RenderWidget itself receives
the value its RenderWidgetHost computes.
Child frames in the same RenderView frame tree as the main frame has the
unfortunate situation of possibly conflicting with the main frame and
having a different value between the main frame and themselves, while
sharing the same WebView, and in this case they can not win. They do not
clobber the value that the main frame sets on the WebView though.
This CL clarifies a bunch of code and documents the RenderWidget waterfall
dance. The RenderWidget waterfall dance for visual properties propagates
visual properties set for the top level main frame RenderWidget down
the tree of local root RenderWidgets to reach every RenderWidget - and
as a result to each RenderViewImpl and WebView also.
The plumbing goes like:
1. Browser: parent RenderWidgetHost
2. IPC -> WidgetMsg_UpdateVisualProperties
3. Renderer A: parent RenderWidget
(sometimes blink involved)
4. Renderer A: child RenderFrameProxy
5. IPC -> FrameHostMsg_SynchronizeVisualProperties
6. Browser: child CrossProcessFrameConnector
7. Browser: parent RenderWidgetHost (We're here if |is_child_frame|.)
8. IPC -> WidgetMsg_UpdateVisualProperties
9. Renderer B: child RenderWidget
10. (sometimes RenderViewImpl/WebViewImpl)
We remove PageMsg_UpdatePageVisualProperties which was bypassing the
waterfall to each RenderViewImpl directly, which jumps past the
compositor synchronization done with UpdateVisualProperties in the
waterfall dance.
See also https://docs.google.com/document/d/1G_fR1D_0c1yke8CqDMddoKrDGr3gy5t_ImEH4hKNIII/editR=avi@chromium.org, dcheng@chromium.org
Bug: 419087
Change-Id: I298538a71e6428b2182baf6742c21c104a3a5d75
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1863512
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#707164}
The WebDisplayMode enum is redundant in C++ now that we have
blink::mojom::DisplayMode.
The following header is no longer needed:
third_party/blink/public/common/manifest/web_display_mode.h
// TODO(dgozman): instead of this enum, use blink.mojom.DisplayMode directly.
WebDisplayMode.java is added to chrome/android/java/..., replacing the
WebDisplayMode.java file that was previously generated from the above header.
(The mojom-generated Java class DisplayMode is not a direct replacement for
the Java annotation type @WebDisplayMode.)
The DisplayMode enum constants now following the naming guide:
kUndefined kBrowser kMinimalUi kStandalone kFullscreen
https://google.github.io/styleguide/cppguide.html#Constant_NamesTBR=jochen@chromium.orgTBR=reillyg@chromium.orgTBR=yusufo@chromium.org
Bug: 1009909
Change-Id: Ida01048bd5001e9217601d35a2ef3770d4d7bf54
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1834804
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Alexey Baskakov <loyso@chromium.org>
Cr-Commit-Position: refs/heads/master@{#702724}
Some visual properties are for the page, and some are for the widget. Right now,
all are propagated by WidgetMsg_SynchronizeVisualProperties. This is incorrect
since it's possible for a renderer to have a page but not a widget.
This CL begins the process of fixing this incorrect routing. It adds a new IPC
message ViewMsg_UpdateLocalMainFrameVisualProperties, which allows us to begin
routing visual property messages through the Page object.
This CL should not have any behavior changes.
Bug: 998273
Change-Id: I4f4b46f8bd51e2d64b652db6aa1df6e6c3b076a0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1788201
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Auto-Submit: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694936}
