The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Iee14d10d544e9f0ec046117cc4ec8a55c427adc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5469947
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290838}
When the code was originally written, "mouse lock" was a popular term in
the gaming industry and the PointerLock API didn't even exist. Now that
"pointer lock" is an established term, we are switching our codebase
away from the old term to be consistent with the web platform API:
https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API
There still are some names that aren't renamed in this CL, e.g. enum
values recorded in metrics.
There should be no behavioral changes.
Low-Coverage-Reason: TRIVIAL_CHANGE This is a rename CL
Bug: 1518948
Change-Id: Ib66d87e4919c2570109d7e6755ea91dfc18d42fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5148491
Commit-Queue: Takumi Fujimoto <takumif@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Vincent Scheib <scheib@chromium.org>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: Finnur Thorarinsson <finnur@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1251864}
There are two headers to declare features in content.
- the public one: `content/public/common/content_features.h`
- the private one: `content/common/features.h`.
Unfortunately, most are declared in the public one, despite being used
privately exclusively. This violate the `content/public/` rules. This
patches provides a fix.
Parts of this patch was made programmatically using this script:
https://paste.googleplex.com/6699322946093056, with the following
output: https://paste.googleplex.com/5591288895242240
This patch:
1. Update `docs/how_to_add_your_feature_flag.md` to incentive
developers to the non public versions.
2. Move ~70 features back into the private version.
3. Programmatically update the includes to include the correct
#include header(s).
4. For consistency and minimizing the amount of files modified,
the two headers to use the `features::` namespace.
AX-Relnotes: n/a.
Change-Id: Id9126a95dfbc533d4778b188b659b5acc9b3d9e3
Bug: None
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4836057
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1194718}
Note that the old method is already returning the PrimaryFrameTree so
this patch is just about making that explicit.
Trivial change that renames all test files leaving the production code
for a later patch. That code will need a closer look to make sure that
call sites are really expecting the primary frame tree (note they are
already getting the primary frame tree, so this is just an extra check
for peace of mind).
Keeping the old method around for a while will also prevent this massive
patch from being reverted if an optional try-bot later fails.
Bug: 1251094
Change-Id: Ibc86aedf203013e41e61ede94e6af929f80ee477
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3231330
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Sreeja Kamishetty <sreejakshetty@chromium.org>
Commit-Queue: Carlos Caballero <carlscab@google.com>
Cr-Commit-Position: refs/heads/main@{#935359}
The documentation of ExecJs says:
```
Run a script exactly the same as EvalJs(), but ignore the resulting
value.
```
and developers are using it with this assumption. A big difference is
that EvalJs() is waiting on the promise the resolve, while ExecJs
doesn't.
There are no strong reasons not to wait for the promise to resolve in
both case. Moreover, there are dozen of tests written with an
incorrect assumption about its behavior. They are listed on this patch:
https://chromium-review.googlesource.com/c/chromium/src/+/2644945
This patch aligns ExecJs with EvalJs. It nows waits for the promise to
resolve before returning.
Bug: 1170681
Change-Id: I97e6f199c7d261d8fab2096911a0327d60997338
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2652609
Auto-Submit: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Rouslan Solomakhin <rouslan@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#859712}
The change is mostly mechanical replacing defined(OS_CHROMEOS) with
BUILDFLAG(IS_CHROMEOS_ASH) and GN variable is_chromeos with
is_chromeos_ash with some special cases (For those cases please
refer to http://go/lacros-macros).
The patch is made in preparation to switching lacros build from
target_os=linux to target_os=chromeos. This will prevent lacros from
changing behaviour after the switch.
Bug: 1052397
Change-Id: Ieb265e116ff6ada5e2f99d609ff12fb9f92727e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2534271
Commit-Queue: Yuta Hijikata <ythjkt@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#829687}
The tests in pointer_lock_browsertest.cc were flaky for 3 reasons:
- requestPointerLock being asynchronous
- mouse events being asynchronous
- native mouse events interfering with tests during execution
All the above were addressed in prior CLs.
Bug: 766450
Change-Id: I759ca6c31856fbf1e99a70b4e925a7d5093c50cc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2212978
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Liviu Tinta <liviutinta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#772756}
The tests in pointer_lock_browsertest.cc were flaky for 3 reasons:
- requestPointerLock being asynchronous
- mouse events being asynchronous
- native mouse events interfering with tests during execution
All the above were addressed in prior CLs.
Bug: 766450
Change-Id: I30c9d3df7101be6ccd0686b051b83bfb0754300c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2213103
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Liviu Tinta <liviutinta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#772666}
The tests in pointer_lock_browsertest.cc were flaky for 3 reasons:
- requestPointerLock being asynchronous
- mouse events being asynchronous
- native mouse events interfering with tests during execution
All the above were addressed in prior CLs.
Bug: 766450
Change-Id: I473623338fee3277cb905b17151f80a6468ebb57
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2213107
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Liviu Tinta <liviutinta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#772367}
The tests in pointer_lock_browsertest.cc were flaky for 3 reasons:
- requestPointerLock being asynchronous
- mouse events being asynchronous
- native mouse events interfering with tests during execution
All the above were addressed in prior CLs.
Bug: 766450
Change-Id: Icc977b9c8bbfaba8c322a82ff6388886aee83941
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2212997
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Liviu Tinta <liviutinta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#772227}
The tests in pointer_lock_browsertest.cc were flaky for 3 reasons:
- requestPointerLock being asynchronous
- mouse events being asynchronous
- native mouse events interfering with tests during execution
All the above were addressed in prior CLs.
Bug: 766450
Change-Id: I08ba7c5f34d57a92e24480934cb6d2fc731fd6f4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2213110
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Liviu Tinta <liviutinta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#771923}
The tests in pointer_lock_browsertest.cc were flaky for 3 reasons:
- requestPointerLock being asynchronous
- mouse events being asynchronous
- native mouse events interfering with tests during execution
All the above were addressed in prior CLs.
Bug: 766450
Change-Id: Ic046bce6c81a9bcc8d1f78a5c56506ed959b45ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2213202
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Liviu Tinta <liviutinta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#771844}
This is a step towards doing full IWYU of browser_test.h, which will
have other benefits.
Completely mechanical and already R+ed as part of r765923.
Tbr: sky
Bug: none
Change-Id: Icb7ab728098a6cf29c0920da4b524e96a7c024c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2186411
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#766361}
Include this directly in relevant test files. This lets us convert the
HAS_OUT_OF_PROC_TEST_RUNNER checks in this file and
view_event_test_base.h into #errors, and force people to not even
include this file in files that can't use it.
Bug: none
Tbr: sky
Change-Id: I86626099eb047eb53e8b3611de38ba6bebc01a0b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2136117
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#765923}
requestPointerLock is an asynchronous operation.
Use a promise to properly sync on pointerlock in order to safely check
for correctness.
Bug: 766450
Change-Id: I6df4f4b597807a1c4938e75ccd4b994ba6a1adde
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2177154
Commit-Queue: Liviu Tinta <liviutinta@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#765809}
The test was not waiting appropriately for events to fire. Now it waits for proper events to fire for requestPointerLock, exitPointerLock, mousemove before it checks for the correctness of the operation.
Bug: 766450
Change-Id: Id9f1db83f4555a16a45960f1869680a90c77757e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2158386
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Commit-Queue: Liviu Tinta <liviutinta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#761916}
WebInputEvent::Type and WebTouchPoint::State are adjusted in this change.
This allows us to alias this enumeration to a mojo defined type that
will come in another CL.
No functional changes in this CL, largely completed via sed.
Change-Id: I0657aacf782a437f9432e721bba349f8fdf797e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2159698
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#761210}
Recent changes to pointer lock requests(https://crrev.com/c/2069199)
caused an error in logic which allowed requests made while not in focus
to be able to succeed. This meant that a request made while changing
focus would cause a strange state. I also added an earlier check for
focus so that we error out before reaching the browser.
Bug: 1068339
Change-Id: If706d2a693ca6a9aa2a8cf6c85ed622b429b97fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2138501
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: James Hollyer <jameshollyer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#758382}
The FrameConnectorDelegate is supposed to be an interface which
is implemented by an object supplying platform semantics for a child
frame. The recent change(https://crrev.com/c/2071788) failed to
implement the ChangeMouseLock in CrossProcessFrameConnector and
therefore these calls were not getting to the correct place.
I also added the error handler for the rarely hit
PointerLockResult::kUserRejected error.
Bug: 1062702
Change-Id: I9c6aad9bac455b578b39e2aa086732f69f09fe61
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2116327
Commit-Queue: James Hollyer <jameshollyer@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#756517}
This CL removes more dead BrowserPlugin infrastructure.
Specifically, it remove WebContentsViewGuest, and
RenderWidgetHostViewGuest. It also removes the "guest_view_hack" which
has been in RenderWidgetHostViewMac/Aura since the inception of
BrowserPlugin.
Bug: 533069
Change-Id: Ie6d28ca981d612d3f7bf8f180c615f78d53b7e26
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1943097
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#721497}
