We're refactoring startup tracing in Chrome, see design doc[1]. With
the new startup tracing architecture, each process needs to allocate a
shared memory buffer when enabling startup tracing.
In zygote child processes, this is only possible after mojo's IPC
support is brought up, because the mojo broker has to create the buffer
on the process's behalf (the zygote sandbox prevents the child processes
from doing this themselves).
To prepare for the startup tracing refactor, this patch moves startup
tracing initialization for zygote child processes from
ContentMainRunner to their respective main functions, until after mojo
is brought up by the respective ChildThreadImpl subclass.
We should only lose minimal tracing data due to this change (from the
early part of the respective main function), and only from zygote
children (primarily renderer + utility processes) on Linux/ChromeOS.
[1] https://docs.google.com/document/d/1FygJQbD29vMkfVfT7m0Lb1u1zZZU1VgXAPi_R0uBoTw/edit?usp=sharing
Bug: 1006753
Change-Id: I59c21b2b383c755925dc5ff0c19160985e089800
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2038574
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739869}
This CL is a precursor CL to moving FrameMsg_SetFrameOwnerProperties
to mojo interfaces.
It introduces scrollbar_mode.mojom and adds enum ScrollbarMode
to the mojom file to replace WebFrameOwnerProperties::ScrollingMode,
blink::ScrollbarMode, and FrameOwnerProperties::ScrollingMode.
Bug: 1042723
Change-Id: Ieb42dfc8abcded0ec7c1c847893f36fd150de858
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2038411
Commit-Queue: Julie Kim <jkim@igalia.com>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739830}
This patch will improve the interoperability on flash.
As Firefox has a restriction to disallow 307/308 POST redirects
for requests from the flash plugin, we will follow the same
approach, but will have a stronger restriction to allow only
GET and HEAD.
Bug: 332023
Change-Id: I17924315f1770c61b8cffca64f897e6be2e09cda
TEST: browser_tests --gtest_filter="*PPAPI*.URLLoader*"
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2026839
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739799}
This reverts commit e7f522eeb9.
Reason for revert: suspect causing compile failure on linux-chromeos-chrome.
Sample build: https://ci.chromium.org/p/chrome/builders/ci/linux-chromeos-chrome/2923
Sample log: https://logs.chromium.org/logs/chrome/buildbucket/cr-buildbucket.appspot.com/8888898680396285712/+/steps/compile/0/stdout?format=raw
E.g.
../../chrome/browser/ui/ash/assistant/assistant_test_mixin.cc:323:42: error: variable has incomplete type 'const base::test::ScopedRunLoopTimeout'
const base::test::ScopedRunLoopTimeout run_timeout(wait_timeout);
^
../../base/run_loop.h:28:7: note: forward declaration of 'base::test::ScopedRunLoopTimeout'
class ScopedRunLoopTimeout;
^
../../chrome/browser/ui/ash/assistant/assistant_test_mixin.cc:356:42: error: variable has incomplete type 'const base::test::ScopedRunLoopTimeout'
const base::test::ScopedRunLoopTimeout run_timeout(wait_timeout);
^
../../base/run_loop.h:28:7: note: forward declaration of 'base::test::ScopedRunLoopTimeout'
class ScopedRunLoopTimeout;
^
../../chrome/browser/ui/ash/assistant/assistant_test_mixin.cc:371:42: error: variable has incomplete type 'const base::test::ScopedRunLoopTimeout'
const base::test::ScopedRunLoopTimeout run_timeout(wait_timeout);
^
../../base/run_loop.h:28:7: note: forward declaration of 'base::test::ScopedRunLoopTimeout'
class ScopedRunLoopTimeout;
^
3 errors generated.
Original change's description:
> [base] Make test Run() timeouts fatal unless using GTest.
>
> The Run() timeouts set for tests now default to crashing the calling
> process. This ensures that Run() timeouts cause visible failures
> regardless of whether the calling suite uses GTest. Suites which do use
> GTest can switch to having timeouts reported via GTEST_FAIL() by calling:
>
> base::test::ScopedRunLoopTimeout::SetUseGTestFailOnTimeout();
>
> Test suites derived from base::TestSuite will have this option set for
> them as part of the TestSuite initialization.
>
> The RunLoop::ScopedRunTimeoutForTest helper is moved to
> base::test::ScopedRunLoopTimeout, to allow it to have GTest dependencies.
>
> Bug: 1021777, 1014767
> Change-Id: Id372c666c6455e56e52034ae528b417a0c23143c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1932464
> Commit-Queue: Wez <wez@chromium.org>
> Auto-Submit: Wez <wez@chromium.org>
> Reviewed-by: Scott Violet <sky@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#739760}
TBR=sky@chromium.org,wez@chromium.org,gab@chromium.org,kmarshall@chromium.org
Change-Id: Ib0927699042f216971448da8b1d70619c0545367
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1021777, 1014767
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2045697
Reviewed-by: Takashi Sakamoto <tasak@google.com>
Commit-Queue: Takashi Sakamoto <tasak@google.com>
Cr-Commit-Position: refs/heads/master@{#739790}
The Run() timeouts set for tests now default to crashing the calling
process. This ensures that Run() timeouts cause visible failures
regardless of whether the calling suite uses GTest. Suites which do use
GTest can switch to having timeouts reported via GTEST_FAIL() by calling:
base::test::ScopedRunLoopTimeout::SetUseGTestFailOnTimeout();
Test suites derived from base::TestSuite will have this option set for
them as part of the TestSuite initialization.
The RunLoop::ScopedRunTimeoutForTest helper is moved to
base::test::ScopedRunLoopTimeout, to allow it to have GTest dependencies.
Bug: 1021777, 1014767
Change-Id: Id372c666c6455e56e52034ae528b417a0c23143c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1932464
Commit-Queue: Wez <wez@chromium.org>
Auto-Submit: Wez <wez@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739760}
ui::EventType is being moved to //ui/event/types/ directory
(crrev/c/2028629). Currently, that directory needs types be put inside
ui::input_types. This would mean that input_types should be repeated in
many many places without much benefit in clarity. To be consistent
across this directory, we are removing the input_types namespace
altoghether.
Bug: 963781
Change-Id: I91fc42ca84bd112357989e024a732dcbabbedc39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2031532
Commit-Queue: Mohsen Izadi <mohsen@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739740}
- Report fullscreen playback on desktop the same way it's done
on Android. It means, in fullscreen mode, even if
the <video> element is not fullscreenElement, but occupies a
large enough portion of the screen, count such video playback as fullscreen.
- Use single viewport intersection observer for both remote/cast video renderer
to detect fullscreen playback
- Change the definition of "large enough proportion of the screen" to align
with what is used by RendererController and MediaControlsRotateToFullscreenDelegate.
Original commit: 64d6dc150d
Original review: https://chromium-review.googlesource.com/c/chromium/src/+/2032683
Revert commit: bdee4fdae5
Reason for resubmit: Fixed MSan error (uninitialized variable) in
FullscreenDetectionTest.
TBR=miu@chromium.org,dcheng@chromium.org,kinuko@chromium.org,dalecurtis@chromium.org
Bug: 1044666, 696211
Change-Id: I8cd0106b78b2f3a88957fdc67ebc3028a3e7cd69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2044304
Reviewed-by: Frank Liberato <liberato@chromium.org>
Commit-Queue: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739734}
This reverts commit 64d6dc150d.
Reason for revert:
Findit (https://goo.gl/kROfz5) identified CL at revision 739703 as the
culprit for failures in the build cycles as shown on:
https://analysis.chromium.org/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyRAsSDVdmU3VzcGVjdGVkQ0wiMWNocm9taXVtLzY0ZDZkYzE1MGQ0YWUwOTEwNTA0ZjJhNzM3MWVlNTRhZDlhYmYyMTEM
Sample Failed Build: https://ci.chromium.org/b/8889035766025759792
Sample Failed Step: content_browsertests
Original change's description:
> Fullscreen video playback detection on desktop
>
> - Report fullscreen playback on desktop the same way it's done
> on Android. It means, in fullscreen mode, even if
> the <video> element is not fullscreenElement, but occupies a
> large enough portion of the screen, count such video playback as fullscreen.
> - Use single viewport intersection observer for both remote/cast video renderer
> to detect fullscreen playback
> - Change the definition of "large enough proportion of the screen" to align
> with what is used by RendererController and MediaControlsRotateToFullscreenDelegate.
>
> Things left to do:
> - Detect effectively fullscreen playback even if the browser doesn't use
> fullscreen mode.
> - Removing rudemantal switches like ActivateViewportIntersectionMonitoring
>
> Bug: 1044666, 696211
> Change-Id: I14b197442b82ef5ccbb9ec1e7b9dcfa5812f048a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2032683
> Reviewed-by: Yuri Wiitala <miu@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
> Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
> Commit-Queue: Eugene Zemtsov <eugene@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#739703}
Change-Id: Iaeea15fb430956ec764c259af5e819830424cec6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1044666, 696211
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2044386
Cr-Commit-Position: refs/heads/master@{#739713}
- Report fullscreen playback on desktop the same way it's done
on Android. It means, in fullscreen mode, even if
the <video> element is not fullscreenElement, but occupies a
large enough portion of the screen, count such video playback as fullscreen.
- Use single viewport intersection observer for both remote/cast video renderer
to detect fullscreen playback
- Change the definition of "large enough proportion of the screen" to align
with what is used by RendererController and MediaControlsRotateToFullscreenDelegate.
Things left to do:
- Detect effectively fullscreen playback even if the browser doesn't use
fullscreen mode.
- Removing rudemantal switches like ActivateViewportIntersectionMonitoring
Bug: 1044666, 696211
Change-Id: I14b197442b82ef5ccbb9ec1e7b9dcfa5812f048a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2032683
Reviewed-by: Yuri Wiitala <miu@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Eugene Zemtsov <eugene@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739703}
This CL adds detection of breakage that may be caused by enabling CORS
for content scripts of Chrome extensions - this is controlled by the
CorbAllowlistAlsoAppliesToOorCors feature. The detection works in
"passive" mode - without actually modifying the CORS behavior in Chrome.
The "passive" detection reports that there is a risk that a response
might be broken if all of the 3 conditions below are true:
1. The request is triggered by a content script of a Chrome Extension
2. The response is allowed by CORB (we expect that extensions triggering
responses blocked by CORB are already allowlisted and therefore won't
be affected by the planned CORS changes)
3. The response would be blocked by CORS if it was enabled (i.e. the
request was cross-origin, in `cors` mode and the response didn't have
a valid `Access-Control-Allow-Origin` response header).
The "passive" mode is overly pessimistic - the responses might actually
be allowed if Chrome's behavior was modified to sent `Origin` request
header which might prompt the HTTP server to reply with a proper
`Access-Control-Allow-Origin` response header (see the 3rd item above).
The CL consists of 3 parts:
- Moving the definition of the CorbAllowlistAlsoAppliesToOorCors feature
to the //services/network layer.
- Declaration and implementation of the new UMA
- Test coverage
Bug: 920638
Change-Id: I6656d70925f63235c91430441dff978e4d747c94
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2033639
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739693}
Previously, the flag to enable WCG on Android was inside
compositor_impl_android.cc. But this is too late in the pipeline.
The display color gamuts are already set to wide or not before this.
This CL moves the flag forward so the display color spaces are set
correctly based on what the display actually supports.
Bug: 955158
Change-Id: I5e81b4d711eced61182f1a0466ddb65b00219af5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2036917
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Chris Blume <cblume@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739677}
The Core API Mappings 1.1 specification is not 100% clear on how to expose
embedded and plugin objects in IA2 and UIA.
What is clear is that screen readers Jaws and NVDA don't work with PDF documents
at all when an IA2 role of embedded object is used.
In this patch, I tried to follow the spec, while being consistent between how we expose <embed> and <object> tags:
1. If an embedded object or a plugin has children in the accessibility tree
an MSAA role of system groupping and an IA2 role of section are used.
This is because Jaws and NVDA do not "see" any of the children if an IA2 role of embedded object is used.
2. If the embedded object or the plugin doesn't have children
an MSAA role of system client and an IA2 role of embedded object are used.
3. UIA mappings have not been modified, but it would be nice if we could decide
whether UIA_PaneTypeId could be used for both plugins and embedded objects.
4. Also, since all of our plugins are windowless, (we don't support ActiveX objects), I exposed
an MSAA state of SYSTEM_UNAVAILABLE as per the spec.
R=dmazzoni@chromium.org, adam.ettenberger@microsoft.com
Bug: 1047856
Change-Id: I6a00eca551ca7aaf1310e2b539f69adbc4583611
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2031762
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Adam Ettenberger <adettenb@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#739676}
AppCache previously never implemented 304 response handling for
resources at all. The correct handling sequence causes the cached
item on disk to be updated based on the 304 response's results,
including its request and response times.
When corrupted cache entries were created due to another bug (issue
968179), this missing 304 handling resulted in those corrupted cache
entries persisting indefinitely.
This commit changes the 304 handling sequence for resources
so any cached entry's info will get updated based on the incoming
request's info and the entry's data will get copied to that new
entry. One implementation detail: it was easier to create a
new cached entry based on the old entry rather than updating
the old entry directly, so the change is written to copy cached
entries over, updating them in-flight based on the response.
As part of this change, this commit adds an UpdateJob unit test to
verify the cached data is correctly updated by first writing a cached
entry to disk with broken request and response times, kicking off the
update, letting it complete, and then reading the newly cached data
to verify that the request and response times are correctly updated.
This commit doesn't address 2 cases:
* It doesn't address 304 fixes for non-resource handling which will
remain as it was since the AppCache feature is close to removal.
* It doesn't handle the case where a cached entry has a Vary header
and the incoming response does not. In those cases, we'll continue
to be non-compliant with the spec. We believe this is acceptable
since support requires a lot of extra work and we expect it to be a
rare case. See the CL for more details.
Bug: 989611
Change-Id: Ifcb1c853da49d8f3a26104edad96d23386715f1a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2018442
Auto-Submit: Chase Phillips <cmp@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739668}
This CL replaces .mojom.h includes with .mojom-forward.h in some sub-directories
of content/browser to reduce the pre-processed size of header
files and shorter build time. The sub-directories are following,
- content/browser/accessibility
- content/browser/appcache
This CL has no behavior changes.
Bug: 1001360
Change-Id: I2af4190fcf6ce3498ff6c772046702318eedfee5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2035812
Reviewed-by: Martin Robinson <mrobinson@igalia.com>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com>
Cr-Commit-Position: refs/heads/master@{#739652}
This change is a first step towards disallowing null strings in
StringPiece by forbidding its construction from the nullptr literal.
Note: This does not catch constructing StringPiece from runtime null
strings, this will be done in a future CL.
TBR=dcheng
Bug: 1049498
Change-Id: I8d4d5508a1e7b773086d42caf738a03f85dea25f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2027791
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739606}
This change is the first step in creating a proxy resolver that
completely relies on the underlying system to figure out a proxy. The
ProxyResolutionService is currently deeply tied to the notion of first
fetching proxy configurations (ex: a PAC URL) and then using those
configurations to resolve a proxy. Since a proxy resolver that truly
defers to the underlying operating system for all proxy logic does not
follow this model, it is helpful if we separate the generic
ProxyResolutionService from the notion of configurations.
This change renames the existing ProxyResolutionService, which relies
on fetching proxy configurations, to ConfiguredProxyResolutionService.
The only other changes to this file are suggestions from presubmit and
Tricium.
A set of future CLs will break up the ConfiguredProxyResolutionService
into the logical pieces needed to create a new, generic
ProxyResolutionService that does not necessarily depend on configs.
This change is intended to introduce zero functional changes. It is a
pure refactor change.
Bug: 1032820
Change-Id: I63c51c97e361d1cf5184e10ecb5f9f0deb1b5cdf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2036408
Reviewed-by: Ramin Halavati <rhalavati@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Nicolas Arciniega <niarci@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#739597}
Previously, there was a content::LockObserver that both IndexedDB (via
IndexedDBExecutionContextConnectionTracker) and web locks (via
content::LockManager) would talk to in order to let
performance_manager::PerformanceManagerLockObserver know whether or not
a particular frame was using either IndexedDB or web locks.
This moves the tracking of both of these features into the renderer
behind a blink.mojom.FeatureObserver interface which still plumbs
through to the same (now) PerformanceManagerFeatureObserver functions.
This interface allows the renderer to send an empty ObservedFeature
interface, whose lifetime is associated with how long that frame
is using it. When the renderer is done, it can close the mojo pipe.
For locks, the LockManager owns the FeatureObserver remote pipe.
When pending requests are made, the LockRequestImpl owns an
ObservedFeature, so that frames with outstanding requests will not
be frozen. If the lock is granted, it is passed to the Lock object,
where it is held until it is released or the lock is stolen.
The blink IndexedDB implementation behaves similarly to locks.
IDBFactory gets the appropriate FeatureObserver for this frame and
gives it to WebIDBFactory(Impl). This is used to send the
ObservedFeature to whenever an IDBOpenDBRequest is created, with
the other end of the pipe living temporarily in IDBOpenDBRequest.
When the callback completes (if it completes successfully), it is
moved into the new IDBDatabase and lives there until that object
is destroyed or the database is closed.
Change-Id: I4b8a0bb66d758fe20af836f2992199e8867671c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2015860
Commit-Queue: enne <enne@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739579}
The CC frame sequence metrics have knowledge of why we need to be
performing frame updates. Pipe that through to the renderer to
annotate the Blink.UpdateTime UKM event. This will allow us to
identify common performance patterns.
Note that this information is already available in UKM via the
Compositor Throughput UKM event, so does not represent new
information. But it cannot be correlated with a Blink.UpdateTime
event for performance analysis of the renderer.
Bug:1040551
Change-Id: I3159b4363d86448df200c6ce8978f4aa6f293830
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2040181
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739576}
For a specific range, AXPlatformNodeTextRangeProvider::GetAttributeValue
returns the attribute value found in all of its subranges. For example,
if we query the read-only attribute for a range composed of two
subranges, we are going to query the read-only attribute of the two
different subrange. If the value is true in both subranges, true will be
returned. Otherwise, if the value is different, an unknown value will be
returned.
An issue exists with rich text fields. Because the rich text field
accessible node can have children, it can have subranges. That means
that, when we query the read-only attribute for a rich text field, we
look for the read-only value of all of its children. It is thus extra
important that the appropriate properties describing the editable state
of the text field node are propagated to its children node.
Working on this issue, I discovered that the editable properties are not
propagated to its children that are selectors, like the ::before
selector. It works fine for other children however.
This CL fixes this issue by modifying the implementation of
AXLayoutObject::GetNodeOrContainingBlockNode, called by
AXLayoutObject::IsEditable and AXLayoutObject::IsRichlyEditable.
I also took the liberty to fix a test I added in another CL related to
the read-only attribute. The test in itself had no issue for the
moment, but would have as soon as someone else would have modified it.
The error message was not helpful and I spent some time investigating it.
To avoid to waste someone else's time like I did, I fixed it. For more
info, see the changes made to
ax_platform_node_textrangeprovider_win_unittest.cc.
In short:
- We now pass down the editable properties all children of an editable
node.
- I added a dump test for this scenario.
- I fixed a future issue that would have happened with a unit test.
- I made FindNonAnonymousContainingBlock public and move the
implementation accordingly.
Bug: 1041305
Change-Id: I3ef0af27f0ef679eb27cf12ce5999c6c11fffccf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1996269
Commit-Queue: Benjamin Beaudry <benjamin.beaudry@microsoft.com>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739533}
RenderView isn't going away any time soon, but its relationship to the
frames/page has changed from in the past. It is now for frame-agnostic
things which are more rare. Generally RenderFrame is likely where most
code should live.
R=avi@chromium.org
Bug: 419087
Change-Id: Ia879599c001e16c559386cea5bf086211f970b9c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2044632
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739526}
A relatively simple modification to add embedding tokens to the main
frame. This has the same behavior as embedding tokens for remote frames
except it doesn't propagate the token to a parent.
Behaviors
- Add a token on first navigation.
- Swap the token on any cross-process navigation.
Bug: 1045014
Change-Id: Ia3a6ba58913b11167e0eb10b5d6f3399f5e3cfcd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2032024
Commit-Queue: Calder Kitagawa <ckitagawa@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739504}
Getting termination status on android is not reliable. To avoid flakiness,
we can skip did_exit_normally check and just check bad message.
On other platforms we want to verify that the renderer got killed,
rather than exiting normally.
In the SecurityExploitBrowserTest.PostMessageSourceOrigin,
we expect android process not to exit normally and specific bad
message reason for termination. To determen if it exited normally,
certain heuristics are used. The OOPIF's process is required to
have moderate or strong binding state at the moment of termination.
In this case last condition (see |setPriority| in
ChildProcessLauncherHelperImpl.java) needed for moderate binding
state is viewport intersection. Message about viewport intersection
is sent from renderer process, during cc::ProxyMain::BeginMainFrame.
Required condition for this is swap out of local web frame for remote one.
However, cc::ProxyMain::BeginMainFrame is not called when GPU is busy.
That means that if the swap out, navigation ending and process
killing, all happen between calls to DisplayScheduler::DidSwapBuffers
and DisplayScheduler::DidReceiveSwapBuffersAck (which can happen,
at least on some single core emulators), information about
viewport intersection will never get chance to reach main process.
As a result, termination info will be incorrectly determined as
normal, altough from histograms we could still obtain correct bad
message reason.
Change-Id: I21b6cbb9099cc66ee386045586ea2d4f823a8db7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2036098
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739502}
This reduces the pre-processed size of the header from 874,775 to
732,443 tokens (linux debug builds), bringing it back down to the size
of last October (crrev.com/706388), and shaving 10 CPU minutes off
local builds.
It also adds a #pragma clang max_tokens_here line to prevent the size
from regressing without anyone noticing. See the bug and docs linked
from it for more info.
Bug: 1049569
TBR=palmer for browser_interface_binders.cc
Change-Id: Ia5c16982a0d914d2a1ee6d7c387206d0448d2d62
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2035984
Commit-Queue: Hans Wennborg <hans@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739395}
Disable API based fallback by default since there have been issues found
with matching style when performing API based fallback on Windows pre
Windows 10, as well as issues with selection of the UI-suffixed versions
of certain CJK fonts for fallback.
This reverts commit https://crrev.com/ce428e0197791b318f066a9d680cd254b05148fc.
This synchronises the repository with a kill-switch experiment
configuration which was already disabling this feature.
Bug: 976737, 1027724, 1047791, 1020454
Change-Id: Ie3d4b8a6d48fe4949db421c383bd0c0c16dd33d7
Tbr: kojii
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1948429
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739312}
This enum is going to be used as status code of operations
performed by the Storage Service. Convert it to a mojo enum so
that we can define mojo interfaces for service worker storage.
Bug: 1046335
Change-Id: Ie4cf45a5dc119cc6b9e454d31e680dce32084986
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2040790
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Commit-Queue: Kenichi Ishibashi <bashi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739244}
This applies to viz::OutputSurface::Reshape and
viz::SkiaOutputDevice::Reshape, their many many many sub-classes,
and to viz::BufferQueue::Reshape.
This value is still effectively treated as a bool -- we convert from
a bool to this value in viz::DirectRenderer::DrawFrame by selecting
either RGBA_8888 or RGBX_8888, and we convert from this back to a
bool by the new gfx::AlphaBitsForBufferFormat.
The next steps for this include
- Make viz::BufferQueue::Reshape use the format value from Reshape, and
remove the initialization parameter
- Plumb format to through glResizeCHROMIUM to gl::GLSurface, where
it can be used by gl::DirectCompositionChildSurfaceWin.
Bug: 1049334
Change-Id: I3f1d1402cac76bb7b399c247a84d2fe2b1cd6b84
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2040446
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#739242}
