ContentBrowserTest::SetUpCommandLine() is actually not defined. Calls to
this method ends up running BrowserTestBase::SetUpCommandLine(), which
is always going to be empty. Since there is no point in calling this
method, delete all the callers from SetUpCommandLine() overrides. When
the override becomes empty, delete the override altogether.
Make a note of this in the comments in content_browser_test.h. Also fix
some lint errors along the way.
Change-Id: I81f263286d72ebdab68dfd9575ad4cf2b6378a3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5691227
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1325736}
The call stack for keyboard lock is as follows (called from bottom to
top):
KeyboardLockController::RequestKeyboardLock()
Browser::RequestKeyboardLock()
WebContentsImpl::RequestKeyboardLock()
RenderWidgetHostImpl::RequestKeyboardLock()
KeyboardLockServiceImpl::RequestKeyboardLock()
blink::KeyboardLock::lock() (navigator.keyboard.lock())
Before this CL, whether to resolve/reject the lock() promise was
determined by WebContentsImpl and below in a synchronous manner,
without the input from KeyboardLockController. This CL allows
KeyboardLockController to resolve/reject the promise asynchronously,
which will allow it to show a permission prompt for keyboard lock.
A permission prompt will be added in a future CL.
Bug: 324147495
Change-Id: I544d77bc1361162705f6a7b0709e4ab35cccc9c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5399458
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Takumi Fujimoto <takumif@chromium.org>
Reviewed-by: Mike Wasserman <msw@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1281659}
This reverts commit 1abc874e14.
Reason for revert: Causing resize janks crbug.com/1506034
Original change's description:
> Remove `will_cause_resize` from WebContents::ExitFullscreen()
>
> This CL fixes a regression on Mac that if a web page enters the tab
> fullscreen mode and then exits fullscreen by system controls (keyboard
> shortcuts or window control buttons), the page becomes
> fullscreen-in-tab. This issue was caused by the browser not sending
> a resize message to the renderer after browser has exited fullscreen.
> Specifically, the resize message isn't sent because the browser
> is told that there will by another resize event and skips this message
> when `will_cause_resize` is True.
>
> This issue can be solved by removing the `will_cause_resize` parameter
> from WebContents::ExitFullscreen() so that a resize message is sent
> every time this function is called to exit fullscreen.
>
> The `will_cause_resize` flag was initially added to restore the
> scroll position when toggling fullscreen mode crrev.com/1488653002
> However, the scroll restoration was later removed because of its
> complexity by crrev.com/c/1195714 and this flag wasn't cleaned up
> at that time.
>
> There are several places where a True value is passed to
> `will_cause_resize` i.e. exit fullscreen when showing a printer pop
> up dialog. These use cases shouldn't be affected by having another
> page resize.
>
> Bug: 1469462
> Change-Id: I5c522121ea6eae847c2816f0239ff8f0fa97f8ae
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5031312
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Commit-Queue: Muyao Xu <muyaoxu@google.com>
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Reviewed-by: Kevin McNee <mcnee@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1224651}
Bug: 1469462
Change-Id: Id5ed791ea63ff9e9c0fb07eaec07d1a999f4cfcf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5074445
Reviewed-by: Kevin McNee <mcnee@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Muyao Xu <muyaoxu@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1231733}
This CL fixes a regression on Mac that if a web page enters the tab
fullscreen mode and then exits fullscreen by system controls (keyboard
shortcuts or window control buttons), the page becomes
fullscreen-in-tab. This issue was caused by the browser not sending
a resize message to the renderer after browser has exited fullscreen.
Specifically, the resize message isn't sent because the browser
is told that there will by another resize event and skips this message
when `will_cause_resize` is True.
This issue can be solved by removing the `will_cause_resize` parameter
from WebContents::ExitFullscreen() so that a resize message is sent
every time this function is called to exit fullscreen.
The `will_cause_resize` flag was initially added to restore the
scroll position when toggling fullscreen mode crrev.com/1488653002
However, the scroll restoration was later removed because of its
complexity by crrev.com/c/1195714 and this flag wasn't cleaned up
at that time.
There are several places where a True value is passed to
`will_cause_resize` i.e. exit fullscreen when showing a printer pop
up dialog. These use cases shouldn't be affected by having another
page resize.
Bug: 1469462
Change-Id: I5c522121ea6eae847c2816f0239ff8f0fa97f8ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5031312
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Muyao Xu <muyaoxu@google.com>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1224651}
Removing reliance on EXECUTE_SCRIPT_USE_MANUAL_REPLY forces the
JavaScript to be written in terms of promises, which makes the code
less bug-prone since double-sends are systematically prevented (see
https://crrev.com/c/4318742 for an example bug that would have been
prevented by this).
There are still more usages, especially under content/browser/webrtc,
but those removals are not as mechanical and will be attempted in
followups.
Bug: 1423407, 1422660
Change-Id: Ib8f153da50f0bd3e2d09e00615973264dc3214d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4332196
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Auto-Submit: Chris Fredrickson <cfredric@chromium.org>
Commit-Queue: Chris Fredrickson <cfredric@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1122508}
This basically homogenizes the way platform-agnostic KeyboardLock
content browser tests are disabled in currently unsupported platforms.
Fixed: 1414629
Change-Id: I776384adbb26ca2e9efd13f2f1dc8956e7761b57
Cq-Include-Trybots: luci.chromium.try:linux-x64-castos
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4240688
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Auto-Submit: Nick Yamane <nickdiego@igalia.com>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1105361}
This CL converts the remaining usages of the DOMMessageQueue default
constructor in content_browsertests to the one that takes in a
WebContents instance. The former listens for messages from all
WebContents instances via a notification, while the latter observes the
passed-in WebContents instance to listen for messages from that
instance. We are trying to eliminate the former entirely as part of the
elimination of NotificationService.
The conversions are for the most part straightforward; the one
exception is site_per_process_unload_browsertest.cc, in which we need
to catch a WebContents instance created via a popup to be able to listen
for messages that occur in that instance.
Bug: 1174774
Change-Id: Ieaf7d2811282e2a3c0c7dbbe95c58d2c7aeff20c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3635781
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1001976}
This replaces DISALLOW_COPY_AND_ASSIGN with explicit constructor deletes
where a local script is able to detect its insertion place (~Foo() is
public => insert before this line).
This is incomplete as not all classes have a public ~Foo() declared, so
not all DISALLOW_COPY_AND_ASSIGN occurrences are replaced.
IWYU cleanup is left as a separate pass that is easier when these macros
go away.
Bug: 1010217
Change-Id: Iea478401b7580682c7b9f195f7af9cbbdb6ce315
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3167292
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#923194}
'--ignore-certificate-errors' is bad, because its behavior is not
plumbed correctly everywhere. As a result, its behavior is different
from using a real SSL certificate.
For tests that need to use multiple distinct sites (and not
just different origins), using either MockCertVerifier or
the net::EmbeddedTestServer::CERT_TEST_NAMES can allow multiple
distinct sites to talk to the test server.
Currently folks, are copy-pasting existing tests with
"ignore-certificate-errors". It would be lovely to update existing test
so that folks can start copy-pasting the "good" way instead.
This patch updates:
keyboard_lock_browsertest.cc
Bug: 1236525, 1124775
Change-Id: I3117219d44b7132a9c5c48628b88096399e4a47f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3074882
Auto-Submit: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#909274}
This new clang-tidy check complains when param names /*in_comments=*/
don't match up with the actual parameter name they're being passed to.
Sometimes this is benign, other times, actual bugs are found.
Bug: 1136209
Change-Id: I9802951e5f8d4d77d0c0ae2a3f69134f93b548df
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2459427
Reviewed-by: Bo <boliu@chromium.org>
Commit-Queue: George Burgess <gbiv@chromium.org>
Cr-Commit-Position: refs/heads/master@{#815685}
WebContents has both IsFullscreenForCurrentTab() and IsFullscreen().
It really only needs one. Consolidate them both into IsFullscreen().
Bug: 1100727
Change-Id: I3c578653089979b8dee9045f0d6b441cda975ed2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2275148
Auto-Submit: Avi Drissman <avi@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#784135}
Check for permission on cross-screen fullscreen requests.
Do not prompt users, fall back to the current screen on failure.
Plumb the requesting RenderFrameHost into FullscreenController.
(needed to make the appropriate origin-specific permission check)
Remove the redundant WebContents args; rely on RenderFrameHost.
Bug: 1080690
Change-Id: I8ec80e8b1f1f64ad2de1f936f4656d41a6e8e9d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2203268
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Commit-Queue: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#773250}
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}
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}
In order to remove the dependency, the web_fullscreen_options.h file was moved
to third_party/blink/public/common/fullscreen. Since the file is no longer in
the public/web/ directory we are also renaming it to fullscreen_options.h (and
the struct defined in it to FullscreeOptions).
Bug: 1008303
Change-Id: If96a8263b3bb696931ce9af4846f3d6dcbc40698
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1852288
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#705577}
This change removes:
keyboard-lock-api
and assigns:
system-keyboard-lock
and removes backing features & tests for the former.
Bug: None
Change-Id: I4fe8fa3aeef65e2996e0091d557182af9fa6e565
Reviewed-on: https://chromium-review.googlesource.com/c/1477790
Reviewed-by: Joe Downing <joedow@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Auto-Submit: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633332}
Per discussion with API owner, we want the behavior for invalid
params to be a bit stricter. Prior to this change, if someone
called the API with at least one valid DomString, then we would
allow lock to be set. This made sense when we were translating
the key_codes param into native key codes (where we couldn't
determine the difference between 'invalid for this platform' and
'invalid key for all platforms'. Now that we use DomCodes, we
can do better validation.
The second change is to cancel any current keyboard lock requests
if the API is called with invalid params. The scenario here
involves lock() being called correctly (request is registered) and
then a second lock call being made w/ invalid params. Since we
reject the promise in this case, it didn't make sense to keep the
lock request since the intention by the caller was to override the
initial call. In practice, we don't think this will occur often
but it is a case we wanted to handle better.
BUG=680809
Change-Id: I0ca54cca262761133739ab1d43f22e219792ca7c
Reviewed-on: https://chromium-review.googlesource.com/1099762
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Gary Kacmarcik <garykac@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567800}
These tests are similar to the tests in the content layer, however
these test exercise Chrome E2E instead of using stubs.
BUG=680809
Change-Id: I371d1cdec025517634e62b7ee4cde674c480307c
Reviewed-on: https://chromium-review.googlesource.com/1068122
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563038}
Previously the KeyboardLockServiceImpl would silently fail if the
keyboard lock request failed in some cases (we returned an error
for some scenarios but not all).
This change will ensure that if the keyboard.lock() promise succeeds,
the request was registered successfully.
BUG=680809
Change-Id: I65228603592a871173e6df4a1c265b14fc6a6d8f
Reviewed-on: https://chromium-review.googlesource.com/1066699
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Gary Kacmarcik <garykac@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560726}
This CL implements tests for a couple of TODOs that arose during the
initial code review for my content layer changes for this feature.
During implementation I found an issue where we weren't clearing
KeyboardLock during navigation, that now works correctly.
A big portion of this change involves codifying the behavior between
iframes and the KeyboardLock feature. I haven't written many of
these tests before so I'd like to make sure that the tests I have
are set up correctly, testing what I think they are testing, and
the behavior I have codified is reasonable.
BUG=680809
Change-Id: Ief1fbfef48d396f4df72319bb5bb61120033eada
Reviewed-on: https://chromium-review.googlesource.com/1041137
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557249}
Now that all desktop platforms have a browser-level implementation
for keyboard lock, it is time to remove the platform restriction
for the keyboard lock BrowserTests.
BUG=680809
Change-Id: Iad4ddea988069a73dd6cb31683a3a2086c753c47
Reviewed-on: https://chromium-review.googlesource.com/1042542
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555880}
Created a java side mirror object to the class that can be parceled
into an intent so that it works with the FullscreenActivity code.
Change TabObserver from onToggleFullscreenMode to
onEnterFullscreenMode/onExitFullscreenMode so that we could pass the
FullscreenOptions around.
This change does not have any behavior changes as of yet it is just
plumbing passing options around.
BUG=829937
Change-Id: I8599df0e155de78704d70dd22f886cd94f68d6ff
Reviewed-on: https://chromium-review.googlesource.com/1030837
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555125}
This change includes the integration of the MacOS KeyboardHook impl in
the RenderWidgetHostViewMac and RenderWidgetHostViewCocoa classes.
RWHVMac handles the lock/unlock calls from RenderWidgetHostImpl and
forwards them to RWHVCocoa which handles the events and input routing.
The RenderWidgetHostViewMac and RenderWidgetHostViewCocoa integration
follows the same pattern I used for RenderWidgetHostViewAura and
RenderWidgetHostViewEventHandler. The main difference between this impl
and the Aura impl is that there is a bridge class between RWHVMac and
RWHVCocoa (RenderWidgetHostViewNsBridgeView).
BUG=680809
Change-Id: I524c98c059ae4883bf597704c326b5a0055f1212
Reviewed-on: https://chromium-review.googlesource.com/989618
Reviewed-by: ccameron <ccameron@chromium.org>
Reviewed-by: Nick Carter <nick@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551491}
The previous KeyboardLockService implementation always returned success
even when no KeyboardLock request was registered due to an error. This
CL adds errors for two known error conditions which are now communicated
back to javascript by rejecting the promise. The messages passed are
meant to help developers as they are building their website, they are not
something that can/should be used post-development (i.e. they represent
unrecoverable errors).
BUG=680809
Change-Id: I7748d0f0c7b8688b4e945e6aa349d75b2a9757ca
Reviewed-on: https://chromium-review.googlesource.com/1003216
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Gary Kacmarcik <garykac@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549716}
This CL integrates the KeyboardLock feature into the Chrome UX layer.
Integrating in the ExclusiveAccessManager allows fine grained control
over when KeyboardLock is activated (for instance we want keyboard lock
activated in tab-initiated fullscreen, but not in browser or content
fullscreen. The FullscreenController provides that nuanced level of
control for us.
Also, Keyboardlock should only be available to one
tab at a time which is conceptually the same as Fullscreen and
PointerLock.
Lastly, we need to integrate KeyboardLock logic into
the mechanism used for exiting fullscreen and displaying the exit
fullscreen instructions/bubble. Future CLs will add an animated
exit UX which is tied to the press and hold gesture, and a rapid
tap 'panic' timer which will reshow the exit instructions (these
two behaviors were suggested as part of the UX design process).
I have some initial browsertests for this feature however I have
not added interactive browsertests yet as I would like to get
feedback on the implementation before adding additional tests.
I will add those in a follow-up CL if this impl looks good.
BUG=680809
Change-Id: I6588367875934b59ba979cef65a73707c3d85320
Reviewed-on: https://chromium-review.googlesource.com/989021
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Yuri Wiitala <miu@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Nick Carter <nick@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549230}
This change completes the KeybaoardLockServiceImpl class and hooks it
into the RenderWidgetHostImpl class.
RenderWidgetHostImpl is responsible for tracking the keys requested
to be locked, forwarding the request to WebContentsImpl, handling
the response from WebContentsImpl once the UX is fullscreen, and
then calling into the RenderWidgetHostView impl to actually request
KeyboardLock.
WebContentsImpl tracks the RenderWidgetHostImpl instance which has an
active KeyboardLock request. It also calls back into that instance
once tab-initiated fullscreen is entered/exited. Note that there are
two other approaches I could have taken here: I could have used a
WebContentsObserver class or I could have pushed this logic up
into the chrome layer (ExclusiveAccessManager related class). I
chose the current approach as the logic needed for calling down to
the RenderWidgetHostImpl class is simple and only needed in a few
places.
RenderWidgetHostView is the class which will handle platform
specialization for the KeyboardLock request. I've implemented this
logic for Aura in this CL, macOS will be completed in a follow-up.
My next CL will integrate KeyboardLock into the chrome layer and
implement ESC key handling and UX string display. Also to be added
are some browser tests for this functionality. These will be
required before we enable this functionality by default.
BUG=680809
Change-Id: I703d1ba27592943fff80432303583499d789a2ec
Reviewed-on: https://chromium-review.googlesource.com/939535
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Nick Carter <nick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545096}
