This is necessary to update the existing typemap to use the newest
version of the base::Value API for dictionaries and lists. There should
be no actual change from this CL, since the C++ typemap for
mojo_base.mojom.{Dictionary,List}Value is exactly the same as the C++
typemap for mojo_base.mojom.Deprecated{Dictionary,List}Value.
Bug: 1301889
Bug: 1301890
Change-Id: I96e77f3a15c693e5c6ffa512cb015c9e11d4e062
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3514804
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#979624}
When the User-Agent string is overridden without an accompanying
UserAgentMetadata, User-Agent Client Hint request headers will now with
blank values (as opposed to not sending the headers at all). The
documentation and tests for chrome.webviewTag.setUserAgentOverride have
been updated to reflect this change.
Bug: 1240171
Change-Id: Ic31f7ed0abc57d98ccd4a4a1c1dcd3d12338064a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3500976
Commit-Queue: Aaron Tagliaboschi <aarontag@chromium.org>
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#979469}
These changes will allow issues to be shown in devtools when a cookie
has one or more warning or exclusion reasons associated with it. It
refactors the code path used for same site cookie issues by making it
available for any type of cookie issue.
Additional changes will need to be made in devtools frontend to account
for the changes introduced here. This will be done in a followup CL.
Bug: 1254192
Change-Id: I929435567eac90bed60c4df464150db6c456da83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449712
Reviewed-by: Steven Bingler <bingler@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Juba Borgohain <chromiumjuba@gmail.com>
Cr-Commit-Position: refs/heads/main@{#975286}
This CL detects the reset used between WPT tests and forces a new
BrowsingInstance when the flag
--force-browsing-instance-reset-between-tests
is included with a virtual test suite. It also adds this flag to
the virtual test suite used to run the OriginAgentCluster (OAC)
web tests. This prevents OAC state from a previous test from affecting
subsequent tests, since OAC state is per-BrowsingInstance.
Bug: 1227911
Change-Id: Ia330d3cb781e57e8709f80e51b8feef208e6d058
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3212936
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Erik Staab <estaab@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#974736}
GetList() will be reimplemented in a future CL with an updated
signature, so existing uses need to be renamed out of the way.
Unlike TakeList() and TakeDict(), GetList() is used quite widely. This
CL migrates a number of uses using the following set of automated steps:
sed -i "s|->GetList()|->GetListDeprecated()|g" \
$(git gs "GetList()" --name-only)
git checkout -- base/values_unittest.cc third_party/dom_distiller_js
git cl format
Bug: 1291666
Change-Id: I1b7a92fcb4874e7afb82d4bd092c1c9de2cc3d05
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3430698
Reviewed-by: danakj chromium <danakj@chromium.org>
Owners-Override: danakj chromium <danakj@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#966487}
This CL adds a requestPictureInPictureWindow() method to Window for
PiP 2.0 that opens a popup window while adding some
picture-in-picture-specific options to the FrameLoadRequest. These
options are currently ignored. This is a prototype that does not yet
return a PictureInPictureWindow object, or handle any other PiP
requirements. It simply opens a popup window when called.
This is all behind the existing PictureInPictureV2 blink feature flag.
Bug: 1253970
Change-Id: I9cd15fd6bddc3bb5b4dc3c00367e139db2250485
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3269038
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Reviewed-by: Fr <beaufort.francois@gmail.com>
Reviewed-by: danakj chromium <danakj@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Tommy Steimel <steimel@chromium.org>
Cr-Commit-Position: refs/heads/main@{#965822}
This CL modifies the behavior of web test to avoid unnecessary caching
of the test page as follows.
Before this CL, the web test behaved as follows:
=====
- Open test_1.html as a test.
- Navigate to about:blank?reset-web-test.
- Cache test_1.html in back/forward cache.
=====
- Open test_2.html as a test.
- Navigate to about:blank?reset-web-test.
- Cache test_2.html in back/forward cache.
=====
After this CL, the web test behaves as follows:
=====
- Open test_1.html as a test.
- Disable back/forward cache for test_1.html.
- Navigate to about:blank?reset-web-test.
- Flush all of the back/forward cache.
=====
- Open test_2.html as a test.
- Disable back/forward cache for test_2.html.
- Navigate to about:blank?reset-web-test.
- Flush all of the back/forward cache.
=====
Bug: 1269581
Change-Id: Id5173d53c6b5dca35f02265ec36538dd7ec13625
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3398310
Reviewed-by: danakj chromium <danakj@chromium.org>
Commit-Queue: Minoru Chikamune <chikamune@chromium.org>
Cr-Commit-Position: refs/heads/main@{#965789}
These functions are not supposed to be called if reporting is disabled
(enable_reporting=false). The usages was supposed to be guarded on the
caller side by BUILDFLAG(ENABLE_REPORTING). Nonetheless, some of the
usages are not guarded and they are still called and cause assert on
certain web pages.
As a fix, remove the guards where it is possible from the caller site and
guard the callee site to do nothing if reporting is disabled.
Also enable ReportingServiceProxy for disabled reporting to avoid
crash/assert when reporting API is accessed via mojo.
Bug: none
Test: load https://www.usnews.com/
Change-Id: If2cc6add7eee78e842a4663f857f07bf75cce149
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3412481
Reviewed-by: Rodney Ding <rodneyding@google.com>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#965655}
In crrev.com/c/3230354, we landed the change where we only dispatch
DocumentAvailableInMainFrame for the primary main frame. This
change makes it straightforward for the API users to interpret that
the observer is only invoked for primary main frames.
We do mass rename of the DocumentAvailableInMainFrame use cases and also
remove the RenderFrameHost* parameter, which is not necessary as it can
be obtained directly from web_contents()->GetMainFrame().
The following changes were made using tools/git/mffr.py:
- DocumentAvailableInMainFrame(RenderFrameHost* render_frame_host)
-> PrimaryMainDocumentElementAvailable
- DocumentAvailableInMainFrame(bool uses_temporary_zoom_level)
-> MainDocumentElementAvailable(bool uses_temporary_zoom_level);
- is_document_available_in_main_document()
-> is_main_document_element_available()
For more context, please refer to:
https://docs.google.com/document/d/1GjuE0wXRj304q61T_HFLj3CRV1mNqMWfYIz_8tKdEZY/edit?usp=sharing.
BUG= 1288029, 1237422
Change-Id: If46e69d8653b0993645887d945b4c5c05c3801c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3395378
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Owners-Override: Alexander Timin <altimin@chromium.org>
Commit-Queue: Sreeja Kamishetty <sreejakshetty@chromium.org>
Cr-Commit-Position: refs/heads/main@{#964662}
With scroll unification, blink::WebPlugin no longer receives gesture
scroll events, which breaks some tests that expect it to see them.
However the only current users of WebPlugin, besides tests, are:
- PDF viewer, which does its own gesture detection and drives scrolling
from outside the plugin through special hooks.
- Pepper API (still used for NaCL in extensions and Chrome Apps). Pepper
forwards some inputs, but PepperPluginInstanceImpl::HandleInputEvent
will drop gesture events as ClassifyInputEvent() would return 0.
- Placeholders that tell the user a plugin couldn't be loaded. These
aren't scrollable (plugin_placeholders.css sets overflow:hidden).
Therefore, it appears WebPlugin doesn't need to receive gesture events.
Update the test expectations accordingly.
Bug: 1252915
Change-Id: Ib0498479d90bf8368156e68953fcf5fb9ae98951
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3417691
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: danakj chromium <danakj@chromium.org>
Commit-Queue: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#964589}
This CL removes legacy SwiftShader from the
SetSoftwareWebGLCommandLineSwitches function
and uses SwANGLE for WebGL on all platforms.
Bug: chromium:1060139
Change-Id: Ie1ad81e6d648026f4143c09a103cdbd0d628fb48
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3408178
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: danakj chromium <danakj@chromium.org>
Commit-Queue: Alexis Hétu <sugoi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#963033}
During a transition, each shared element induces a render surface to
generate its content as an image. This image is then drawn using a
pseudo element which can be animated for the duration of the transition.
This pseudo element is drawn using a cc::DocumentTransitionContentLayer
tagged with the same SharedElementResourceId that the shared element's
render surface is tagged with.
Since the shared element's render surface output is drawn where the
DocumentTransitionContentLayer quad draws (instead of its actual
render target), this results in incorrect render surface dependency
tracking.
This change fixes this by updating the shared element's target render
surface to the render target of its corresponding
DocumentTransitionContentLayer (or to the layer itself if it has a
render surface).
This ensures that render passes are created in correct dependency order.
R=vasilyt@chromium.org, kylechar@chromium.org
Bug: 1277772
Change-Id: I9972eff032cbf9d76a1f8c2770a0937322de8907
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3396605
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Kyle Charbonneau <kylechar@chromium.org>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#961631}
Connects the ChromeContentBrowserClient implementation of
IsInterestGroupAPIAllowed to the recently added access control function
for joining an interest group.
To support distinguishing joins from other interest group operations,
an InterestGroupApiOperation is added, and to better clarify the
contents, usage of GURL for the auction party is changed to Origin.
Additionally, to allow the PageSpecificContentSettings to be informed
of attempts to join interest groups, the interface is adjusted to
take the RenderFrameHost instead of the BrowserContext.
Stubs for PageSpecificContentSettings functionality are included, these
will be included in a follow up.
Bug: 1286276
Change-Id: If02aefa75e8cf80940b18bd122418c36bdb65665
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3398639
Reviewed-by: Russ Hamilton <behamilton@google.com>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Theodore Olsauskas-Warren <sauski@google.com>
Cr-Commit-Position: refs/heads/main@{#961098}
If window.close() is called by a web test right *after* it has
completed, don't call OnTestFinished twice. Doing so leads to an extra
result being reported, and thus future web tests being matched to the
wrong expectations.
Fixed: 1283172
Change-Id: I8a3fd7eff9b553786ce1241e1d82875a1bdf9ddd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3383610
Auto-Submit: David Baron <dbaron@chromium.org>
Reviewed-by: danakj chromium <danakj@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#958865}
When the layout dumps were stitched together we would use
web_contents()->GetMainFrame()->ForEachRenderFrameHost() but when
requesting dumps we would use web_contents()->ForEachRenderFrameHost().
Since back/forward cache can share the FrameTreeNode ids it is possible
that we'd iterate RenderFrameHosts in the back/forward cache and those
would get already handled causing the DCHECK.
There are two ways to fix this 1) Actually use a GlobalFrameRoutingID
which uniquely maps to a RenderFrameHost 2) Fix the inconsistency
which seems more correct. WebTest currently doesn't require dumps from
prerender or bfcached pages so it is more appropriate to iterate only
the active page.
BUG=1267581
Change-Id: I9c6fa2ef612e3a85c3a569359418897cb36677be
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3345138
Reviewed-by: danakj chromium <danakj@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#952487}
Remove unnecessary includes and replace them with missing includes if
necessary. Fix the build by adding missing includes in various files
that depended on child_process_host.h's includes.
Also uninline ~ChildProcessHost().
Bug: 242216
Change-Id: I387ac9782910af2eedeed82de5355707dd63de48
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3309695
Reviewed-by: Alexander Timin <altimin@chromium.org>
Owners-Override: Alexander Timin <altimin@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#947045}
Introduces the initial NavigationEntry, created on FrameTree
initialization, which is not associated with any navigation. It will
be replaced or lose its initial-ness when the first navigation in the
main frame committed. With the initial NavigationEntry, we can always
guarantee that a NavigationEntry always exists, even when no navigation
has committed. This has many benefits, as outlined in the doc:
https://docs.google.com/document/d/1H81oAG13f21fUf-IGHH8AnjNVJFtaThowl5Ki9hWw5E/edit#heading=h.sbcge7snrbj3
This CL introduces a few changes of behavior:
- After initialization, a FrameTree/NavigationController will always
have a NavigationEntry. This will be reflected in content/public
functions such as GetLastCommittedEntry(), GetVisibleEntry(),
GetActiveEntry(), GetEntryCount(), GetLastCommittedEntryIndex(),
GetCurrentEntryIndex()
- Navigations that are previously ignored because there is no committed
entry to attach to or clone are now no longer ignored, except for the
synchronous about:blank commit for window.open().
What this CL does not change:
- This CL does not change the behavior of any navigation that wasn't
previously ignored, including initial empty document replacements.
- Web-platform-exposed behaviors, including history.length which will
still start at 0 instead of 1 on a tab that hasn't navigated at all.
- Behavior of WebView APIs. WebBackForwardList, which exposes the
whole session history list, remove initial NavigationEntry.
getOriginalURL() will continue to return null when there's no
committed navigation.
- Similarly, behavior of WebLayer APIs will not change. The values
returned by APIs such as GetNavigationListCurrentIndex() and
GetNavigationListSize() will continue to be what they were before (-1
and 0 respectively) even when the initial NavigationEntry exists,
preserving their previous behaviors.
This CL corresponds to Step 1 of the implementation plan in this doc:
https://docs.google.com/document/d/1H81oAG13f21fUf-IGHH8AnjNVJFtaThowl5Ki9hWw5E/edit#heading=h.8n643ug2wk11
This CL also applies all the changes detailed in the audit doc, except
for most of the "remove nullcheck" changes:
https://docs.google.com/spreadsheets/d/1MJyLNd6T5b7QWCO-qsSdnzmyLhubCddns1Uu9X8mEIk/edit#gid=0
Bug: 524208, 1215096
Change-Id: I9dbc17feeb451ae32954a8544cc32bb39ec37150
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3237491
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Kevin Marshall <kmarshall@chromium.org>
Reviewed-by: Daniel Rubery <drubery@chromium.org>
Owners-Override: Charlie Reis <creis@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946343}
Currently CHECK_EQ() at permission_request_manager.cc line 196 fails
when the permission is requested from a fenced frame. This is because
IsInactiveAndDisallowActivation() returns false for fenced frames.
This CL fix this by checking IsNestedWithinFencedFrame() in
PermissionContextBase::GetPermissionStatus().
Bug: 1190825, 1259837
Change-Id: Ieed75c6939d861da2f6fd2396fdbab7a43eb37a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3220941
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Ravjit Singh Uppal <ravjit@chromium.org>
Reviewed-by: Adithya Srinivasan <adithyas@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/main@{#942118}
As discussed in https://bit.ly/3qtrn9s we want to use gfx::PointF for
scroll offset (out of blink renderer) and gfx::Vector2dF for scroll
delta, instead of gfx::Vector2dF for both, for the following purposes:
1. To make it easier to do the correct thing: passing blink scroll
position (currently using FloatPoint, will be changed to gfx::PointF)
to out-of-blink scroll offset (and vice versa); and to make it
difficult to do the incorrect thing: passing blink scroll offset [1]
to out-of-blink scroll offset. Without this CL, the incorrect thing
would be easier to do than the correct thing because of the data
type mismatches.
2. We can better distinguish scroll offset and scroll delta with
different data types.
3. Make it consistent to use gfx::Point[F] for absolute scroll offsets
throughout Chromium.
[1] See third_party/blink/core/layout/README.md for detailed explanation
for of scroll position and scroll offset in blink renderer.
Bug: 738465
Change-Id: Ic9ac9658b8f3154514608ef4039780d0f20883bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3267944
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Kentaro Hara <haraken@chromium.org>
Owners-Override: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941498}
This is taking care of a long-standing TODO to move these OnceClosure
holders rather than copy them around with their OnceClosure* members.
This is a precursor to
https://chromium-review.googlesource.com/c/chromium/src/+/3187153/35#message-fcc92e9f85e73f0e5ba6c03610a95cda8736f1f9
which highlighted a problem where some tests see a non-null
MainFunctionParams::ui_task but running the closure results in a UAF.
Logs show that the test hitting the UAF is not the one setting this
field. This CL makes that impossible and fixes the issue in the
follow-up CL.
This CL is intended to be a logical no-op.
This CL touches a lot of files and must happen all at once.
The core change is that ContentMainParams and MainFunctionParams's
moveable fields (ui_task, created_main_parts_closure, and startup_data)
are now held by moveable types rather than raw pointers.
This trickles in the following chain:
main() (in various *_main.cc)
(or SetUp() in !OS_ANDROID browser_test_base.cc)
-> ContentMain()
-> ContentMainRunnerImpl::Initialize()
(forwards arg into MainFunctionParams)
-> RunBrowser()
-> BrowserMain()
-> BrowserMainRunnerImpl::Initialize()
-> BrowserMainLoop (stores MainFunctionParams)
-> BrowserMainLoop::Init
-> ContentBrowserClient::CreateBrowserMainParts()
-> (Embedder)ContentBrowserClient::CreateBrowserMainParts()
-> (Embedder)BrowserMainParts(Platform)
-> (Embedder)BrowserMainParts
-> RunOtherNamedProcessTypeMain()
-> (Embedder)ContentMainDelegate::RunProcess()
(or)
-> FooMain() (kMainFunctions)
(or)
-> RunZygote()
(creates its own MainFunctionParams)
-> (Embedder)ContentMainDelegate::RunProcess()
(on OS_ANDROID, browser_test_base.cc calls directly into
ContentMainDelegate::RunProcess())
Few of these needed the params after passing them down so a move-only
model was simple to adapt (even if invasive). The few exceptions like
BrowserMainRunnerImpl::Initialize consuming |created_main_parts_closure|
are better off in the new model (where they take the OnceClosure before
passing down the params) because that prevents others down the chain
from having access to a OnceClosure they shouldn't invoke anyways.
Noteworthy:
- ContentMainDelegate::RunProcess():
Returned an exit_code >= 0 to indicate the embedder elected to handle
the run request given these params. With move-only semantics it is
necessary to return the params back when the embedder declines
handling this run request. An absl::variant return value is used
to satisfy this requirement.
- content/public/test/test_launcher.h : GetContentMainParams():
Becomes CopyContentMainParams() and only exposes a copy of copyable
params. Uses new ContentMainParams::ShallowCopyForTesting() which
verifies that moveable fields are still null by that time as should be
the case in the order browser tests are initialized.
- MainFunctionParams::command_line being const& violated the style-guide
rule to "avoid defining functions that require a const reference
parameter to outlive the call". This also prevented moving. The type
was hence switched to a const CommandLine*.
- BUILD.gn changes for nacl_helper_win_64 which requires static linking
of its minimal //content deps (was previously missing a dep but was
getting away with it because MainFunctionParams was .h only; required
now with .cc). This was already done for static_switches and this CL
adds static_main_function_params, reusing a similar static_features
target that already existed but was no longer required in
/c/nacl/broker, cleaning that up by replacing rather than copying that
target's definition in this CL.
- ContentMainParams::minimal_browser_mode was weirdly passed as a
parameter to ContentMainRunner::Run(bool start_minimal_browser) but
that method also has access to the ContentMainParams originally passed
via ContentMainRunner::Init(). Passing the param again from Run()
would be a use-after-move in content_main.cc, instead
content_main_runner_impl.cc was updated to use the param it already
has in store.
Bug: 1175074
Change-Id: I3af90505525e426383c59107a3903d645d455682
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244976
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Owners-Override: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940478}
This is another CL that removes USE_X11 define and
gn arg usage from //content and also removes
IsUsingOzonePlatform condition as it's no longer
needed as it always resolves to true.
Bug: 1096425
Change-Id: Ibbf2e861b46ffd8156dfe6fd5c6df75c54b83ba9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3198073
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Cr-Commit-Position: refs/heads/main@{#937765}
These line numbers are sometimes included and sometimes not,
and they are "test only" output. So to avoid tests that flaky-
fail for no reason related to the test, this CL removes line
numbers completely.
While this CL is quite large, the only material changes are to
these two files:
content/web_test/renderer/web_frame_test_proxy.cc
- Remove line numbers
third_party/blink/web_tests/TestExpectations
- Remove many now-passing, non-flaky tests.
The remainder of the files are rebaselines that remove the
string "line Xyz: " from expectations output. I verified both
automatically and by manual inspection that these are the only
changes in expectations. Of course, it'd be great if reviewers
double-spot-checked this.
For posterity (and FYI), I used this filter to look for expectations
changes that are unrelated to the console line numbers:
git diff HEAD^ -U0 --diff-filter=d | grep '^[+-]' | grep -Ev '^(--- a/|\+\+\+ b/)' | grep -v "CONSOLE"
The only thing it returns are the two files mentioned above.
Fixed: 896194
Change-Id: Idc318795c56dd78d2eb8575897a144ba4bc0de63
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3246152
Commit-Queue: Mason Freed <masonf@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#937717}