Enabling RenderDocument causes same-origin navigations to swap to a new
RenderFrameHost. However, when a RenderFrameHost is changed, the browser
dispatches synthetic mouse events to ensure the renderer knows where the
mouse cursor is. In web tests using the event_sender API, events are
injected into Blink synchronously so the browser-generated synthetic
events may be processed after test events which can affect test output.
This CL changes the web test runner to ensure all synthetic events have
been flushed and processed before the test is started. It does this by
blocking parsing in a web test until input has been flushed, the order
of events from the perspective of WebTestControlHost:
* Initial-state/Test Finished: Set a `next_nav_is_new_test` bit.
* READY_TO_COMMIT: If `next_nav_is_new_test` - call
BlockTestUntilStart in the renderer which blocks parsing in the
current DocumentLoader, before it starts loading the new document.
* <During CommitPending>: Post a task to generate the synthetic
events.
* DID_FINISH_NAVIGATION: If `next_nav_is_new_test` - clear the bit and
post a task to:
* Flush input - this waits until all input has been IPC'd to the
renderer and ACK'd. Note: input may still be queued in
renderer-side compositor or main thread queues.
* Calls StartTest on the renderer.
* StartTest (in renderer)
* Flushes the compositor queue to ensure all its input has been
processed (this may result in queueing input on the main thread).
* Flushes the main thread event queue.
* Unblocks the parser.
Bug: 1416496
Change-Id: I2ac0c3745e74a0a01055d5e7a474036096b8ec6f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4727485
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1188325}
Crashpad is not yet updated for the new location, so leave a
forwarding header to be removed later.
Skipping trybots. This is a Mac change, and it’s passing all
trybots except for android_optional_gpu_tests_rel that is
repeatedly failing on an unrelated issue.
NOTRY=true
Bug: 1444927
Cq-Include-Trybots: luci.chrome.try:mac-chrome
Change-Id: Iad0c903187b0e1e5584c68f2eb00b5b026085596
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4790744
Owners-Override: Avi Drissman <avi@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Auto-Submit: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1185029}
We are using "Courier" as a default monospace font on Mac. Other
browsers, like FF and Safari are using "Menlo" font.
"Menlo" has a better glyph coverage compared to "Courier". It has glyphs
for box-drawing unicode characters and for cyrillic script while
"Courier" does not have them. It also has better glyph attachments
stacking for zalgo text [0].
Changed font sizes in web_tests/external/wpt/css/css-display/display-contents-shadow-dom-1.html and web_tests/external/wpt/css/css-multicol/multicol-width-ch-001.xht due to the pixel differences in glyphs' positions after the change. It was happening because of the rounding of glyphs positions' value (presumably because wpt tests are running without antialiasing and subpixel positioning), see https://bugs.chromium.org/p/chromium/issues/detail?id=1409445. "Menlo" has different advances from "Courier" that's why we wasn't facing this issue before. Changed tests are testing different logic and font size is not affecting that.
[0] https://en.wikipedia.org/wiki/Zalgo_text
Bug: 1449469
Change-Id: I53c94e5b2c9089c05874dff33750e281d1c4ad88
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4700963
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Munira Tursunova <moonira@google.com>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1184059}
Specifically the same-site case and top-level frame case, so that
requestStorageAccess() does not auto-resolve before checking user
settings.
A spec PR will be created for this change. Normally we don't change
things before PRs land, but in this case we're forced to by the branch
cut deadline.
Bug: 1441133, 1471209
Change-Id: I4165dd54c0d4d9e4130946dcca3f1c668b6265e8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4706928
Reviewed-by: Chris Fredrickson <cfredric@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Commit-Queue: Shuran Huang <shuuran@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1181612}
Ensure that embargoed permissions are correctly displayed by querying
for the embedder and requester origin of blocked permissions.
The main change is page_info.cc and chrome_page_info_delegate.cc.
Everything else is adding a second parameter to a PermissionManager
function that is implemented a dozen times.
Bug: 1433644
Change-Id: Ib75b4cc0785764bee9f1c68998233cc62e65e2f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4746465
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Reviewed-by: Elias Klim <elklm@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1180362}
It could override settings that are already initialized using default initializer. Besides, ResetBrowserAfterWebTest() is already called at
the end of running each test.
Historically this call existed because it also initializes some
settings, however, going over each of the calls the defaults are
maintained and behavior such as WebTestResultPrinter is dependent on
test state. (Which will be no-ops during the removed call.)
Change-Id: I3dffecdaf62ed0183b92e221bbe16ed6216286e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4753395
Commit-Queue: Shuran Huang <shuuran@chromium.org>
Auto-Submit: Shuran Huang <shuuran@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1180330}
The cancelHelper is not scoped accurately. Additionally, use a WeakPtr
for the RFH in case a test accidentally invokes the function after the
RFH is destroyed, to avoid UAF.
Bug: 1404951
Change-Id: I67c2259692b90a936cfeb3e268b839e1912879af
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4742921
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1178618}
With CL:4725066, page size calculation is done inside Blink, rather than
in PrintRenderFrameHelper & co. This makes it much easier to support web
tests properly, since we don't use PrintRenderFrameHelper in such cases
(and would otherwise have to duplicate its logic). For now, add support
for page margins. Later on, mixed page sizes will just work
out-of-the-box, once support for that has been added to the layout code
(upcoming CL).
Bug: 835358
Change-Id: Ic2b8b891b692d99f4d2d030a907399338abc96be
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4727864
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1177906}
This pref was linked to threaded compositing in crrev.com/821456 but it
doesn't need to be anymore.
Also remove calls to internals.settings.setThreadedScrollingEnabled()
in web tests that check main-thread scrolling reasons.
Bug: 1087725,1369739
Change-Id: I59b528b542d776fd591fe08e46790fb5f5fde9d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4721697
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1176076}
In crrev.com/c/4401995 and crrev.com/c/4634965 we ensure that the
BFCache NavigationRequest will never outlive the speculative RFH.
So the `rfh_restored_from_back_forward_cache_` should never be
invalidated once set.
This CL changes the type of `rfh_restored_from_back_forward_cache_`
from WeakPtr to optional<SafeRef>, so the caller can claim that it's
either null since the construction, or is currently referencing to a
valid RFH.
Bug: 1430653
Change-Id: Ic9b4513248fbbda03108d49e2c5ebd55955f3f92
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4707476
Commit-Queue: Mingyu Lei <leimy@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1174960}
This CL adds a test case for the read path added in https://crrev.com/c/4672510
The test html is
third_party/blink/web_tests/http/tests/lcp_critical_path_predictor/prioritize_lcp_image.php
, but it requires the following test infra changes to run:
- NonAssociatedWebTestControlHost mojom binding so it can be accessed
from mojo JS binding. Context: discussion at
https://chromium.slack.com/archives/CGGGVPSQ4/p1688601297545099
- WebTestContentBrowserClient injects LCPP hint at
`DidStartNavigation` if it was supplied via
NonAssociatedWebTestControlHost.
- BUILD.gn files are modified so that they will generate
wire format protos used for testing from text protos.
- `lcpp` VirtualTestSuite is added, since the test require the
LCPCriticalPathPredictor feature flag to be enabled until the
feature is unflagged.
Bug: 1419756
Change-Id: Ib7447341808d2df4e5ca374c42362e872c11b1f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4673124
Auto-Submit: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1174559}
This patch supports sending keys with modifiers in `keyUp` and
`keyDown` action sequences.
crrev.com/c/4654141 supported `keyUp` and `keyDown` for all
keys, but when they are combined, such as:
```
actions().keyDown(kAltKey)
.keyDown('c')
.keyUp('c')
.keyUp('kAltKey)
.send();
```
It's the keyboard driver's (`EventSender` in this case)
responsibility to keep track of the modifier key state, not
the `Widget`'s (which `EventSender` sends events to.)
This patch updates `EventSender` to keep track of the state.
This patch:
* Fixes 3 tests (6 sub tests.)
* Makes a WIP test in crrev.com/c/4679415 pass.
* Turns 1 timeout to a failure. The cause isn't clear but the
test fails at wpt too:
https://wpt.fyi/results/uievents/interface?label=master&label=experimental&aligned&q=keyboard-accesskey-click-event
Bug: 893480, 1462196
Change-Id: If1cf6e0a290c9f060135b2a67322aed3dd559e5a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4680842
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1170356}
This patch implements a short-term solution for `keyUp()` and
`keyDown()` in action sequences. As in crbug.com/893480, the
long-term solution is to move to webdriver, but some tests
need to be fixed before the long-term solution.
This patch does this by following changes:
1. The `testdriver-vendor.js` determines whether it's a key
actions or pointer actions, and dispatch key actions to
`EventSender` instead of `gpuBenchmarking`.
`EventSender` already has logic necessary to implement this,
and it's already used for `send_keys()` testdriver function.
This patch shares the logic with it.
2. `EventSender` has two new functions: `KeyDownOnly` and
`KeyUp`, to support `keyDown()` and `keyUp()` actions
respectively.
Note, `EventSender::KeyDown()` already exists, which sends
both key-down and key-up events. This is currently used by
hundreds of tests, hence the naming above avoids conflicts.
One limitation in this short-term solution is that one action
sequence can't contain both key and pointer actions. From the
test result, there is one such test. Such test is still not
testable with this patch, but this patch turns 43 untestable
tests to testable.
Bug: 893480, 1420675
Change-Id: I6a17b46caefdeb13245bfecb1eb9bd0f28550f7c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4654141
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Weizhong Xia <weizhong@google.com>
Cr-Commit-Position: refs/heads/main@{#1167771}
After layout for pagination, check if the size of the first page is
different from what was specified initially. If it is, relayout with
that page size. This is the same as what PrintRenderFrameHelper does
(i.e. what we do in regular Chrome). However, we will need to rewrite
this when we add support for mixed page sizes, but before we get there,
it's a step in the right direction not to hardcode the page size, and
behave more similarly to regular printing in Chrome.
This should have allowed us to set the default WPT page size to 5 by 3
inches, just like
http://web-platform-tests.org/writing-tests/print-reftests.html says,
but that would break infrastructure/reftest/reftest_match-print.html
(which passes in Gecko), so we need to keep on using 4 by 2 inches for
now.
Update the bug number for one of the test failures, since it turned out
to be unrelated to this issue.
No behavior changes outside running web tests intended.
Bug: 1416181
Change-Id: I809901af7c2a1f8b06947de997dd226722fe8ee7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4654234
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1163637}
To retain the current behavior in print web tests in crrev.com/c/4567866
we kept the magical scaling of 1.3333... there. Although
PrintFrameToBitmap() suggested that it wanted things in CSS pixels (the
parameter is named page_size_in_pixels), we were actually expecting it
to be in points, since Blink would perform that conversion (prior to the
aforementioned CL). So we added a temporary points-to-CSS-pixels
conversion borkery right there in that function.
This CL removes all such temporary conversion hacks, and contains all
the necessary test rebaselines and rewrites.
For WPT print reftests in particular, though, the situation was a bit
different. We were already passing the page size (4 by 2 inches) in
points to PrintFrameToBitmap() (even though the parameter is named
page_size_in_pixels). So now we have to actually pass it in pixels. :)
Multiply the inches by 96 instead of 72, and explain why we use 4 by 2,
and not 5 by 3, for the time being.
A few reftest expectations had to be changed, because the page size has
changed. E.g. for web_tests/printing/multicol-2-pages.html, only 4 lines
(instead of 5) will fit on the first page now.
This also fixes two existing reftests, most likely because of rounding
errors no longer being there.
Only web test behavior changes are intended with this CL.
In detail:
- Legacy web test (web_tests/printing/): The page size is 1.333 times
smaller than before (normally 800 by 600 CSS pixels, instead of 800 by
600 points).
- WPT print tests: No changes.
Bug: 1450167
Change-Id: I9db5a21f4456730575f2e97b127390299c8fb2c6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4643593
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1163438}
This CL implements two of the FedCM automation commands from
https://fedidcg.github.io/FedCM/#automation. This CL does not yet update
the tests to make use of these methods. A followup is required to stop
auto-selecting accounts in tests so that we can reliably get the title
before the UI is dismissed.
This is needed because WPTs run under content_shell, without
chromedriver support.
Bug: 1453691
Change-Id: I0f7765aa012b38d6e5ce73070cb47341af4f57a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4618303
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1162433}
This is a reland of commit 4a964f37d1
The original CL was reverted due to conflicts from a change related to
privacy sandbox attestations being checked in around the same time as
this CL. This CL fixes the conflicts associated with the conflicting
changes. Specifically, it accounts for the fact that an instance of the
attestations class is not tied directly to a PrivacySandboxSettings
object anymore and is now obtained with a different call.
See: https://chromium-review.googlesource.com/c/chromium/src/+/4605397
Original change's description:
> Check reportEvent() destination for enrollment/attestation.
>
> Sites must be enrolled in order to use Privacy Sandbox APIs. This CL
> adds a check for event reporting (both through reportEvent() and through
> automatic beacons) that only lets an event get sent out if the site is
> enrolled.
>
> In order for the fenced frame reporter to perform the check, it needs
> access to the browser context. The context is plumbed through the code
> paths that create the FencedFrameReporter object and stored for later
> use. As a side effect, we no longer need to plumb the AttributionManager
> into the FencedFrameReporter, as we can just get it directly from the
> newly plumbed BrowserContext.
>
> This CL also makes changes so that the check will always return true
> when running in all web tests and in certain browser/unit tests.
>
> Change-Id: I1eca7742c99c81c27c5940fc86b0bef46e2e2711
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4594658
> Reviewed-by: Theodore Olsauskas-Warren <sauski@google.com>
> Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
> Reviewed-by: Shivani Sharma <shivanisha@chromium.org>
> Reviewed-by: Charlie Harrison <csharrison@chromium.org>
> Reviewed-by: Russ Hamilton <behamilton@google.com>
> Commit-Queue: Liam Brady <lbrady@google.com>
> Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1160466}
Change-Id: I85808d5fd11d030d8d8260332073cba88beb112c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4630152
Reviewed-by: Theodore Olsauskas-Warren <sauski@google.com>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Liam Brady <lbrady@google.com>
Cr-Commit-Position: refs/heads/main@{#1161218}
Use CSS pixels where we can, most prominently, in WebPrintParams.
Convert directly from device pixels to CSS pixels. We used to convert
from device pixels to points, then pass this to Blink, and Blink would
convert it to CSS pixels. The fact that this conversion was
taking place wasn't exactly obvious. The values were multiplied by
PrintContext::kPrintingMinimumShrinkFactor, which was documented as a
somewhat mysterious factor, that, according to the documentation, used
to be 1.25, but more recent research had shown that 1.33333 was a better
factor. But there's really nothing magical or heuristic about this.
There are 96 CSS pixels per inch, and there are 72 points per inch.
96/72 = 4/3 ~= 1.33333
Don't expose internal Blink scaling (remove WebLocalFrame::
GetPrintPageShrink()). Blink sometimes scales down content to fit more
content in the inline direction (as an attempt to avoid clipping and
thus losing content). Take care of that internally, which is more
consistent. Blink used to do it internally for web tests
(SpoolPagesWithBoundariesForTesting() in WebLocalFrameImpl), whereas for
printing in actual Chrome, it was done on the outside, by
PrintRenderFrameHelper::PrintPageInternal().
This also improves media query evaluation "for free". We used to perform
some strange conversions in PrepareFrameAndViewForPrint::
ResizeForPrinting(). The input size used to be in points, and then we'd
*divide* the height (but not the width!) by 1.333, and then pretend that
the result was in pixels. Now that "everything" is in pixels, things
will improve automatically, unless we make an effort to prevent it. It's
still not quite right, and this CL isn't about that anyway (added TODO).
Also update the header/footer template. PrintHeaderAndFooter() used to
cancel out scaling, including the internal 1/1.333 (3/4) scaling in
Blink, so that content in headers and footers would appear 1.333 (4/3)
times as large as it should be. This has now been untangled and cleaned
up, so we need to ask for the sizes we actually want to see, rather than
3/4 of that. This includes the options passed to
setupHeaderFooterTemplate(). setupHeaderFooterTemplate() specifies the
page size in pixels, although it was actually passed in points. But that
looked just fine, since everything was accidentally (?) zoomed in by
4/3.
There was some confusion on the web tests side of things.
PrintFrameToBitmap() thinks that it takes a page size in pixels, but
this value was multiplied with 1.333 inside Blink afterwards, so it was
effectively points, not pixels. We need to rebaseline or rewrite quite a
few of the tests before we can remove it, so, for now, keep the magical
1.333 scaling thing for tests. Will follow up with a CL that removes
this and rebaselines / rewrites the tests that need it.
Four tests still need to be rebaselined in this CL, though. The
down-scaling of content inside Blink produces slightly different results
now. Since we're using pixels instead of points, and they are passed as
integer values, we end up with a slightly different aspect ratio, so
that LocalFrame::ResizePageRectsKeepingRatio() doesn't behave exactly
like before. Since this CL fixes some rounding errors, two layout tree
dump tests also need to be rebaselined.
Added a few browser tests, both for crbug.com/1444579 (which was the
main motivation for making this change), and also for crbug.com/1117050
since media query evaluation has improved, because we're now using CSS
pixels.
Two of the new tests are disabled. Since we don't support fractional
page sizes, and round down everything to the nearest integer (e.g.
123.9px -> 123px), content that the author would expect to fit on one
page will fragment. Will deal with this in a follow-up.
Bug: 1444579, 1117050
Change-Id: I076cc9f84591b74925465e364ef2f5f4908bb794
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4567866
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1161059}
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}
Sites must be enrolled in order to use Privacy Sandbox APIs. This CL
adds a check for event reporting (both through reportEvent() and through
automatic beacons) that only lets an event get sent out if the site is
enrolled.
In order for the fenced frame reporter to perform the check, it needs
access to the browser context. The context is plumbed through the code
paths that create the FencedFrameReporter object and stored for later
use. As a side effect, we no longer need to plumb the AttributionManager
into the FencedFrameReporter, as we can just get it directly from the
newly plumbed BrowserContext.
This CL also makes changes so that the check will always return true
when running in all web tests and in certain browser/unit tests.
Change-Id: I1eca7742c99c81c27c5940fc86b0bef46e2e2711
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4594658
Reviewed-by: Theodore Olsauskas-Warren <sauski@google.com>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Shivani Sharma <shivanisha@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Russ Hamilton <behamilton@google.com>
Commit-Queue: Liam Brady <lbrady@google.com>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160466}
ui::SelectFileDialog::SetFactory() is taking ownership of its argument,
either globally leaking or deleting it, so this makes that more obvious.
It also uncovers a spot in PPAPI where fairly egregious ownership issues
exist. Update a comment here but otherwise leave unchanged.
-- Removes a large number of bare `new`.
-- std::make_unique<> needs more specific type information in a few
places that just a bare brace-initialized list.
Change-Id: I3111e009a3afc99ff87bd99ca35f3613255ea6e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4616626
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1158899}
Currently, devtools web tests serve devtools and the inspected page
from the same site. This interferes with the ongoing experiments
that put the same-site tabs in the same process.
This patch makes sure we serve devtools from a different site from
the inspected page. This is more in line with how we run devtools
in production.
Bug: chromium:1444827
Change-Id: I144f6844fcafe496483ac2e3482a789c37b8856a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4574441
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1151681}
std::string_view is special because std::string knows how to integrate
with it. Happily, the STL uses a StringViewLike concept, so just by
adding the implicit conversion, we can now write
str.append(piece) instead str.append(piece.data(), piece.size()).
While small, this change keeps us using safe constructs. Clear these out
so we get a little closer to being able to flag accesses of data() as
unsafe. (That's a long ways off, but let's get the easy stuff out of the way.)
A few places (content/web_test/renderer/blink_test_helpers.cc and
net/test/embedded_test_server/http2_connection.cc) were even wrong as
they used .data() without .size() on a string_view/StringPiece.
Bug: 691162
Change-Id: Ib58e00db5f8c2527908c9e7971d28a0b53e68e65
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4574755
Reviewed-by: danakj <danakj@chromium.org>
Owners-Override: danakj <danakj@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Commit-Queue: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1151252}
Supports numerics in three versions of the js bindings:
- Lite JS Bindings, used by some ChromeOS WebUIs.
- Lite JS Bindings for compile, used by ChromeOS WebUIs for type
checking
- JS module bindings, used mostly in Web Tests.
Bug: 657632
Change-Id: I23de8696ed52abb6cf3af37307a4e6422877e7f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4337119
Commit-Queue: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@google.com>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1141147}
