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}
With RenderDocument, cross-document navigations will use new
RenderFrameHosts (and RenderViewHosts, RenderWidgetHosts, etc for
main frame navigations). This CL updates some tests in
content_browsertests that didn't expect those changes.
Bug: 936696
Change-Id: Ia43799aaae9f50b7ff9c3221982b622d76698d14
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4349554
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1120489}
This is a no-op change to /content/browser to update all callers of
WaitForFirstYieldAfterDidStartNavigation and WaitForNavigationFinished
to check for success. Failure could be due to a test timeout or other
error in which case we should stop the test. Proceeding further with
the test will just produce confusing output.
The return values will be marked `[[nodiscard]]` in a follow-up
change.
This CL was uploaded by git cl split.
R=altimin@chromium.org
Bug: 1403181
Change-Id: Ifc67145b50e5befbd07e3c62878baf840f21e56b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4122187
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Fergal Daly <fergal@chromium.org>
Auto-Submit: Fergal Daly <fergal@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1093632}
Turns out there's a lot of includes, so these will have to be removed
before deleting the implementation of the task runner handles.
To allow the deletion of the task runner handle headers, add
the sequenced/thread task runner handles where they are used in
the codebase with scripts.
This was done with an automated change, with a few touchups afterwards.
The code for the mass-refactor changes are here:
python:
https://paste.googleplex.com/5534570878337024
shell:
https://paste.googleplex.com/6466750748033024
In terms of touchups:
- add sequenced/thread task runner handles to
the third_party/blink/public/DEPS, because multiple files were using
it transitively anyways.
- rewrite certain parts of the codebase which used
ThreadTaskRunnerHandles instead of CurrentDefaultHandles.
- fix a compile issue with forward-declaration in
extensions/browser/extension_file_task_runner.h.
AX-Relnotes: n/a.
Bug: 1026641
Change-Id: I737ef32aee4e77c21eaa3a2bdc403a28322cf1b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4133323
Owners-Override: Gabriel Charette <gab@chromium.org>
Commit-Queue: Sean Maher <spvw@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1090532}
Sequential focus should start where the page was scrolled to. The
text fragment can have highlights further down the page so setting it
for each highlight means that focus may be well outside of the viewport
which may be surprising for users.
Change-Id: Ib7e6668c71a7b4d5790ce4742e42c219202cb4c7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3633948
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Jeffrey Cohen <jeffreycohen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1005418}
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}
Tests that requires a document to not be bfcached are still valid even
when BFCache is enabled by default, so updating the comment for
TEST_ASSUMES_NO_CACHING that implies these tests are invalid.
Also renames TEST_ASSUMES_NO_CACHING to TEST_REQUIRES_NO_CACHING to be
more intentional (previously it was used to update existing tests with
outdated assumptions).
Change-Id: I4c54dc61177d7eaedeb18488000adf59a893612a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3271970
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Owners-Override: Alexander Timin <altimin@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#961186}
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}
Links opened from mail.google.com for example have the referrer set to
google.com. This leads to recording the link open source as being a
search engine even if it's not.
The reason is in two parts:
1- It seems the requestorOrigin is accurate in more case, so moving to
using that
2- Client-side redirects mess these up. We'll consider all cases with
client-side redirects to not come from search engine. Tested it on
major SEs and they did use client redirects.
Bug: 1256789
Change-Id: Ibad2d4a14ca6c05efa7b59c9d4396d1f3b3c907a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3205071
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: sebsg <sebsg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#932684}
The failing pattern was using RunUntilInputProcessed followed by
checking RenderFrameMetadata::is_scroll_offset_at_top.
RunUntilInputProcessed forces the renderer to generate a new frame and
waits until that frame is presented by the Viz process. However, the
renderer sends the RenderFrameMetadata to the browser at the same time
as it submits a compositor frame. If the Viz process displayed the
compositor frame before the browser processes processes the
RenderFrameMetadata message, RunUntilInputProcessed will be unblocked
before the metadata is updated, leading to the flake.
This CL replaces uses of is_scroll_offset_at_top by simply reading the
scroll offset via JS.
Bug: 1239636
Change-Id: I3cfff49151f6ce8e1dae9e85f2592acab84ed5af
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3201694
Reviewed-by: Bo <boliu@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#927710}
Previously we will only do proactive BI swap if the destination URL is
HTTP/HTTPs. However this isn't really needed because we want to do
proactive BI swap to cache the previous page, instead of the
destination page. Since the contents of the destination page shouldn't
affect the bfcache eligibility of the previous page, this CL removes
the aforementioned check, and updates tests that do not expect BI/RFH
swap on navigations to about:blank, etc.
Change-Id: I46282c7665124b80bae663c80bdd5c1fa625d7b3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3014135
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#899867}
This CL lifts the restriction on text fragments in the specific case of
a same-document navigation initiated by an origin that's same-origin
with the current document. In this case, the two documents already have
full access to each other's content so text fragments present no risk.
Enabling them allows using anchor links to text-fragments on the current
page as well as allowing coordinating origins to pass a text-fragment
into an iframe.
To do this, we update DocumentLoader's |is_same_origin_navigation_|
member on same-document navigations (and we rename it to be more
specific that the initiator is same-origin or browser).
We also make another small adjustment in allowing text fragments to be
invoked on replacement navigations (e.g. location.replace) which don't
create a new history entry. This was simply an unintentional omission in
the implementation.
Change-Id: Id82f46294b87d12d6a7355e0f7e4936e7fae75d6
Bug: 1198668
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2811999
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Nicolás Peña Moreno <npm@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#875755}
The Paint Holding Cross Origin feature extends Paint Holding to most
navigations. Paint Holding defers the first commit of rendering
data from the main thread to the compositor until after First
Contentful Paint, or a 500ms timeout, has occurred.
From a test perspective, the most important change is related to input.
We drop all input when not updating the document lifecycle and while
deferring the commits. Many tests expect to navigate and then
immediately process input, and these tests timeout or otherwise fail
with Paint Holding.
This is a partial reland of
https://chromium-review.googlesource.com/c/chromium/src/+/2368282 with
just the various browser and ui test changes. Some switch setup
has been expanded from ChromeOS to all platforms, and some additional
tests now have changes. This is as a result of the original patch
generating failures on non trybot builders.
The goal is to make re-landing and future potential reverts less onerous.
Bug: 1120158
Change-Id: I97a7d7574ff3f33ad011682762c0b616f51c6d5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2773991
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#865581}
This reverts commit 7aa2449e71.
Reason for revert: This may causes multiple flaky tests:
Windows:
https://ci.chromium.org/ui/p/chromium/builders/ci/Win%207%20Tests%20x64%20(1)/78657/overview
Linux:
https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Ozone%20Tester%20(X11)/28133/overview
Original change's description:
> Enable Paint Holding Cross Origin for tests
>
> The Paint Holding Cross Origin feature extends Paint Holding to most
> navigations. Paint Holding defers the first commit of rendering
> data from the main thread to the compositor until after First
> Contentful Paint, or a 500ms timeout, has occurred.
>
> From a test perspective, the most important change is related to input.
> We drop all input when not updating the document lifecycle and while
> deferring the commits. Many tests expect to navigate and then immediately
> process input, and these tests timeout or otherwise fail with
> Paint Holding.
>
> Three strategies have been employed to address this:
> - For many tests it is sufficient to add text to the html content
> so that First Contentful Paint is reached upon load and commits
> begin. This works well for most cases but unfortunately the
> linux_chromeos_rel bot is still flaky, probably due to slower loading.
> - Some tests just need to wait for hit test data, using
> WaitForHitTestData
> - In other cases we allow early input using the blink flag.
>
> Test coverage for Paint Holding is provided by essentially all
> tests that use input or require a rendered result, so there is
> little concern about using the early input flag in a few test suites.
>
> This change may cause increased flakiness, particularly on the
> linux-chromeos-rel bot and Android. Please assign flakiness bugs
> to schenney@ and ping if necessary.
>
> Bug: 1120158
> Change-Id: Ief45735c5bdb4d48d6554dcfc12e3b621355e080
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2368282
> Reviewed-by: Clemens Arbesser <arbesser@google.com>
> Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
> Reviewed-by: Evan Stade <estade@chromium.org>
> Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
> Reviewed-by: Bo <boliu@chromium.org>
> Reviewed-by: Owen Min <zmin@chromium.org>
> Reviewed-by: Eric Willigers <ericwilligers@chromium.org>
> Reviewed-by: Tommy Martino <tmartino@chromium.org>
> Commit-Queue: Stephen Chenney <schenney@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#864725}
Bug: 1120158
Change-Id: Ia1c24c7b2be34bf0a8f7a5ac72ecb692636d4c6b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2775893
Auto-Submit: Owen Min <zmin@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#864779}
The Paint Holding Cross Origin feature extends Paint Holding to most
navigations. Paint Holding defers the first commit of rendering
data from the main thread to the compositor until after First
Contentful Paint, or a 500ms timeout, has occurred.
From a test perspective, the most important change is related to input.
We drop all input when not updating the document lifecycle and while
deferring the commits. Many tests expect to navigate and then immediately
process input, and these tests timeout or otherwise fail with
Paint Holding.
Three strategies have been employed to address this:
- For many tests it is sufficient to add text to the html content
so that First Contentful Paint is reached upon load and commits
begin. This works well for most cases but unfortunately the
linux_chromeos_rel bot is still flaky, probably due to slower loading.
- Some tests just need to wait for hit test data, using
WaitForHitTestData
- In other cases we allow early input using the blink flag.
Test coverage for Paint Holding is provided by essentially all
tests that use input or require a rendered result, so there is
little concern about using the early input flag in a few test suites.
This change may cause increased flakiness, particularly on the
linux-chromeos-rel bot and Android. Please assign flakiness bugs
to schenney@ and ping if necessary.
Bug: 1120158
Change-Id: Ief45735c5bdb4d48d6554dcfc12e3b621355e080
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2368282
Reviewed-by: Clemens Arbesser <arbesser@google.com>
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Owen Min <zmin@chromium.org>
Reviewed-by: Eric Willigers <ericwilligers@chromium.org>
Reviewed-by: Tommy Martino <tmartino@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#864725}
This Blink RuntimeEnabledFeature was previously used to enable this
opt-out for the TextFragment (and other kinds of load-time scrolls)
feature using an Origin-Trial.
The feature shipped for real as part of Document-Policy and the
Origin-Trial has been wound-down. This CL removes the no longer needed
RuntimeEnabledFeature.
Bug: 1047900
Change-Id: Ie8e8180aae6a9d76e4626eb2d5c8e4b3a9fb582c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2622240
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Nick Burris <nburris@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#843274}
A text fragment occurs in a URL fragment and begins with ":~:text=...".
It is used to highlight and scroll the provided text into view when the
page is loaded. For user privacy reasons, we restrict scrolling the text
into view unless the navigation occurred via a user gesture. See:
https://github.com/WICG/scroll-to-text-fragment#security-considerations
for more details.
However, it is common (particularly on social and messaging services
where content is user-generated) for links to be served via a redirect.
A typical example (from chat.google.com) works like this:
1. User receives and clicks a link to https://example.com#:~:text=foo"
2. chat.google.com opens a new tab using window.open("", "_blank")
3. chat.google.com calls document.write on the newly opened window to
write a <meta> tag-based client redirect to
google.com/url?url=https://example.com... which is the URL
redirection service with the destination URL as a query param.
4. google.com/url then calls window.location and writes
"https://example.com#:~:text=foo" into it
5. the new tab finally navigates to example.com
The only navigation that had a user gesture attached to it is the
initial empty document navigation in step 2. This means the example.com
page is navigated to without a user gesture and the text fragment is
blocked. A similar pattern is seen on many popular services: Twitter,
Instagram, Facebook Messenger, etc.
This CL solves the above scenario by introducing a "text fragment
token". This token grants its holder permission to invoke a text
fragment. The token can be used during load to invoke the text fragment,
or it can be passed into a navigation to grant permission to the next
page without requiring a user gesture. However, in either case, the
token is consumed so a page cannot both invoke a text fragment and pass
the token.
The token is created in only in DocumentLoader's constructor and while
processing a same-document navigation. For regular navigations, it is
only created if the current navigation was user initiated. For
same-document navigations, it's created only if browser-initiated and
the navigation has a text fragment. This mechanism can be thought of as
a user gesture that applies only to text fragment and whose lifetime
extends across navigations but cannot be copied and is always consumed
on use.
Bug: 1055455
Change-Id: Icddd849937d24b579bbeb5a4b9f87539d8339905
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2159324
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#799173}
With crrev.com/c/2121522, some main-frame same-site navigations will
result in a new BrowsingInstance, SiteInstance, RenderFrameHost,
RenderView, etc. This CL updates expectations of tests under contents/
that didn't expect a change of RenderFrameHosts etc. on same-site main
frame navigations.
This CL does not include:
- Updates for navigation-related content_browsertests and
content_unittests, which are handled in crrev.com/c/2195872 and
crrev.com/c/2210035.
- Updates for tests under chrome/, components/ and layout tests (fixed
in other CLs)
- Fix to ensure order of unload handlers on same-site cross-RFH
navigations (will be fixed on a future CL)
- Fix to ensure WebPreferences are carried over for cross-RFH same-site
navigations (will be fixed on a future CL)
For more details, see doc: https://docs.google.com/document/d/1lHdkKLUe8H6ZP6ALwj-dsus7oYcuc93HkSCHCcerItg/edit?usp=sharing
Bug: 977562
Change-Id: I1fc507538b48d7566be28a4bd2ef83ff3cacd843
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2210174
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Sreeja Kamishetty <sreejakshetty@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/master@{#795365}
ForceLoadAtTop is a policy which pages can apply that blocks any kind of
scroll-on-load behavior including: fragments, text-fragments, history
scroll restoration.
However, we had a bug where by it blocked all fragment navigations,
including same page navigations (e.g. clicking a link that changes only
the fragment in the current URL). Since this isn't a new load, the
policy shouldn't apply in this case.
In addition to the small fix to this check, this CL also cleans up and
makes the scrolling to fragment condition more readable.
Bug: 1091247
Change-Id: Ic523b5b331720a822a5530698ab6560f580d2b97
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2265758
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Nick Burris <nburris@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#782667}
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}
These have grown large enough that it makes sense to split them out from
navigation browser tests into their own separate file.
This CL is a straightforward move with not changes to the tests
themselves.
Bug: None
Change-Id: Iba4759b4e8f5797d5a693775684312c8997bac12
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2160325
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#762141}
