This is part of the patch series migrating PlatformEvent to ui::Event
(formerly using XEvent) in Aura/X11 in order to eliminate this
fundamental difference/incompatibility between Ozone and non-Ozone X11
ports. Design doc [1] describes in details such effort.
This CL, particularly, is meant to ensure XEvent => ui::Event
translation code (x11_event_translation.{h,cc}) is equivalent to
constructing ui::*Event using the PlatformEvent ctors, the mechanism
used so far to do such "translation".
To achieve it, events_unittests have been modified to use the brand new
X11 event translation code as well as fixing discrepancies found along
the way. Most of them are trivial and this change does not bring any
behavioral change.
[1] https://docs.google.com/document/d/1Neh2p6f8pew9SPuEAtnJMafozAY7uhAIfhwd43CLETc
Bug: 965991
Change-Id: I1b738fd20c21233a611a0661b76da7fcdf176613
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2022322
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736213}
A transaction watchdog timer intended to guard against hung renderers
would be scheduled even if the transaction backend still had tasks to
perform, which could be blocked on other backend work. The watchdog
timer should only be started if the backend is only waiting on the
front end. Add the extra condition.
Bug: 1045585
Change-Id: I86e978faa9735e1b7a89a10660f1c747237b3c9c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2026109
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736211}
BrowserAccessibilityComWin inherits IAccessibleText from 2 sources :
- IAccessibleHypertext
- AXPlatformNodeWin
A snippet of the inheritance hierarchy looks like this :
______IAccessibleText______
| |
V V
IAccessibleHypertext AXPlatformNodeWin
| |
|___________________________|
|
V
BrowserAccessibilityComWin
Because of this, BrowserAccessibilityComWin (BAComWin) must override
IAccessibleText methods even though it only calls the inherited
implementation from AXPlatformNodeWin.
To simplify the inheritance hierarchy and allow BAComWin to only
override what is necessary, AXPlatformNodeWin should inherit
IAccessibleHypertext and return E_NOTIMPL for the hypertext methods
until hypertext implementation can be migrated out of BAComWin.
Bug: 1038767
Change-Id: Ie8b47cbac2de791700852f3298e609b0791e818c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1985172
Commit-Queue: Adam Ettenberger <adettenb@microsoft.com>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736178}
Implement UKM metrics in storage_partition_impl to record when cookies
are sent or set across schemes.
This is the UKM version of the UMAs
Cookie.SameSiteDifferentSchemeRequest and
Cookie.SameSiteDifferentSchemeResponse.
Doing so requires that the CookieInclusionStatus warning field be
expanded to include cross-scheme warnings.
Bug: 1030938
Change-Id: Iad13d610ae39e4d250157394459297698a2879de
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2015353
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Maksim Orlovich <morlovich@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Steven Bingler <bingler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736165}
Added explicit case for <time> tags to prevent node from being ignored
as a leaf on Android. This will allow the <time> nodes to be traversed
with AT the same as on other platforms.
Bug: 1043377
Change-Id: Ibd243578322485d7abafc4b5f7a8dbe0f9986d79
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2018243
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Mark Schillaci <mschillaci@google.com>
Cr-Commit-Position: refs/heads/master@{#736159}
This CL adds a new UI thread class, ConversionManager, owned by the
StoragePartition. The ConversionManager initializes and owns
a ConversionStorage instance and also implements the
ConversionStorage::StorageDelegate.
Specific API constraints like delaying conversion reports, and setting
the maximum number of conversions are implemented in a separate
composable class ConversionPolicy to allow tests to easily mock certain
functionality, as well as centralize these constraints to a single
include.
Intended functionality of the ConversionManager includes:
- ownership of the ConversionReporter, and timers for periodically
fetching reports to send from storage.
- methods to log new impressions / conversions to storage
- ownership and usage of Report Cooldown throttling implementations
This functionality is intended to be implemented in follow-up CL's due
to dependencies, and to keep these changes small. A more complete
implementation can be seen on the prototype change below.
The functionality of the API is described on
https://github.com/csharrison/conversion-measurement-api
Design-doc(RVG): https://crbug.com/1039466
Reference prototype change:
https://chromium-review.googlesource.com/c/chromium/src/+/1967220
Bug: 1014604
Change-Id: If432b0046b8c6dcd12ce828aea3917cf887fbe08
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1994016
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Commit-Queue: John Delaney <johnidel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736136}
This adds a new net error and cert status for when a connection uses an
obsolete version of TLS (i.e., TLS 1.0 or 1.1 in the default
configuration). This also adds support for the SSLVersionMin enterprise
policy setting which version triggers the error (and will thus show an
interstitial warning), allowing enterprises to opt-out of the legacy TLS
interstitial.
A new interstitial for this error will be added in
https://crrev.com/c/1940707. Support for the control site list will be
added in https://crrev.com/c/1906779.
Bug: 896013, 1039756
Change-Id: Ib24d4b3efcfbbad1f37a41bfed3690280d4d2b71
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1894616
Commit-Queue: Christopher Thompson <cthomp@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736130}
During upgrade transactions, a store or index can be created and
then immediately used from script in operations (e.g. "count"). On the
backend, the creation will not run until the transaction acquires a
lock, and pending tasks are queued. A handful of operations (including
"count()") were synchronously checking to see if the target
store/index had been created before queuing the task, which would fail
if the lock had not yet been acquired. The checks must occur when the
task is run; remove the bogus early checks, which would abort the
transaction.
Bug: 1045585
Change-Id: Ibef191e24916333da4e9b2449dda5ff775a35138
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2023521
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Commit-Queue: Daniel Murphy <dmurph@chromium.org>
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736126}
Remove the deprecated trace id mangling facility and convert the last
remaining uses to the new API as follows:
TRACE_ID_MANGLE() => TRACE_ID_LOCAL() // Process-local id.
TRACE_ID_DONT_MANGLE() => TRACE_ID_GLOBAL() // Cross-process id.
Test: Checked that a trace with input flow events still looks correct.
Bug: 639003
Change-Id: I2493e89787a49368528f844e8d37cfd120558fb0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2016648
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736109}
Simplify GpuProcessStartAllowed(), currently it returns false on
Windows with GPU and swiftshader disabled, or on Chromecast with the
flag --disable-gpu. This matches exactly when |gpu_mode_| is
GpuMode::DISABLED.
The test GpuStartsWithGpuDisabled has a special case for Chromecast
audio-only builds, but it isn't run on Android Chromecast. Separate out
the Chromecast-only test.
Also fix a couple of typos.
Change-Id: I166bf1c7f482e7b97c31ed607949044f3ef7ac6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2023949
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Sean Gilhuly <sgilhuly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736101}
To give Clank language parity with Android 27 new locales are being
added. 26 of those locales have been added in two previous CLs:
- https://crrev.com/c/1941058
- https://crrev.com/c/1952288
zh-hk was skipped because currently resources for it are mapped to
zh-tw. This CL skips that mapping for bundle builds where zh-hk is
now included. zh-hk is still mapped to zh-tw in apk builds.
There is an increase in size even when language splits are used in
bundles. A bug has been created to look into this:
- APK Bundles wastes a lot of space in resources.arsc (400kb)
- https://crbug.com/1031645
Bug: 1034774
Binary-Size: Size increase is unavoidable (see above).
Change-Id: I4edb9d5213e8dd3443522deee5395e500af34371
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1970258
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Reviewed-by: (gone) Eric Stevenson <estevenson@chromium.org>
Commit-Queue: Trevor Perrier <perrier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736071}
This test was disabled on Fuchsia due to flakiness, but is also
extremely flaky on Linux, suggesting a more general cross-platform
raciness or timing issue.
TBR=falken
Bug: 1029434
Change-Id: I02969efdb4e318a46c47fe292e63c5a7129946cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2025707
Reviewed-by: Wez <wez@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736061}
This CL implements percent-based scrolling for Windows. This makes
mousewheel initiated scrolls be interpreted as a percentage
of the size of the intended scroller, instead of being translated
directly into pixels. This is done as a part of the effort to port
Edge-style scrolling into Chromium.
The deltas reported by the wheel event are unchanged in order to
maximize compatibility with the web.
Bug: 1009735
Change-Id: I4987cb6916fe5961cdb479018ccd7a464d574ebe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1776898
Commit-Queue: Daniel Libby <dlibby@microsoft.com>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736013}
IndexedDB doesn't need to know the file path for V8 File objects, as
these work just fine being hooked up to a mojo blob handle. This CL
removes all usages of external file paths in IndexedDB, and removes them
from even being serialized from the renderer.
Bug: 1036415
Change-Id: I6e074c5fe11654faaf2afb56d8fe290ded4f408e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1978848
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736010}
This reverts commit 0885c956ac.
Reason for revert: Unfortunately, this change results in the
notification of page-load-complete happening much later than it
did previously.
Since a11y events aren't fired when |user_is_navigating_away_|, the
result is that some events that occur early in a page's lifetime are
not emitted. This is most visible for programmatic 'focus' changes;
if they're not emitted, any connected AT doesn't know the focus has
changed.
Original change's description:
> Notify BrowserAccessibilityManager via WebContentsObserver
>
> This is the last of a series of CLs that remove manual notifications
> BrowserAccessibilityManager, now that it implements WebContentsObserver.
> This CL removes manual BAM::Navigation{Succeeded,Failed} notifications
> in favor of WCO::DidFinishNavigation, and BAM::UserIsNavigatingAway in
> favor of WCO::DidStartLoading.
>
> Bug: 981271
> Change-Id: Ieca6ce0b97f2a0267fd7f2582ab1e333deb11b95
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1938489
> Reviewed-by: Matt Falkenhagen <falken@chromium.org>
> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
> Commit-Queue: Dominic Farolino <dom@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#720102}
TBR=falken@chromium.org,dmazzoni@chromium.org,dom@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 981271
Change-Id: I41d68985b964792083aa5b6628bb3bc0972c9790
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2024154
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Ian Prest <iapres@microsoft.com>
Commit-Queue: Ian Prest <iapres@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#735980}
The CL allows us to clean up one of the respective legacy/plumbing IPC
methods from content::RenderFrameProxy and blink::WebRemoteFrame{Impl}:
OnDidStopLoading().
However, given that content::RenderFrameProxy::OnDidStartLoading()
is still called directly by content::RenderFrameImpl::OnUnload(),
it can't be removed now.
RenderFrameHostManagerTestWithSiteIsolation.NewProxyReceivesLoadingState
makes use of the newly added helper class StartStopLoadingRemoteFrame.
It inherits from content::FakeRemoteFrame, and overrides two mojo methods
it wants to track calling called: DidStartLoading() and DidStopLoading().
For this, the CL also adds a new hook to RenderFrameProxyHost that allows
tests to install a callback to react to an instance being created.
This way custom blink::mojom::RemoteFrame implementations can be
injected accordingly.
BUG=1044301
R=dtapuska@chromium.org
Change-Id: I0f972236c63356a872f339dddaa623c2dde4fdf1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2017002
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735970}
`gn format` recently changed its formatting behavior
for deps, source, and a few other elements when they
are assigned (with =) single-element lists to be consistent
with the formatting of updates (with +=) with single-element.
Now that we've rolled in a GN binary with the change,
reformat all files so that people don't get presubmit
warnings due to this.
Most changes have landed by now via `git cl split`.
This is what remains after two weeks.
Bug: 1041419
Change-Id: Ia813d744e57e5647266a91d4f6c725bf921fb11c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2024471
Commit-Queue: Nico Weber <thakis@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735958}
If the provided text marker is between lines, such as when on a soft line break
or on an ignored position that separates lines, we return the previous line when
VoiceOver asks for the line text marker range.
This is the same to how the WebKit code in Safari works.
See webcore/editing/VisibleUnits.cc::endOfLine(VisiblePosition&, LineEndpointComputationMode, bool) in the WebKit source code.
Also, this patch temporarily switches to CreateNextLineStartPosition for computing
the end of the line range. This should not have any drastic user
visible behavior change, but it's important to do
until CreatNextLineEndPosition is fixed to handle ignored positions.
Failure to introduce this workaround would delay fixing of line
navigation in Docs with VoiceOver.
R=dmazzoni@chromium.org
Bug: 1015408
Change-Id: Ifeb67d4de688fddace461568e064fc9768024fba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2023277
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735945}
Programmatic smooth scrolls should also be instant if the smooth scroll
flag is explicitly disabled.
Previously landed in
https://crrev.com/c/1536759https://crrev.com/c/2009842https://crrev.com/c/2022356
To reland, this CL force enables the scroll animator in Blink web
tests. Without this, the usual flow for determining if the animator is
enabled is followed, which leads to inconsistencies. On Mac, the
animator is enabled in Chrome but not in content shell. This leads to
inconsistencies with other platforms (Mac tests ran without smooth
scroll while Linux/Windows ran with) and ensuring we test what we ship.
This change required some minor fixes to tests that assumed instant
scroll on Mac (and uncovered one real bug).
Second reland fixes a few more tests on Mac. See diff from original
patchset for changes.
Third fix addresses flakiness in some of the Mac tests. Original
patchset has reverted CL.
TBR=flackr@chromium.org,nasko@chromium.org
Bug: 944583
Change-Id: I6b1ccb719b6bbed2b6d7495efa4d7846424796d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2024163
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735931}
What: Currently we only know ad status of a LocalFrame.
This patch will add the status to RemoteFrames.
Why: This makes it easier to implement some ad detections - sticky ads,
interstitial ads, etc. Those detections will involve frequently
querying the layout information and is_ad information of a Frame. So we
tag remote frame to avoid going through the browser process each time
we want to know ad status on a remote frame, so that the
detection/intervention can probably all be done on the renderer side.
How:
Add the "ad_frame_type" bit to FrameReplicationState.
In ContentSubresourceFilterThrottleManager::ReadyToCommitNavigation,
set the frame replication state and also notify all RemoteFrames about
the new status.
Testing is done within content/ to avoid exposing the proxy details
outside of content/.
Bug: 939370
Change-Id: I26fd2acb10b3a5e837aacdc3d3f3e2a05563694b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1913074
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735914}
This CL migrates the IAccessibleText implementation for
- get_textAtOffset
- get_textBeforeOffset
- get_textAfterOffset
.. from BrowserAccessibilityComWin to the base class AXPlatformNodeWin,
and adds a helper method which unifies their implementation.
https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_text.html
There was an issue that get_text{Before|After}Offset were
not implemented correctly according to this spec which is being
addressed by this change :
* BeforeOffset and AfterOffset were not returning the adjacent
boundary start / end offsets. AfterOffset was setting the
|star_offset| to |offset| which included that character, and
BeforeOffset was setting the |end_offset| to |offset| which did
exclude it. Both methods however did not select a start and end
offset that formed a complete boundary.
"Returns the substring of the specified text type that is located
{before|after} the given character and does not include it."
"For example, if text type is IA2_TEXT_BOUNDARY_WORD, then the
complete word that is closest to and located {before|after} offset
is returned."
There is another difference for get_text{At|Before|After}Offset but it
is not being addressed with this change :
* AtOffset allows invalid indices for IA2_TEXT_BOUNDARY_LINE,
e.g. IA2_TEXT_OFFSET_LENGTH.
"All methods that operate on particular characters use character
indices (e.g. IAccessibleText::textAtOffset) from 0 to length-1."
Bug: 1038767, 1039516
Change-Id: Icb0916e9b96e8e2fe48c0e8a2e232381fcf421a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1989027
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#735893}
Attempting to reland https://crrev.com/c/1543258 which was reverted in
https://crrev.com/c/1626417 because of a bug (not collapsing successive
navigations into one), which is not a problem anymore now that
PerNavigationMojoInterface has landed.
With this CL, about:blank navigations (except initial navigations) will
always go through the browser process.
Some additional changes:
- SitePerProcessBrowserTest.SubframeBlankUrlsAfterRestore is also updated
in this CL because now about:blank navigations will use its initiator
origin instead of the parent's origin when determining which SiteInstance
it should use after getting restored.
- about:blank navigation requests that go through the browser process got
their referrer URL sanitized incorrectly, causing a WPT to fail, so
we're updating Referrer::SanitizeForRequest too.
Bug: 936696
Change-Id: I15adfc0ded269a9a10b1d4f5e820f3a627e9c101
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2006997
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735828}
This CL introduces a new accessibility role type named
kPdfActionableHighlight which is needed to make highlights in PDF
accessible. There is no existing role type which can effectively
denote a PDF highlight, hence the need for a new role type.
Bug: 1008775
Change-Id: Ia57a273561c82fc5b7daf2dad96f479e34cc0636
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1914140
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Kevin Babbitt <kbabbitt@microsoft.com>
Commit-Queue: Ankit Kumar 🌪️ <ankk@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#735752}
This also removes the virtual test suite, and the failing test
expectations from the experimental build.
The default values for the two initial features are also set to their
correct web-compatible defaults.
Bug: 993790
Change-Id: I308676b0c63524ad4a229a03940b928f95a384c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2019464
Commit-Queue: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735751}
When an expectations file for accessibility dump tree or event tests
has more lines than the actual output, the test must fail.
Without this change, the following will produce false positives
in our test results:
- Expected events the end of event expectations, but are not fired,
- Expected objects at the end of the object hierarchy that do not
exist in the actual object hierarchy.
Bug: None
Change-Id: I4bb65bb73b0d8af7380c85e59c7891c466c95fc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2015429
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Auto-Submit: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735749}
A few functions in RenderProcessHostImpl, such as IsSuitableHost, were
passing both a BrowserContext and either an IsolationContext or
SiteInstance. This isn't needed, as both IsolationContext and
SiteInstance already include BrowserContext information, so this CL
removes the unnecessary BrowserContext arguments.
Bug: 1015882
Change-Id: I248b999736adf409bb694af7330af8dcf5161d78
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2021337
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735721}
Exposes setExperimentalAppBadge() and clearExperimentalAppBadge() on the
navigator for service workers. When a service worker uses the badging
API, the badge update affects all web apps within the scope of the
service worker's registration. Future changes can expose the badging API
to dedicated workers and shared workers. The WICG draft spec
(https://wicg.github.io/badging/) states that dedicated workers and shared
workers may set a badge when they are a service worker client.
To expose badging on WorkerNavigator, this change updates the existing
badging code under /blink/renderer/modules/badging/. The change adds a
new IDL file, worker_navigator_badge.idl. The new IDL defines a partial
WorkerNavigator interface to add the set and clear badging functions. The
change updates the existing NavigatorBadge class to include the new
WorkerNavigator IDL bindings, which are identical to the existing
Navigator IDL bindings except they pass a WorkerNavigator& parameter
instead of Navigator&. The change moves the core implementation from the
existing Navigator IDL bindings into SetAppBadgeHelper() and
ClearAppBadgeHelper(). These helpers enable both the Navigator IDL
bindings and the WorkerNavigator IDL bindings to use the same
implementation.
The next part of the change registers a blink::mojom::BadgeService
binder in the ServiceWorkerGlobalScope's browser interface binders.
The ServiceWorkerGlobalScope needs this registration to connect the
NavigatorBadge class to the badging::BadgeManager class in
chrome/browser. Without this registration, the JavaScript badging
APIs do not trigger any badge updates for service workers. For the
Window, the binder registration occurs through
ContentBrowserClient::RegisterBrowserInterfaceBindersForFrame().
Unfortunately, RegisterBrowserInterfaceBindersForServiceWorker() does
not exist. Additionally, the Window binder registration provides the
RenderFrameHost as context when creating a new mojo binding. The
BadgeManager uses the RenderFrameHost as a binding context to find the
URL to use when setting a badge. ServiceWorkerProviderHost is like
RenderFrameHost, but for service workers. ServiceWorkerProviderHost
can provide the service worker registration scope URL to use when
setting a badge. Unfortunately, ServiceWorkerProviderHost is not
publicly exposed to chrome/browser. This makes creating a
RegisterBrowserInterfaceBindersForServiceWorker() problematic since
the service worker cannot provide the same amount of context as the
Window/Frame.
Instead of using something like
ContentBrowserClient::RegisterBrowserInterfaceBindersForFrame(), this
change registers the badging binder in the content layer in
browser_interface_binder.cc. Keeping the binder in the content layer
allows it to use the ServiceWorkerProviderHost to get the context it
needs and then pass that context to the BadgeManager in chrome/browser.
The change adds the
ContentBrowserClient::BindBadgeServiceReceiverFromServiceWorker(), which
allows the content badging binder to pass the service worker's Render
Process Host and its scope URL to the BadgeManager, which the
BadgeManager uses as the binding context.
The change updates the BadgeManager class to work with both service
workers and documents. There are two differences between service
worker and document badge updates:
1) A service worker badge update may affect multiple apps. A document
badge update may affect up to one app.
2) Service workers and documents provide different mojo binding
contexts. Service workers provide a RenderProcessHost and a scope URL.
Documents provide a RenderFrameHost and a frame ID.
To deal with these differences, this change updates the pre-existing
BadgeManager::BindingContext struct to be an abstract interface base
class. The class has one method to override: GetAppIdsForBadging(),
which returns the list of AppIDs to update after a badge change. The
change adds two derived classes FrameBindingContext and
ServiceWorkerBindingContext. Each class handles the differences
described above.
For testing, this change updates WebAppBadgingBrowserTest to include
service worker test cases. The change added new test data to
chrome/test/data/web_app_badging/ to facilitate service worker testing.
The new browser tests use the main frame to post a message to the
service worker. Depending on the message content, the service worker
responds by either calling setExperimentalAppBadge() or
clearExperimentalAppBadge(). The change also generalizes
WebAppBadgingBrowserTest to handle when a service worker badge change
affects multiple apps. Before this change, WebAppBadgingBrowserTest
expected exactly 1 badge update. After this change, the test can
expect multiple badge changes with at most 1 badge change per app.
The change also updates the badging origin trial API web_tests to
include service workers. I attempted to update the existing badging
web_tests to include workers, but since these tests run as file://,
all workers failed to run due to null origin errors. I was also
unsuccessful moving these tests to run as https:// since the https://
server did not have the required resources to mock mojo.
Bug: 1036202
Change-Id: I66b2bf66b787965d6aa4ac35b663e522ffc4bd67
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2009376
Commit-Queue: Steve Becker <stevebe@microsoft.com>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Jay Harris <harrisjay@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735705}
This reverts commit b746c948a2.
Reason for revert: Still failing on Mac web tests: https://ci.chromium.org/p/chromium/builders/ci/Mac10.13%20Tests%20%28dbg%29/16983
Original change's description:
> [Reland#2] Make programmatic scrolls respect smooth scroll flag
>
> Programmatic smooth scrolls should also be instant if the smooth scroll
> flag is explicitly disabled.
>
> Previously landed in https://crrev.com/c/1536759 and in
> https://crrev.com/c/2009842
>
> To reland, this CL force enables the scroll animator in Blink web
> tests. Without this, the usual flow for determining if the animator is
> enabled is followed, which leads to inconsistencies. On Mac, the
> animator is enabled in Chrome but not in content shell. This leads to
> inconsistencies with other platforms (Mac tests ran without smooth
> scroll while Linux/Windows ran with) and ensuring we test what we ship.
>
> This change required some minor fixes to tests that assumed instant
> scroll on Mac (and uncovered one real bug).
>
> Second reland fixes a few more tests on Mac. See diff from original
> patchset for changes.
>
> TBR=flackr@chromium.org,nasko@chromium.org
>
> Bug: 944583
> Change-Id: Ib91c417f1fcc2b27601f2c7039b02da72b9d5420
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2022356
> Reviewed-by: David Bokan <bokan@chromium.org>
> Commit-Queue: David Bokan <bokan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#735480}
TBR=flackr@chromium.org,nasko@chromium.org,bokan@chromium.org
Change-Id: Ifad1c0b6a19f222391c2361e80c699d27da7576b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 944583
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2024412
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735704}
The Chrome WebAuthn team has decided not to ship support for BLE
authenticators in Web Authentication due to reliability issues.
This CL removes the flag that allows it to be enabled. BLE
authenticators can still be used with Chrome running on versions of
Windows 10 that support the Hello API since that does not depend on this
flag or Chrome's implementation.
BUG=1046131
Change-Id: I2992fec02b95677d84a0b4fc65a5432a325e6c23
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2023671
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735677}
This CL adds support for, but never triggers, two kinds of mixed content
download warnings that show up in the download shelf. Neither is used
yet. These supplement the existing silent blocking.
The warnings look like this:
- https://drive.google.com/file/d/1HKKrRv4uScGsVv_l8J9huZLnHWp-j_t6/view
- https://drive.google.com/file/d/1TgSTEFh1n0gWn1CpJnqkP4imhtkk20gd/view
This CL also adds support for these warnings in the chrome://downloads
UI. There it re-uses the "dangerous" download warning without any
modifications beyond a custom string.
All MIX-DL blocking logic is guarded by a flag, but even when that flag
is enabled, this change is not triggered and is thus not visible.
Subsequent CLs will:
- trigger these warnings when appropriate,
- finish the UI for Android, and
- add proper testing.
This is part of go/downloads-as-mixed-content
Bug: 960819
Change-Id: Id69adca8f5b7ae9acab9384435bb84257acaa9c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1984470
Reviewed-by: Esmael Elmoslimany <aee@chromium.org>
Reviewed-by: Daniel Rubery <drubery@chromium.org>
Reviewed-by: Min Qin <qinmin@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Commit-Queue: Joe DeBlasio <jdeblasio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735652}
