Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] master from chromium:master #58

Merged
merged 6 commits into from
Oct 3, 2021
Merged

Conversation

pull[bot]
Copy link

@pull pull bot commented Oct 3, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

vincb2 and others added 6 commits October 3, 2021 01:18
Currently, the forced sign-in screen can only be presented on the
browser view controllers (incognito tab or regular tab), because
interfaceProvider.currentInterface.viewController only provides the
browser view controller used on the current browser interface.

TabGridViewCoordinator.activeViewController provides the view controller
that is really active. For example, activeViewController will provide
TabGridViewController when the active view is the regular tab switcher.

Tested on each surface: incognito tab, incognito tab switcher, regular
tab, regular tab switcher, and recent tabs. See
http://shortn/_fBkQ0PBzFB.

Bug: 1250761
Change-Id: I3008535b6f715a704c2d6592de6609cb4d58ee21
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3188491
Reviewed-by: Gauthier Ambard <[email protected]>
Reviewed-by: Mark Cogan <[email protected]>
Commit-Queue: Vincent Boisselle <[email protected]>
Cr-Commit-Position: refs/heads/main@{#927547}
This CL fixes a bug that was due to UpdateTreeOfRendererFrame()
erroneously assuming that frames removed from FormData::child_frames
have been or will be destroyed.

Frames may also be removed from FormData::child_frames because they
have become invisible.

In such a case, this CL unsets the removed frame's
FrameData::parent_form. That way, the former parent's
FormData::child_frames and the former child's FrameData::parent_form
are consistent.

As far as I can tell, this bug had no relevant consequences.

To keep the code simple, this CL does not push the fields that
originate from forms in the child's subtree to the child. The fields
are simply deleted, and only restored upon the next reparse of the
forms in the child's subtree.

Pushing the fields to the child's subtree is possible by tweaking
UpdateTreeOfRendererForm()'s tree traversal, but it does add some
further complexity.

Bug: 1187842, 1187857
Change-Id: I8fd7791e93609b1cf27cdc99eb917080c0f549c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3190490
Commit-Queue: Christoph Schwering <[email protected]>
Reviewed-by: Dominic Battré <[email protected]>
Cr-Commit-Position: refs/heads/main@{#927548}
Change-Id: I87c86d5bf10dee04050b1b501c3096dfe0fcdd15
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3201450
Auto-Submit: Ben Mason <[email protected]>
Commit-Queue: Rubber Stamper <[email protected]>
Bot-Commit: Rubber Stamper <[email protected]>
Cr-Commit-Position: refs/heads/main@{#927549}
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/fuchsia-sdk-chromium-autoroll
Please CC [email protected] on the revert to ensure that a human
is aware of the problem.

To file a bug in Chromium: https://bugs.chromium.org/p/chromium/issues/entry

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Cq-Include-Trybots: luci.chromium.try:fuchsia-arm64-cast;luci.chromium.try:fuchsia-deterministic-dbg;luci.chromium.try:fuchsia-x64-cast
Tbr: [email protected]
Disable-Retries: true
Change-Id: I275118139c5b282eadf8ce607f3312b38dce5002
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3201074
Commit-Queue: chromium-autoroll <[email protected]>
Bot-Commit: chromium-autoroll <[email protected]>
Cr-Commit-Position: refs/heads/main@{#927550}
Unit tests are also converted

Bug: 1254879
Change-Id: I6ff43f5cc82549ab3b425ced87cce2abe7e8510b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3198329
Commit-Queue: Weizhong Xia <[email protected]>
Reviewed-by: Kyle Ju <[email protected]>
Reviewed-by: Dirk Pranke <[email protected]>
Reviewed-by: Rakib Hasan <[email protected]>
Cr-Commit-Position: refs/heads/main@{#927551}
See bug for screenshots of the change.

Bug: 1253911
Change-Id: Ia53f069782477d7340aa3c47026533bb4afb1067
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3191755
Reviewed-by: Mihai Sardarescu <[email protected]>
Reviewed-by: Tanmoy Mollik <[email protected]>
Commit-Queue: Jonathan Freed <[email protected]>
Cr-Commit-Position: refs/heads/main@{#927552}
@pull pull bot added the ⤵️ pull label Oct 3, 2021
@pull pull bot merged commit 7cbda33 into jamlee-t:master Oct 3, 2021
pull bot pushed a commit that referenced this pull request Nov 16, 2023
This reverts commit 8ca224d.
(reverted the m120 cherry-pick then cherry-picked it back to main
since Gerrit was throwing errors trying to revert the main revert,
or reland the original).

Reason for revert: fixed delegated quads in LaCros that caused
https://crbug.com/1497384. When drawing an RPDQ into a texture
for an overlay, the target-to-device transform is overridden in
CalculateDrawQuadParams(). There had been no parameter to also
pass this transform into CalculateRPDQParams().

Before the original CL, this was irrelevant because all of the
bounds math stayed in target space. With the original CL it
mapped through device space using the current frame's transform.
The CRD overlay panels with filters would be discarded because
their original target space had them on the left side of the
screen (high X values) being clipped against the 0-anchored
clip of the overlay's overridden setup.

Now we just pass in the transform_to_device to
CalculateRPDQParams as well so that the overlay is correctly
clipped (or not as the case may be). This patch was been tested
and verified not to re-trigger crbug.com/1497384
(thanks @khaslett!).

Original change's description:
> Revert "Improve backdrop filter calculations in SkiaRenderer"
>
> This reverts commit bbbcef0.
>
> Reason for revert: possibly breaking https://bugs.chromium.org/p/chromium/issues/detail?id=1497384
>
> Original change's description:
> > Improve backdrop filter calculations in SkiaRenderer
> >
> > Pulls all of the bounds analysis for how to clip the output and input
> > of a backdrop filter into the CalculateRPDQParams function. Improves
> > the calculations for the `filter_bounds` value to be tighter for
> > backdrop filters since their output is always restricted.
> >
> > Optimizes more cases to have backdrop output restricted by just a
> > clip instead of introducing an image filter node at the end. Switches
> > the input cropping node from a no-op Offset(0,0) to a proper `Crop`
> > that can define the boundary tilemode to apply (kClamp). This
> > actually fixes the behavior in the backdrop-offset unit test. It also
> > makes it possible to easily experiment with using mirror tiling for
> > content that is off screen.
> >
> > Re-organizes some of the logic for clipping or clearing the backdrop
> > bounds into helper functions in RPDQParams so that
> > PrepareCanvasForRPDQ is more readable.
> >
> > The backdrop logic to determine if an input crop is needed or not
> > used to have a bug (exposed when removing the staging flag
> > SK_USE_LEGACY_CONTENT_BOUNDS_PROPAGATION). The input bounds
> > calculation needs to use a null src rect so that the returned value
> > has no additional content restriction. If it *still* matches the
> > target output bounds, then we know it's not a pixel-moving backdrop
> > filter. I confirmed that the backdrop boundary layout tests work
> > correctly with and without the above staging flag.
> >
> > Updates the conversion of FilterOperations to PaintFilter to define
> > the tiling geometry, so that clamp, mirror, and repeat explicitly
> > apply to the edges of a layer (instead of previously just the edge
> > of whatever image size happened to come through the pipeline). This
> > currently is only taken advantage of in SkiaRenderer,
> > SoftwareRenderer continues to use the legacy (less stable/defined)
> > tiling behavior.
> >
> > Bug: b/40040615
> > Bug: chromium:978031
> > Bug: chromium:1473071
> > Bug: chromium:1451898
> > Change-Id: I65aef30266129b2b76cb7c9d38a38e8444c6789a
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4936570
> > Commit-Queue: Michael Ludwig <[email protected]>
> > Reviewed-by: Kyle Charbonneau <[email protected]>
> > Reviewed-by: Andrew Xu <[email protected]>
> > Reviewed-by: Xiyuan Xia <[email protected]>
> > Cr-Commit-Position: refs/heads/main@{#1215501}
>
> (cherry picked from commit 8924d0c)
>
> Bug: b/40040615
> Bug: chromium:978031
> Bug: chromium:1473071
> Bug: chromium:1451898
> Change-Id: If2efd16db803373fa7426324346ba8b64f04de3a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4989963
> Commit-Queue: Xiyuan Xia <[email protected]>
> Reviewed-by: Andrew Xu <[email protected]>
> Auto-Submit: Michael Ludwig <[email protected]>
> Reviewed-by: Xiyuan Xia <[email protected]>
> Cr-Original-Commit-Position: refs/heads/main@{#1217605}
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4998065
> Commit-Queue: Srinivas Sista <[email protected]>
> Owners-Override: Srinivas Sista <[email protected]>
> Bot-Commit: Rubber Stamper <[email protected]>
> Cr-Commit-Position: refs/branch-heads/6099@{#58}
> Cr-Branched-From: e6ee450-refs/heads/main@{#1217362}

Bug: b/40040615
Bug: chromium:978031
Bug: chromium:1473071
Bug: chromium:1451898
Change-Id: I52b28498691919e0066e65b09df1bd1bc070a149
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5002826
Reviewed-by: Xiyuan Xia <[email protected]>
Commit-Queue: Michael Ludwig <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1225765}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants