GetNavigationEntryScreenshotCache() asserts the frame tree is primary.
However during WebContents destruction, the frame tree is reset before
the animator, so the navigation controller (owned by the FrameTree) back
pointer is a UAF.
This CL adds a shortcut to destroy the animator as the "first" thing
during the WebContents's destruction. Then the animator can still
perform the clean up tasks while the navigation controller is still
valid.
Bug: 373898450
Change-Id: I0d793d536ca99700cf7f8c324f562131f2a480c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5948024
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372744}
In particular, switch to using GetWorkletType() instead of GetParam()
in preparation for adding a second parameter.
Also rename GetParamInverse() to GetOtherWorkletType() and
GetPendingRequestsOfParamType() to GetPendingRequestsOfWorkletType().
Merge GetActiveProcesses() and GetActiveProcessesOfParamType() to a
single GetActiveProcessesOfWorkletType() method that takes an optional
worklet type.
Bug: 374253381
Change-Id: I3e9eeaf5dfa523542217f5bd148dbde548bac072
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5953094
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: mmenke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372725}
Remove unused Layer attachment/detachment APIs from the Shell management
system. This includes:
- Removing forward declaration of cc::Layer
- Removing ShellAttachLayer() and ShellRemoveLayer() functions
These APIs are no longer needed as layer management is now handled
elsewhere in the system.
Bug: None
Change-Id: I7e161d7dbb70100b6e40c254b710d4f5adfbaf09
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952671
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Abhijeet Kandalkar <abhijeet@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1372722}
handling on Viz.
This CL does the following:
* Hooks up creation of appropriate RenderInputRouterSupport* class to mirror
RenderWidgetHostViewInput interface implementation in Viz for a FrameSinkId.
This information is stored in FrameSinkMetadata structure.
* Adds traversal methods, namely Get(Parent|Root)RenderInputRouterSupport to
InputManager, allowing getting parent/root RenderInputRouterSupportBase* class
from a child frame. Added tests for the traversals.
* Refactors RenderWidgetHostViewInput interface and implements some additional
methods for the same interface in RenderInputRouterSupportBase.
Doc Link:
https://docs.google.com/document/d/1tRPUd11fuPcXxb2ep_kGYPahgv0OOlV7DvsGkbom7VA/
Bug: b:367695776, b:373888054
Change-Id: Ia61f1848abc0598f7f385a6b4d1202109ca3fa71
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5941108
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: Aman Verma <amanvr@google.com>
Cr-Commit-Position: refs/heads/main@{#1372706}
A couple of them were still using TEST_F, which works in parameterized
tests as long as you don't call GetParam(), but we'll soon be calling
GetParam() in all tests, whe we add a second parameter to control the
base AuctionProcessManager being tested.
Bug: 374253381
Change-Id: Ie04e820460bdd078f6ef7de1cac33a99b5f8aeea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5954132
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: mmenke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372695}
Apparently, blink handles key down and raw key down events the same way.
Some pieces of content/browser apparently should use blink-like logic but they do not.
This change tries to address it by adding missing key down handling.
Also it includes a necessary change outside of content/browser.
Bug: 40881497
Change-Id: Ic22435674d7054034a3a12d1d5b017248f5508c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5928666
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Mariusz Domżał <mdomzal@google.com>
Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372533}
This CL moves following classes into the "on_device_translation"
namespace.
- OnDeviceTranslationServiceController
- TranslationManagerImpl
- Translator
This CL should not introduce any behavior change.
Bug: 374631433
Change-Id: I58a469953abea7a585825a0fe6fc5afcf89420c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5953006
Reviewed-by: Alex Gough <ajgo@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372530}
The filtered out accounts are not filtered in the case where the user
just logged in to the IDP and there are no new unfiltered accounts. This
includes the case where all accounts are filtered out. On desktop, the
HoverButton is disabled, but the UI still needs to be updated. On
Android, the UI is not updated at all, but it is behind the flag.
Followups will implement proper disabled accounts UI on both.
Bug: 40945672
Change-Id: Ie436542d12b87b17c461102edfedad85066ecf83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5867640
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Nicolás Peña <npm@chromium.org>
Reviewed-by: Yi Gu <yigu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372517}
When SwiftShader is not enabled for the GPU process, the GPU process has
no need for the `com.apple.security.cs.allow-jit` entitlement. It can be
run using a normal, unentitled helper app instead.
Bug: 374064153
Change-Id: Ia67e21d99b5fafddc8ddd16275e9b216e7053370
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952835
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Auto-Submit: Mark Rowe <markrowe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372375}
Following a suggestion by Nasko in https://crrev.com/c/5867574, this
handles performance scenario shared memory completely in the blink and
components/performance_manager layers, getting rid of a shim through
content/ and chrome/.
This will unblock a followup CL to attach the browser-side
StructuredSharedMemory region to ProcessNode instead of
RenderProcessHost, which is blocked by the content/ shim accessing it
synchronously on the UI thread. The cost is an extra IPC roundtrip on
process startup.
Includes a partial revert of https://crrev.com/c/5867574 that returns
mojom::Renderer::TransferSharedMemoryRegions to TransferSharedLastForegroundTime.
Bug: 365586676
Change-Id: I681a3c941661ebba7c10b7abaf54aa5c4e430a9e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5949866
Commit-Queue: Joe Mason <joenotcharles@google.com>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Auto-Submit: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/main@{#1372300}
This CL:
a. Move DeviceConnectionType into WebContents and rename it to CapabilityType
b. Merge all IsConnectedToXXX() functions into a single IsCapabilityActive() function
c. Rename OnDeviceConnectionTypesChanged() method to OnCapabilityTypesChanged().
Bug: 372836924
Change-Id: Ib8be8821dff459c3788aeeb0fc4921f3996ec069
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5938280
Reviewed-by: Patrick Monette <pmonette@chromium.org>
Commit-Queue: Yifan Luo <lyf@chromium.org>
Reviewed-by: Matt Reynolds <mattreynolds@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372240}
To show geolocation usage in the left-hand indicator. We need to expose
it to PageSpecifiedContentSetting.
In this CL, this usage information is exposed with the same method as
HID/bluetooth with the web contents observer.
Change-Id: I730547e07955cd07913c49e92abd6ce01bbde05d
Bug: 372836924
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5920698
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Elias Klim <elklm@chromium.org>
Reviewed-by: Matt Reynolds <mattreynolds@chromium.org>
Commit-Queue: Yifan Luo <lyf@chromium.org>
Reviewed-by: Francois Pierre Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372239}
Dump without crashes can be noisy in stable. This flag will enable us to
turn it off and on in different versions of Chrome avoiding extra noises
while being informed about them happening.
Bug: 374365779, 373617224
Change-Id: Iee0536c303a571f962b1816667d2fbc67da8ff46
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5950247
Reviewed-by: William Liu <liuwilliam@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: Baran Erfani <baranerf@google.com>
Cr-Commit-Position: refs/heads/main@{#1372216}
This reverts commit fffe2c8c47.
Reason for revert: We have fixed all known HitTestOpaqueness bugs
on M132 and M131, so we enable HitTestOpaqueness it by default
again.
The original CL (Revert "[HitTestOpaqueness] Enable by default")
has been merged into M130 (but not M131). We have also landed a kill
switch to disable HitTestOpaqueness on M130 via finch.
Original change's description:
> Revert "[HitTestOpaqueness] Enable by default"
>
> This reverts commit a56e352a2b.
>
> Reason for revert: There are several bugs, some fixed on ToT
> (crbug.com/348520453, crbug.com/367166494), some
> still need investigation (crbug.com/372722559). We need to unlaunch
> the feature and restart the experiment after all bugs are fixed.
>
> Original change's description:
> > [HitTestOpaqueness] Enable by default
> >
> > Also change status of FastNonCompositedScrollHitTest to stable to make
> > it merely depend on the status of RasterInducingScroll, to simplify
> > dependencies.
> >
> > Bug: 40062957, 40256365, 329115115
> > Change-Id: Ia675bf7a2e833f26f3c113bda12735317d218a07
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5824528
> > Reviewed-by: Philip Rogers <pdr@chromium.org>
> > Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
> > Reviewed-by: Jonathan Ross <jonross@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#1348709}
>
> Bug: 40062957, 40256365, 329115115
> Change-Id: Ibeeeed2eda9365c850c174ca0854bba9ba77855a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5941138
> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
> Reviewed-by: Philip Rogers <pdr@chromium.org>
> Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
> Reviewed-by: Jonathan Ross <jonross@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1370123}
Bug: 40062957, 40256365, 329115115
Change-Id: I5545ded5322d6c0552868a28f12664eb6f1ee543
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5954707
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372207}
OBSOLETE_HISTOGRAMS=No longer needed
Based on the metrics collected, only a very small percentage of
registrations are queued during the period of attestations loading.
Therefore, there should be very little impact on the live traffic,
regardless of the default behavior of the attestations API.
Currently the attestations API defaults allow if attestations are
not available yet. Therefore, there is no data loss on the live
traffic, as well as the pending reports that get sent on browser
startup.
This cl skips waiting for attestations loading, which aligns with other
privacy sandbox APIs and simplifies the implementation.
In a follow up, we may consider always defaulting allow pending
reports if attestations are not available yet to remove the dependency
on the attestations API.
Bug: 374790908, 374325234, 40267739
Change-Id: Ie3664cb4f405d3a29ee9059de7bfd1a112b30a11
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5950404
Reviewed-by: Andrew Paseltiner <apaseltiner@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Nan Lin <linnan@chromium.org>
Reviewed-by: John Delaney <johnidel@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372156}
Also migrate it to use WeakPtrs to WorkletProcesses, to make it safer.
At this point, DedicatedStyleAuctionProcessManagerTest could be merged
into AuctionProcessManagerTest, but it's convenient to keep them
separate for now, since the current crop of AuctionProcessManagerTests
should work for InRenderer and Dedicated test cases, while the
DedicatedStyleAuctionProcessManagerTests do not. I have plans for that,
but not ready for them quite yet.
Bug: 374253381
Change-Id: I825136424efb9993e650f216014049a8804b9607
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952626
Commit-Queue: mmenke <mmenke@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372151}
For web tests this stops WindowEventDispatcher::SynthesizeMouseMoveEvent
from sending the renderer a mousemove, which it normally does on startup
and whenever we swap in a new RenderWidgetHostView.
The benefits of this change are:
- Eliminating potential flakiness by making the web tests more order-
agnostic. Tests can behave differently with the mouse at (0,0) versus
the position-unknown state which is restored in between test runs by
EventHandler::ResetLastMousePositionForWebTest. This also helps to
de-risk upcoming web test isolation changes (go/web-test-isolation).
- Aligning Windows and Linux behavior with Mac. AppKit sends a native
mousemove to a new on-screen RWHV, similar to what Aura synthesizes.
But AppKit does NOT send these mousemoves to headless web tests.
Bug: 374783343
Change-Id: I6b1d7234410cd6fa799954845bb5b50f5a2b82ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5808379
Commit-Queue: Steve Kobes <skobes@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372147}
This is a reland of commit 02529b84f5
Original change's description:
> [views_ax] Adding a histogram to measure a11y Windows API performance
>
> This CL adds a histogram to measure the perf of Windows accessibility
> API calls. It differentiates between when its called by a View or by
> web contents. This is so that when the ViewsAX project is done, we can
> compare the performance of before and after.
>
> To determine whether the API is being called on a View or not,
> we check if we have an associated node. If we don't, then it is
> definitely a View. Currently if we have an associated node then
> it is not a View, however, in the future we will have AXNodes
> in Views, which is why I added an extra check in the macro for
> when this is the case.
>
> Bug: 325137417
> Change-Id: I022c606a6073512fe0edf6d2e2b69755880d4bdd
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5368828
> Reviewed-by: Jacques Newman <janewman@microsoft.com>
> Commit-Queue: Javier Contreras <javiercon@microsoft.com>
> Reviewed-by: Benjamin Beaudry <benjamin.beaudry@microsoft.com>
> Reviewed-by: Evan Liu <evliu@google.com>
> Cr-Commit-Position: refs/heads/main@{#1273695}
Bug: 325137417
Change-Id: I80e85c88aed3bb0c803ef3c6dba1960f4aeeb310
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5915945
Reviewed-by: Evan Liu <evliu@google.com>
Commit-Queue: Sejal Anand <sejalanand@microsoft.com>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372143}
What:
- Introduce SharedStorageSet(/Append/Delete/Clear)Method and a union
type SharedStorageModifierMethod. Consolidate the existing modifier
methods into a single
`SharedStorageUpdate(SharedStorageModifierMethod)` method.
- No behavior change.
Why:
- Enable Batch Updates: This prepares for the upcoming support for the
JavaScript API, batchUpdate(sequence<SharedStorageModifierMethod>),
allowing websites to perform multiple modifications in a single
operation. Explainer: https://github.com/WICG/shared-storage/pull/199
- Improved Maintainability: This simplifies the Mojo interface and
reduces future maintenance overhead.
Bug: 373899210
Change-Id: I3b516b577fb170cca19bd7f9afa1c019f53e0f45
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5949646
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372139}
In particular, have both production subclasses use a virtual method to
actually launch the process and create the service, after creating the
WorkletProcess. This will help with writing tests that want to test
production behavior of both subclasses, since some tests need to muck
with the WorkletProcess. There are also a lot of parameters to
the WorkletProcess constructor now, and this will help prevent mocks
from messing them up.
Bug: 374253381
Change-Id: I843e20cb0214cf2fb021b72833ff285a9cf24123
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5950026
Commit-Queue: mmenke <mmenke@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372133}
Request worklets for buyers (including top-level and those in component auctions) before sellers (top-level and component). This change will
allow us to make the most of starting un-bound anticipatory
processes at the start of auctions because we may have fewer ready
processes than we have buyers+sellers.
Bug: 365528726
Change-Id: I9408432dbbec43b25fcad3d44401fc047aca14ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5939354
Reviewed-by: mmenke <mmenke@chromium.org>
Commit-Queue: Abigail Katcoff <abigailkatcoff@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1372086}
This removes code implementing the native ChromeOS authenticator for GPM
passkeys. ChromeOS has since launched support for GPM passkeys using the
enclave authenticator, so this code is now obsolete.
Change-Id: Ie179188900c6f5471ea7525a0aa03f47a669d5df
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5939975
Reviewed-by: Ryan Sultanem <rsult@google.com>
Reviewed-by: Mohamed Amir Yosef <mamir@chromium.org>
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Reviewed-by: Adam Langley <agl@chromium.org>
Reviewed-by: Maksim Moskvitin <mmoskvitin@google.com>
Cr-Commit-Position: refs/heads/main@{#1372082}
This CL does the following:
* Implements RenderWidgetHostViewInput interface as
RenderInputRouterSupportChildFrame mirroring
RenderWidgetHostViewChildFrame class in browser for handling input on
Viz with InputVizard. This CL just adds the skeleton of
RenderInputRouterSupportChildFrame class's implementation with bunch of
TODO's which are being tracked with bugs and will be added later in the
upcoming CL's.
* This CL also introduces ChildFrameInputHelper class to share code
between RenderWidgetHostViewChildFrame (in Browser) and
RenderInputRouterSupportChildFrame (in Viz).
Doc Link:
https://docs.google.com/document/d/1tRPUd11fuPcXxb2ep_kGYPahgv0OOlV7DvsGkbom7VA/
Bug: b:367695776
Change-Id: Idcd1efa39e6a1a20850201a662c3ecdeb1d482d1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5937819
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: Aman Verma <amanvr@google.com>
Cr-Commit-Position: refs/heads/main@{#1372046}
Window context menu options when network is revoked.
Fenced frames(FF) can disable network access by invoking FF API:
window.fence.disableUntrustedNetwork().
After the network access is revoked, FF will get access to cross-site
data, for example, via shared storage get API.
The principle is no network request can be made using URLs in a
network-disabled FF, including user triggered main-frame navigations.
This is because the URL can leak cross-site data, for example, by
appending the cross-site data to the URL.
This CL disables Open Link in New Tab/New Window/Incognito Window
context menu options when FF network is revoked.
Bug: 364825899, 364904745, 364825898
Change-Id: Ic066e0899578a0acb5222b0069205e01c42b811a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5934756
Reviewed-by: Erik Chen <erikchen@chromium.org>
Commit-Queue: Xiaochen Zhou <xiaochenzh@chromium.org>
Reviewed-by: Liam Brady <lbrady@google.com>
Cr-Commit-Position: refs/heads/main@{#1371993}
This CL expands upon the previously added histogram for tracking the
usage of inline text boxes on Android. There are two primary ways in
which the inline text boxes can be requested, and this CL breaks the
histogram into two patterns so that we can track the call sites
separately. We also add a histogram to track whether or not the
requests from an AT are duplicates and do not need to be fulfilled.
We also remove a few lines from a test to eliminate flakes.
OBSOLETE_HISTOGRAM[Accessibility.Android.InlineTextBoxes.Bundle]=Replaced by patterned histogram with .{CallLocation} appended.
AX-Relnotes: N/A
Bug: 372718628
Change-Id: I266ebb9ec6b14fec706525d28aca3a146e93fac0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5949586
Reviewed-by: Akihiro Ota <akihiroota@chromium.org>
Auto-Submit: Mark Schillaci <mschillaci@google.com>
Commit-Queue: Mark Schillaci <mschillaci@google.com>
Cr-Commit-Position: refs/heads/main@{#1371978}
In most cases, initiator*'s value can be calculated directly from RFHI.
The only exception is `initiator_web_contents`.
So, this CL passes RFHI directly to the ctor, and let the ctor to
calculate the values.
This CL is a preparation for the following CLs to add more information to PrerenderAttributes.
Bug: 40246462, 40240492
Change-Id: I2317192de0024126f44c1d947cabb3bfffd4417e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5943847
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Taiyo Mizuhashi <taiyo@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1371876}
Windows MediaFoundation report `max_macroblocks_per_second` equals
1944000 on Qualcomm Adreno 690 GPU, which technically should support
3840x2160 up to 60fps or 1920x1080 up to 240fps resolution and
framerate. However, the actual result is, it does support 3840x2160
up to 60fps, but only supports 1920x1080 up to 238fps instead of
240fps.
Update the exception comment and condition so we know better about
this issue, we can't really do much to solve this.
Bug: 373648897
Bug: 365813271
Change-Id: Idad6f460bbfcec960015fb569833ff5d8901d033
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5941334
Reviewed-by: Eugene Zemtsov <eugene@chromium.org>
Commit-Queue: Sida Zhu <zhusida@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#1371838}
This CL factors out the computation of the device scale override from
the rest of the WebContentsFrameTracker, to simplify the WCFT and
allow he HiDPI heuristics to be improved without making it more
complicated.
Change-Id: I474309ccba1d82ea7d850112b4a4ca46b44e015f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5932824
Reviewed-by: Jordan Bayles <jophba@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1371808}
The Polymer version is no longer used anywhere and iron-iconset-svg has
already been removed from Desktop builds, since crrev.com/c/5869465.
Therefore there is no longer a need to generate the Lit version from
the Polymer one during the build.
Bug: 40943652
Change-Id: Icc8b36c17b7a26da3cf0e51f41e71551604f7b54
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5949028
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Rebekah Potter <rbpotter@chromium.org>
Auto-Submit: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1371806}
