We were passing offsets and sizes as integers. Use floats instead. In
some parts of the code, sizes and offsets are in CSS pixels, in other
parts they are in device pixels, and in some other parts they are in
points. There are reasons for this, although it's currently a bit more
convoluted than it has to be.
Converting between them was done carefully with integer arithmetic and
some special rounding code. This has worked mostly fine, but is fragile.
I'm working on a CL that straightens out the conversions, to use CSS
pixels instead of points in the Blink APIs (since that's what Blink uses
internally). This would however mean that, if we were to keep on using
integers, rounding errors that used to occur when printing HTML with
Blink would be fixed, but, at the same time, we'd introduce new rounding
errors when printing with a plug-in (when opening a PDF and printing
it), since that part of the code wants things in points.
So use floats to avoid this. This also allows for removal of
PrintParamsWithFloatingSize. Although floats have precision issues for
large integer values, this shouldn't be a problem here, since all the
values changed are about page sizes, or offsets into a page (margins,
unprintable area, etc.). Floats have 23 bits for the integer part, so
as long as we stay (way) below a million pixels / points / whatever,
we're good. It would easily become a problem if we start using floats
for offsets into documents, though, as documents can become very tall.
This CL isn't expected to make much of a behavior difference on its
own. We'll still round down sizes to the nearest integer when entering
Blink HTML layout, since we cannot reliably print fractional page sizes
anyway. Furthermore, the way LocalFrame::ResizePageRectsKeepingRatio()
is used to magically convert from points to pixels is inaccurate, and
still causes the symptoms described in crbug.com/1444579
But it should now be more straight-forward to fix such issues without
introducing new ones.
Change-Id: I5fc5afeb14e5470faf970c9f7c94d0fad243ce3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4604506
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160870}
This CL introduces a limit of 500 alarms per extension. The number
was chosen based on data collected from the stable channel for all
platforms. This limit covers at least 99.98% of all clients.
Bug: 1400582
Change-Id: I2c22231f1770ca6bb7bc46b56119331c23e977d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4583941
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Commit-Queue: David Bertoni <dbertoni@chromium.org>
Reviewed-by: Kelvin Jiang <kelvinjiang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160867}
Used Android Studio's "Structured Replace" to add it to all
setForTesting methods that contained a single assignment. Then
went through all spots to reset to "null/false" vs |oldValue|.
Removed calls to modified set*ForTesting(null/false) methods using
grep/sed/python then removed empty @After methods.
* Also cleans up some calls that had both @VisibleForTesting and
ForTest suffix (annotation is incorrect in this case).
* Also renamed a few test-only variables to have "ForTesting" suffix.
Updated tests that broke as a result. Things that broke:
* When setForTesting() was being called in @BeforeClass
* When a value was set as a result of normal logic, and then
setForTesting(null) was called to reset it (which then returned it to
it's non-null value).
Bug: 1416224
Change-Id: Id07066389f4ec0d69ebf4e3e1e6caca356cc36d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4626902
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1160862}
Server push is unused in HTTP/2 (it has been disabled a long time ago)
and in QUIC (Google QUIC has been disabled altogether a long time ago,
and IETF QUIC never supported server push), so all removed code is
unused.
Bug: 1426477
Change-Id: Icc4a97060c661007c2f137fa89c5e30f867b786e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4632342
Commit-Queue: Bence Béky <bnc@chromium.org>
Commit-Queue: Ryan Hamilton <rch@chromium.org>
Reviewed-by: Ryan Hamilton <rch@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160861}
CreatePlatformShortcuts was creating a shortcut in the taskbar
directory, and also pinning, when supported. Pinning a shortcut to the
taskbar does this implicitly, so we should not be doing this. For
tests, this is mostly harmless, since the quick launch dir is
overridden. For Chrome, it's potentially harmful.
The CL makes sure that in_quick_launch_bar is false, in the
ShortcutLocations CreatePlatformShortcuts passes to GetShortcutPaths.
This was discovered while trying to make sure that tests don't pin
shortcuts to the taskbar.
Bug: 1454110
Change-Id: I6555f36bf5340c8c630c3156ff369128a21298bd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4629879
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Commit-Queue: David Bienvenu <davidbienvenu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160858}
Display synced GPM passkeys on webauthn's conditional UI. Credentials
are shown for users who have opted in to syncing them. Credentials may
also show up on the platform authenticator credential picker. This is
okay as we'll update that UI surface before launching the feature.
For now, credentials are rendered with the subtext "Use lock screen". A
follow-up will change this to display the device name.
Tapping a GPM passkey dispatches to a sync paired phone. At the moment,
this is the first applicable phone on the list. A follow-up will have
Chrome remember the last used phone instead.
Finally, with the feature enabled IsConditionalMediationAvailable will
always return true on all desktop platforms since they are all capable
of showing GPM passkeys.
This feature is guarded by the WebAuthenticationListSyncedPasskeys flag
and requires SyncWebauthnCredentials to be enabled as well.
Bug: 1428655
Change-Id: I7297935f905f443eae4b4b0621128c2bc47f0966
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4621635
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Commit-Queue: Nina Satragno <nsatragno@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160857}
There are too many callers to migrate all at once, creating alises
in ColorProviderManager to facilitate the migration.
Many includes of color_provider_manager.h just need one of the types and
not the manager itself. Separate the Key types and declaration into its
own compilation units.
This allows targets to set ColorProviderKey values without depending
on the entirety of ui/color.
Bug: b:286952053
Change-Id: I6a5561d9c12e74f1c843de0fee262357094459eb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4629411
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Commit-Queue: Thomas Lukaszewicz <tluk@chromium.org>
Auto-Submit: Sean Kau <skau@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160856}
This CL switches to incognitio mode, navigate to a pwa site and make
sure there is no installation icon.
CheckInstallIcon(Not)Shown is updated because the web contents from
incognito mode would result in an empty app banner manager.
Bug: b/287739278
Change-Id: Ie1a650276a355fa1d421278258fc7689abc1575c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4630550
Commit-Queue: Clifford Cheng <cliffordcheng@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160848}
Currently both fontKerning and fontVariants accept case insensitive strings as inputs; whereas the specs require the inputs as enum and case sensitive. Update the code to reflect that.
Bug: 1456482, 1448662
Change-Id: I947cfdf5d696377ac0a176d38b01202c6f74074d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4629808
Reviewed-by: Justin Novosad <junov@chromium.org>
Commit-Queue: Yi Xu <yiyix@google.com>
Cr-Commit-Position: refs/heads/main@{#1160844}
The 'from-font' value is newly added to CSS Font Module Level 5 [1],
which allows the browser to automatically determine a font-size-adjust
value based on the primary font. This change implements it.
[1] https://www.w3.org/TR/css-fonts-5/#valdef-font-size-adjust-from-font
We tweak font-size-adjust-013.html to make Windows happy. The platform
got a one-pixel mismatch of width and height due to subpixel rendering.
Test:
external/wpt/css/css-fonts/font-size-adjust-013.html
external/wpt/css/css-fonts/parsing/font-size-adjust-computed.html
external/wpt/css/css-fonts/parsing/font-size-adjust-valid.html
Bug: 1219875
Change-Id: I79b401689c1afdbdb581112fe0778ca4a520a441
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4542920
Commit-Queue: ChangSeok Oh <changseok.oh@bytedance.com>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160843}
Now that all version skew tests use Ash >= 114, the migration to the new
testing protocol is complete. Thus, we can remove the per-channel
version skew filters again and go back to the previous, simpler setup.
Bug: 1353089, 1429632
Change-Id: Ie3b236d8fcebc5a8bb8923324b0d39bd6858ebba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4607448
Reviewed-by: Sven Zheng <svenzheng@chromium.org>
Auto-Submit: Max Ihlenfeldt <max@igalia.com>
Commit-Queue: Sven Zheng <svenzheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160842}
This is browser test for GetClassificationAPI for default model. This
ensures that with the new changes API is working as intended.
Change-Id: Id6f1a17c83b690bb5600ec93fc2e2170505aed84
Bug: 1428719
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4604379
Reviewed-by: Siddhartha S <ssid@chromium.org>
Commit-Queue: Ritika Gupta <ritikagup@google.com>
Cr-Commit-Position: refs/heads/main@{#1160841}
Below spec will represent release blocker tests for green release:
- 'release_blocker': if true any failure will block canary release.
- 'bug_component': should not be empty if a test suite is
release_blocker. Thus gardener could file bug to notify the owners.
Proposal doc: go/chrome-green-release-tests
BUG=1455536
TEST=generate_buildbot_json_unittest.py
Change-Id: I629de3b5f98f34f09679e0b9c443acb4829905a8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4621604
Commit-Queue: Xinan Lin <linxinan@chromium.org>
Reviewed-by: Sven Zheng <svenzheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160838}
We want to keep track the current open bubble in StatusAreaWidget by
storing a pointer of TrayBubbleView (will be used in crrev/c/4615691).
This will also remove the need of using ScopedTrayBubbleCounter in this
class.
Bug: b:4594540
Change-Id: Id51e5eddc1f37af3b215cc6588dd16b782735720
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4627736
Reviewed-by: Alex Newcomer <newcomer@chromium.org>
Commit-Queue: Andre Le <leandre@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160833}
AdjustTargetForFullScreenLetterboxing does not handle the case where the swap chain is larger than the screen size, this change detects that case and disables the optimization.
In this case overlay_onscreen_rect is 1920x1080,
swap_chain_size 1920x1080 and monitor size is 1366 x 768.
clipped_onscreen_rect is 1365 x 768.
Change-Id: I35bd425b5d5242555b7ed52b9e0396ed896fb1d8
Bug: 1456494
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4624835
Commit-Queue: Sushanth Rajasankar <Sushraja@microsoft.com>
Reviewed-by: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160832}
This CL is a temporary workaround for flipped WebGL content issue. This
workaround will be removed when bottom left origin image is supported by
graphite.
Bug: 1449764
Change-Id: Iffe046cc50628ffee8014b356fd5d742d490fba4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4632917
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160831}
Reland note: iframes.sub.html was timing out because it contains several
sub-tests, each of which now wait 2s which, in total, exhausted the 6s
timeout. Reland marks this test as timeout=long to use the extended
timeout. Previously landed CL is first patchset.
Text fragments currently perform up to two searches, one when document
parsing completes and a second attempt when document load completes (if
load wasn't completed at parse complete time). However, pages, often
load content after document load, when content is "dynamically loaded".
One popular example is Mobile Wikipedia, which adds `hidden=until-found`
on collapsed sections in idle tasks after load. This meant
text-fragments couldn't target pages like these.
This CL attempts to make text fragments work on dynamically loaded pages
by performing a third attempt, if needed. If all directives haven't
matched at load time, a delayed task is scheduled for 500ms that will
request attachment on unmatched directives. TextFragmentAnchor listens
for relevant changes in the DOM and reschedules this task each time a
change is made. At 3000ms it gives up and performs the search to avoid
waiting forever.
At a high level, this CL tries to separate the state tracking of actions
performed for the first matching directive from the state tracking for
running multiple searches. This is done by introducing a new iteration_
enum tracking the latter.
Bug: 963045
Change-Id: Ied3f9c610c348eeeca23ace50864f0cc2ff2b233
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4629864
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Auto-Submit: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160827}
We skip it when biometrics are available, but if uv=required in
clamshell mode then we'll have to collect the local password anyway, so
can skip it there too.
Bug: 1456536
Change-Id: I68a243f998a7ae85669e425f35bc74262e9fbd02
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4630430
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Auto-Submit: Adam Langley <agl@chromium.org>
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Quick-Run: Adam Langley <agl@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160826}
This CL updates the following schemas to update them to the new format
for defining asynchronous returns.
- serial
- hid (sans receive, which has a multi-param callback)
- browser
- app.window
- fileSystem (sans chooseEntry, which has a multi-param callback, and
restoreEntry, which has a setUpdateArgumentsPostValidate hook that
can call the callback early)
- syncFileSystem
Note: These are mostly deprecated and restricted APIs, but are being
modified for consistency.
Bug: 328932
Change-Id: Ifaa94be4622efd4d3f6f1226f33c33735dd32874
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4599193
Commit-Queue: Tim <tjudkins@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160824}
These two unittests were added to 3 CQ builders in
https://crrev.com/c/4515018 as swarmed script tests. That was done to
allow us to stop them being invoked via PRESUBMIT, since the tests
took ~10s. That can be a long time if you're making a simple
//testing/buildbot/ change.
So this finally moves them out of PRESUBMIT invocations. This means
upload times for testing changes should be faster. But a change that
regresses the test will only see the test regression in the CQ
rather than local presubmits. We assume this trade-off is worth it.
See how the CQ failed in https://crrev.com/c/4632504 where a test
failure was introduced.
Bug: None
Change-Id: Ia871696d6e4b3243deac0ff0891644b3a5356e98
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4633730
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Reviewed-by: Erik Staab <estaab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160822}
Fixes FolderUploadConfirmationViewTest.InitiallyFocusesCancel on Lacros
by checking the stored focus view instead of the focused view. On
Lacros browser_tests, the containing window doesn't have focus so the
focus manager will report no view has focus. Checking the stored focus
will use the current focused view if there is one, and tell us the view
that will get focus when it returns which is what this test needs.
Change-Id: I1ef447c1604af8c26c29019216d2e275f0caed34
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4629189
Reviewed-by: Allen Bauer <kylixrd@chromium.org>
Commit-Queue: Brett Wilson <brettw@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160821}
