ASCII string literals can be passed as WTF::String directly. WTF also
has existing capabilities for string concatenation and UTF-8 conversion,
and core/ need rely on WebString for neither.
Change-Id: I201a3649dbc77aca789989e6331c7c3774cfa78e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5834582
Auto-Submit: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350488}
This reverts commit 74cedcdf58.
Reason for revert: [Build gardener] Suspected to cause persistent ChromeVoxBackgroundTtsTest.Preprocess failures on https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20ChromiumOS%20MSan%20Tests.
First failing build:
https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20ChromiumOS%20MSan%20Tests/45863
Sample output:
[ RUN ] ChromeVoxBackgroundTtsTest.Preprocess
../../chrome/test/base/ash/extension_js_browser_test.cc:201: Failure
Failed
Failed: RUN_TEST_F("ChromeVoxBackgroundTtsTest","Preprocess")
AssertionError: expected 'This is the ? symbol and this is the pound symbol.' to equal 'This is the pound sterling symbol and this is the pound symbol.'
at assertEquals (file:///b/s/w/ir/out/Release/test_data/chrome/browser/resources/chromeos/accessibility/chromevox/background/tts_background_test.js:11432:15)
at ChromeVoxBackgroundTtsTest.<anonymous> (file:///b/s/w/ir/out/Release/test_data/chrome/browser/resources/chromeos/accessibility/chromevox/background/tts_background_test.js:17562:3)
...
gen/chrome/browser/resources/chromeos/accessibility/chromevox/background/tts_background_test-gen.cc:71: Failure
Value of: RunJavascriptTestF( true, "ChromeVoxBackgroundTtsTest", "Preprocess")
Actual: false
Expected: true
Original change's description:
> recorder: Add a11y labels on main page
>
> Add accessibility labels on components on main page.
>
> Bug: b:327537848
> Test: Use Chromevox to navigate in main page
> Change-Id: If3cc91c255fbb22865fa5e931fb35767fc0060ea
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5828681
> Reviewed-by: Pi-Hsun Shih <pihsun@chromium.org>
> Commit-Queue: Kam Kwankajornkiet <kamchonlathorn@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1350243}
Bug: b:327537848
Change-Id: Ifba98404b393a856981c1c53df233fc0c234c286
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5832812
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350486}
This will be needed soon as PositionArea::AlignJustifySelfFromPhysical
will start returning non-default overflow alignment.
There should be no behaviour change.
Change-Id: If4bba1585b3fa6c6f57de1b77485571f385eb628
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5834625
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350484}
Before: https://screenshot.googleplex.com/5ecD4CXT8fd3Ec2
After: https://screenshot.googleplex.com/9Da7ox4QWCKEq63
This bug is something kmg@ noticed while testing FL settings. After
some digging, I discovered that we are currently mistakenly mapping
SiteSettingSource in C++ to ContentSettingProvider in TS. Miraculously,
some of these values are the same (e.g. 'policy') and therefore work.
However 'supervised_user' is not one of those miraculously working
values. I am also removing obsolete values that have no source in the
C++ or have no handling in WebUI (these were mostly added in crrev/c/1838652, with no reason stated for doing so).
Note that this does not fix b/360877241
Change-Id: I1e909434cfcc7581b487dfe1b898c08b4dc3e334
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5826073
Auto-Submit: Fiona Macintosh <fmacintosh@google.com>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Commit-Queue: Martin Šrámek <msramek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350478}
- There is a small settings icon in the corner of each notification.
- This is not present in any existing battery notifications, so it
shouldn't be in the Battery Saver notification either.
Change-Id: I1342c5de27e15166eb98ee1b0c8827c6de789a07
Bug: b:361616138
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5834274
Commit-Queue: Michael Wojcicka <mwoj@google.com>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350477}
ResettingConnectorCache calls `clear()` on the connector properties
vector and then emplaces several new connector property entries.
Unfortunately, connector properties contains two primitive fields (`id`
and `connection`) with no initializer, so default constructing them
leaves them uninitialized. The test explicitly sets `id` but forgets to
do the same for `connection`.
This ends up manifesting as a use-after-destroy because:
- Calling clear() destroys the entries
- However, clear() makes no guarantees about what happens to the backing
store
- So the emplace_back() calls end up constructing new properties using
the same backing store, leaving `id` and `connection` uninitialized.
The fix is to initialize `connection`.
Bug: 40222690
Change-Id: Iac3bb6d6712bd784fb1eb204f6e1caac1b5eec22
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5825018
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Gil Dekel <gildekel@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350476}
ax_dump_tree falls through to a "NOT REACHED" check when it shouldn't
(it's valid for an AXUIElement to have no point). The same problem
affects ax_dump_events.
Test: out/default/accessibility_unittests \
--gtest_filter="AXElementWrapperMacTest*"
Bug: 363356533
AX-Relnotes: Fixes a CHECK in ax_dump_tree and ax_dump_events.
Change-Id: I4dafcf59fa7dde454eeb8ef4d7b97d918da3be98
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5827702
Reviewed-by: David Tseng <dtseng@chromium.org>
Commit-Queue: Jayson Adams <shrike@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350475}
Destroying BrowserTabsModelController unregisters itself as an observer
of MultideviceSetupClient and BrowserTabsModelProvider, so it must not
outlive either.
Bug: 40222690
Change-Id: I19d2ea07cbea1dba24592f596452bc3717edb52c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5825017
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Jon Mann <jonmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350474}
See bug for detailed context/motivation. Different scenarios seem
to have quite different profiles and performance characteristics.
They have been grouped into broad categories mainly so that we can
distinguish the user wanting to see overview vs when overview
mode is started automatically as part of informed restore.
Current suspicion from looking at Chrometto traces is that
the higher latency buckets for the overarching
Ash.Overview.Enter.PresentationTime metric might be attributed
to informed restore because it happens shortly after login
(during which the cpu's workload is extremely high). In other
words, the latency from just pressing the overview button may
not be as bad as we think. This is just a theory though.
Bug: b:362822878
Change-Id: I4adc2b82553510232ab925651085ea41b402bc4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5827872
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Eric Sum <esum@google.com>
Reviewed-by: Jimmy Gong <jimmyxgong@chromium.org>
Reviewed-by: Sammie Quon <sammiequon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350468}
The feature was launched with "delay: 30 min" and "require interaction:
true", so I have removed the "schedule on view" code path and unit test.
Bug: 40895131
Change-Id: Ia2b32fbb7113de6463dbcfca542147dd5b1bfdf6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5800937
Reviewed-by: Jian Li <jianli@chromium.org>
Commit-Queue: Ian Wells <iwells@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350466}
minigbm amdgpu backend is switching from dri to vulkan.
BUG=b:292148713
TEST=tast.video.PlaybackPerf.* and
tast.webrtc.RTCPeerConnection.h264_oopve_verify_hw_enc on skyrim
Change-Id: I4ed6b51deb31af5da5de14ae06b8bb0d545e4e2d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5794057
Commit-Queue: Chia-I Wu <olv@google.com>
Reviewed-by: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350464}
When installing the application under test for CECA integration
tests, also copy the ASAN dylib. This will allow dylib lookup to
succeed for the application under test.
Fixed: 364289343
Change-Id: Ic492932806486275382bbf6cc7e826790959a475
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5833213
Reviewed-by: Joshua Pawlicki <waffles@chromium.org>
Commit-Queue: Noah Rose Ledesma <noahrose@google.com>
Cr-Commit-Position: refs/heads/main@{#1350460}
SwiftShader was re-enabled on ARM Macs. Update the WebGL web test
expectations from context creation failure to the baseline expected
output.
Bug: 40277080
Change-Id: If3eea92737f93da206979ccd2699e34134ad1ec4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5830989
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350459}
GpuProcess_no_swiftshader_for_webgl_without_flags tests different
permutations of flags for enabling SwiftShader which are not all
available on arm Macs where SwiftShader is disabled for security
reasons.
Bug: 40277080
Change-Id: Ida6bcdb26711451a565fe653ffcfe2ae056e583c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5833665
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350458}
We want to retry android PGO benchmark test multiple times until it
passes to ensure profiles are generated in each build (the freshness
of the profiles are important to PGO).
Bug: b/332696096
Change-Id: I16d7e1d3f8c905623f355caf743bd6a001751107
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5818971
Commit-Queue: Zhaoyang Li <zhaoyangli@chromium.org>
Reviewed-by: Peter Wen <wnwen@chromium.org>
Reviewed-by: John Chen <johnchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350454}
We're seeing a number of different stack traces for this crash but the
commonality is that they all occur in the write callback and that
callback is scheduled in net::UDPSocketWin::Core::WatchForWrite.
Another interesting tidbit is that we don't see this crash signature
on Linux. I looked into the differences between the //net impls for
UdpSocketWin and UdpSocketPosix and found that UdpSocketWin has to
post the callback to an overlapped IO thread via a core_ object which
isn't tied to the lifetime of the socket_, meaning that when we call
close on socket_, the write callback can still be executed.
Given this, I am going to update UdpSocketFactory to use a WeakPtr
which should prevent the problem. I don't think there are any
threading problems but I'm also adding some DCHECKs and a
thread_checker_ so we can look for them in debug builds if
needed.
Bug: 364344011
Change-Id: I5c39b51ff8a285694b772b8b895eec2cf1a25adc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5833539
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350452}
This GN targets is being used by various other GN targets, including
unit_tests, browser_tests and interactive_ui_tests.
This CL factors it out, instead of duplicating its sources around
different targets.
No behavior change intended.
Preparation CL to modularize the rest of //c/b/ui/commerce.
R=erikchen@chromium.org
Bug: 36267596
Change-Id: Ie6dc598f6d7cef94519432ee5ab25cd6e5a3d9f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5831436
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350451}
Move OpenOptionsPage to the ExtensionsBrowserWindow interface for
future porting and implement the ExtensionTabUtil function in terms of
that.
Do the same for BrowserSupportsTabs (now called SupportsTabs since it's
already on a "browser"-named object).
It seemed odd that this function allows a null Browser* input parameter
and the implementation that forwards it makes this more awkward. The few
callers of this function were implemented for possibly null Browser*
input so this function no longer accepts null pointers. Updates some
caller code and comments to reflect this fact and to clarify the
slightly surprising ability for GetTabById to return a null browser in
the success case.
Bug: b/361838438
Change-Id: I62c18f26d7d1f135f580a25a5bbd7e17fd199608
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5828473
Commit-Queue: Brett Wilson <brettw@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350450}
Renames the ExtensionTabUtil::GetDefaultTab function to be GetActiveTab
to match the Browser window function (I didn't actually know what a
"default" tab might be).
Pippes the implementation of this function through the
ExtensionBrowserWindow interface for future porting.
Bug: b/361838438
Change-Id: I26b68cbcae7336864d6067b2e764f06090998693
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5828472
Commit-Queue: Brett Wilson <brettw@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350447}
