Comments

Make cc_unittest to use SkiaOutputSurface
Current SkiaRenderer support several draw modes, but in future
we will only support one draw mode which is using SkiaOutputSurface.
So we need make all tests switch to SkiaOutputSurface.
Bug: 929843
Change-Id: I31de102b62450ac35ed5d440b69b60fd6ed872c3
Reviewed-on: https://chromium-review.googlesource.com/c/1479297
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Jonathan Backer <backer@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#634760}

Comments

device/fido: refactor pin.cc to enable testing.
In order to test this code we'll want to implement the authenticator
side of the PIN protocol in |VirtualCtap2Device|. It'll be helpful when
doing so to have access to some code from pin.cc.
This change exposes some PIN-protocol internals via a |pin_internal.h|
header for a future implementation in |VirtualCtap2Device|.
Change-Id: I76f2441185b4d1a058240de5d2cb9bbf49dc1061
Reviewed-on: https://chromium-review.googlesource.com/c/1481083
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Commit-Queue: Adam Langley <agl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#634759}

Comments

SPM: Fix VK crash on leaving tablet mode
The crash is caused by a race of WS and KeyboardControllerObserver
mojo interface. When we close keyboard hosting window, we send
OnKeyboardOccludedBoundsChanged and OnKeyboardUIDestroyed via
KeyboardControllerObserver then close the hosting window. But
the browser process could receive the hosting window close via
WS first hence the crash.
The CL wires the unembed code path that happens on hosting window
close with ChromeKeyboardControllerClient::OnKeyboardUIDestroyed.
After OnKeyboardUIDestroyed, the calls on KeyboardControllerObserver
interface will be no-op and the crash would not happen.
Bug: 931910
Change-Id: I2b777a56dca3c26e1f734b732d488165936a291a
Reviewed-on: https://chromium-review.googlesource.com/c/1482948
Commit-Queue: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: James Cook <jamescook@chromium.org>
Cr-Commit-Position: refs/heads/master@{#634758}

Comments

Document how mini_installer avoids linking to the CRT
We spent a while figuring out how and why mini_installer.exe avoids
pulling in the C run-time and I wanted to make sure it was working
correctly and was slightly better documented. This just adds some
comments, for future generations.
Bug: 934032
Change-Id: I917a7532d6d8e92a21d58e9cedf0af44fee488ed
Reviewed-on: https://chromium-review.googlesource.com/c/1481956
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#634753}

Comments

Resolve stroke-width 'em' units against unzoomed font size
When resolving style for the 'stroke-width' property we would use
CSSToLengthConversionData::CopyWithAdjustedZoom() with an argument of 1
to get an "unzoomed" length. The FontSizes object was however not
adjusted, so still carried zoomed base font sizes.
Make a new method on StyleResolverState that returns an
CSSToLengthConversionData that uses unzoomed unit bases, basing it on
the existing FontSizeConversionData() method which does roughly the
same thing except it uses the parent style for unit bases.
Bug: 933689
Change-Id: Icfbc59a641f0dc2d94f00ba5f3e9a15b36f8c195
Reviewed-on: https://chromium-review.googlesource.com/c/1481417
Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#634750}

Comments

[LayoutNG] Handle OOF descendants stored in LegacyBlocks directly
This CL changes how NG deals with OOF Elements held by Legacy.
NG and Legacy use different mechanisms to "bind" OOF Elements
to their container.
NG binds OOF Elements to their container by propagating them
up the tree during layout.
Legacy LayoutBlocks keeps a list of PositionedObjects, and
add and remove from this list directly from OOF child.
The case tackled in this CL is this:
NG is the container, and has a positioned child that
has not propagated trought the tree during NG layout because
Legacy was on a path between child and its container.
For example:
<div#container position:relative>
<div#legacy display:flex>
<div#oof position:absolute>
When #container is placing OOF descendants, its NG
list of descendants will not contain #oof, because
#legacy was laid out with Legacy code. Instead, #oof
is in the Legacy's list of #container.PositionedObjects.
The interesting part here is computing the static position
of #oof wrt #container.
What previous code did was this:
- it let Legacy decide when PositionedObjects are laid out.
- when NG positioned object got called to Layout(), it
would compute abspos constraints (static_position,
constraint_space), create a new NGOutOfFlowLayoutPart
- NGOutOfFlowLayoutPart would place the object
The new code changes who triggers layout of these objects.
Instead of waiting of Legacy to layout its positioned
objects, it pulls them out of Legacy, and places them during
NGOutOfFlowLayoutPart::Run.
This makes computing static position for Legacy elements
tricky. Container has not copied its data back to Legacy,
and its children have not had their offset set.
Legacy code that computes static offset needs children's
offset, and that information is no longer available from
LayoutObjects. That information can be found in
NGContainerFragmentBuilder. That is why builder gets passed in
to LayoutBlock::ComputeBlockStaticDistance
The code also contains some minor fixes:
1) to bugs that were exposed by this change.
2) for bugs that would otherwise be caused by this change.
NGContainerFragmentBuilder::AddChild needed to take
relative position into account when propagating OOF
descendants.
NGContainerFragmentBuilder::GetChildOffset could be called
on a grandchild, if child is a linebox.
Bug: 921396
Change-Id: Ib9a26596f21971374854cf6ec2729b10b3cd834a
Reviewed-on: https://chromium-review.googlesource.com/c/1476087
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#634743}