GitLab

BUG=830885

Change-Id: Ie04ce7147d6e89e56d2608c928a49f89681829ef
Reviewed-on: https://chromium-review.googlesource.com/1003223Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549284}

This patch refactors the function, so that it uses distinct return paths
for in-bound and out-of-bound end offsets, so that the code flow logic
is cleaner.

Bug: 828719
Change-Id: I5c4553b4e5480a2fcf0b2496e0153f648c002bb3
Reviewed-on: https://chromium-review.googlesource.com/999160
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549283}

Bug: 819875
Change-Id: Ia2aa791fdc170121b3f2e7d5e43e4b79f5da33bb
Reviewed-on: https://chromium-review.googlesource.com/1003147Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Commit-Queue: Biao She <bshe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549282}

Since the size is always updated using update method, the listener
is not needed. Moreover, the listener might have wrong width and
height information that can't be used for updating the buffer size.

The listener can get called during the updating the autofill
options with invalid Width() and Height() values. As a result,
buffer size would be wrong and Chrome crashes.

Bug: 830471
Change-Id: Ie634241a591f60e2680e291b6fbdf65c9186093b
Reviewed-on: https://chromium-review.googlesource.com/1002871Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Commit-Queue: Amirhossein Simjour <asimjour@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549281}

When ARC session is restarted or closed, OnTaskDestroyed()
callback is not necessary send for all apps. Because of that
ArcKioskAppService continued to think that kiosk app is still running,
while it's not true.
Perfectly, instead of |if (!app_launcher_)| check in line 193,
it should check whether kiosk app is already running (and update taskid)
but there is no such function, so just re-setting internal state
on restart/close should work too.

BUG=830640

Change-Id: I8097e03000d0d9e21b672672cddaf3a91a1d3214
Reviewed-on: https://chromium-review.googlesource.com/1000455Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Yury Khmel <khmel@chromium.org>
Commit-Queue: Sergey Poromov <poromov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549280}

because we may be during changing the layer tree and
HasSelfPaintingLayerDescendant() may traverse the descendants.

Bug: 830179
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I091c60343d81a4286eb4ebada91bd1f8e3dd6289
Reviewed-on: https://chromium-review.googlesource.com/1002891Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549279}

Ensuring proper cleanup of the spare during browser shutdown
============================================================

To properly cleanup the spare renderer we need to:

1. Make sure it is subject to the fast shutdown path (even if it is
   still starting).  This way the spare will be subject to the
   fast shutdown initiated from chrome/browser/browser_shutdown.cc:

      void OnShutdownStarting(ShutdownType type) {
        ...
        // Call FastShutdown on all of the RenderProcessHosts.  This will be
        // a no-op in some cases, so we still need to go through the normal
        // shutdown path for the ones that didn't exit here.
        g_shutdown_num_processes = 0;
        g_shutdown_num_processes_slow = 0;
        for (content::RenderProcessHost::iterator i(
                content::RenderProcessHost::AllHostsIterator());
             !i.IsAtEnd(); i.Advance()) {
          ++g_shutdown_num_processes;
          if (!i.GetCurrentValue()->FastShutdownIfPossible())
            ++g_shutdown_num_processes_slow;
        }
        ...

2. Make sure the SpareRenderProcessHostManager calls CleanUp on the
   spare for which RenderProcessHostObserver::RenderProcessExited is
   called.


Enabling fast shutdown for currently-starting renderers
=======================================================

This CL removes the code that avoids fast shutdown for renderers that
are currently starting.  This code comes from
https://codereview.chromium.org/397031/patch/2029/2041 by jam@.

I feel confident that fast shutdown will be handled correctly for
renderers that are currently starting.  During the fast shutdown
RenderProcessHostImpl::ProcessDied will be called and reset
|child_process_launcher_| - this will correctly terminate the process
regardless of whether the process 1) has already been started or 2) is
in currently starting:

1. If the process has already been launched, then the destructor of
   ChildProcessLauncher will ensure process termination by eventually
   calling ForceNormalProcessTerminationSync.  This platform-specific
   method will kill the process.

2. If the process is being started, then ChildProcessLauncherHelper will
   eventually (once the process really starts) get the
   PostLaunchOnClientThread callback.  In the PostLaunchOnClientThread
   method we will check if the weak pointer to |child_process_launcher_|
   is still valid and if not, we will also terminate the process via
   ForceNormalProcessTerminationAsync.

   I realize that the above explanation depends on
   PostLaunchOnClientThread method being actually called.  I understand
   that this call might not happen if the browser process crashes.  The
   problem of ensuring child process termination in this case seems like
   an orthogonal, separate problem.

Supporting fast shutdown for currently-starting renderers means that
RenderProcessHostObserver::RenderProcessExited may be called earlier
(it is called by ProcessDied which is used on the fast shutdown path).
I think that such an earlier call is okay - I've tweaked the comments
for RenderProcessHostObserver::RenderProcessReady accordingly (removing
the mention of RenderProcessExited callback).


NOT enabling fast shutdown for not-yet-started or crashed renderers
===================================================================

This CL retains the behavior of NOT enabling fast shutdown for
not-yet-started or crashed renderers.  Such change would break tests
like ChromeRenderProcessHostTest.CloseAllTabsDuringProcessDied
on mac_chromium_rel_ng:

    [render_process_host_impl.cc(3743)]
    Check failed: !within_process_died_observer_.
        base::debug::StackTrace::StackTrace(...)
        logging::LogMessage::~LogMessage()
        content::RenderProcessHostImpl::ProcessDied(...)
        content::RenderProcessHostImpl::FastShutdownIfPossible(...)
        CloseWebContentses(...)
        TabStripModel::InternalCloseTabs(...)
        TabStripModel::CloseAllTabs()
        WindowDestroyer::RenderProcessGone(...)
        content::WebContentsImpl::RenderViewTerminated(...)
        content::RenderProcessHostImpl::ProcessDied(...)
        non-virtual thunk to content::RenderProcessHostImpl::OnChannelError()
        ...

Additionally, supporting fast shutdown for previously-crashed renderers
would also introduce a risk that RenderProcessExited might be called
twice - once when the process crashes and a second time when the process
is subject to the fast shutdown path.


Proper clean-up of a killed spare RenderProcessHost
===================================================

SpareRenderProcessHostManager holds the only reference to a spare
RenderProcessHost* (which otherwise has no IPC routes and a zero
ref-count).  Before this CL, SpareRenderProcessHostManager would
respond to RenderProcessHostObserver::RenderProcessExited call by
dropping the only reference to the spare - this would result in a leak
of the RenderProcessHost object.  After this CL,
RenderProcessHost::Cleanup is called, ensuring proper destruction of the
object in case of a crash or in case of a fast shutdown.


Consistent termination status during fast shutdown
==================================================

To ensure consistent termination status during fast shutdown
(i.e.  TERMINATION_STATUS_STILL_RUNNING) we need to tweak
ChildProcessLauncher::GetChildTerminationStatus to account for processes
that have not yet started.  Without this change Windows would see the
default termination status set in the constructor of
ChildProcessLauncher which would lead to a change in prerender final
status seen in the following callstack:

        prerender::PrerenderContents::SetFinalStatus
        prerender::PrerenderContents::Destroy
        prerender::PrerenderContents::RenderProcessGone
        content::WebContentsImpl::RenderViewTerminated
        content::RenderProcessHostImpl::ProcessDied
        content::RenderProcessHostImpl::FastShutdownIfPossible
        browser_shutdown::OnShutdownStarting
        Browser::OnWindowClosing
        BrowserView::CanClose
        views::Widget::Close
        BrowserCloseManager::CloseBrowsers
        BrowserCloseManager::TryToCloseBrowsers
        chrome::CloseAllBrowsers
        chrome::AttemptExitInternal

and consequently would lead to failures of the following browser tests
on Windows:

    PrerenderBrowserTest.PrerenderQuickQuit
    PrerenderBrowserTest.PrerenderInfiniteLoop


Bug: 808114
Change-Id: I0e1cb47eac0b59866d87b5b3c76aae95e6223760
Reviewed-on: https://chromium-review.googlesource.com/994290Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549278}

I can't figure out what the justification for this is.  Mac infobars are not 2
DIP different in size than views infobars.

BUG=none
TEST=none

Change-Id: Ib54e240c9bc529f3793714012c7317524b0aea71
Reviewed-on: https://chromium-review.googlesource.com/996899Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549277}

This allows us to control the final binary size by optionally including features.

We only want clients to import one umbrella header:
  #import <ChromeWebView/ChromeWebView.h>
To accomplish this, we generate the umbrella header based on the feature flags.

Binary size for Release-iphoneos with Cronet included:
+signin and +autofill: 20MB
-signin and -autofill: 15.5MB
+signin and -autofill: 16.7MB
-signin and +autofill: 19.6MB

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I2981b06812495d9b24b1d9630f010247a7ab1331
Reviewed-on: https://chromium-review.googlesource.com/980737
Commit-Queue: John Wu <jzw@chromium.org>
Reviewed-by: Hiroshi Ichikawa <ichikawa@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549276}

Currently, the frame/border around the VR browsing content window starts
off opaque, and later becomes transparent due to bindings. This makes
it start off transparent.

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_vr;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Iaaec76ef7b7ba4c8c54a55fc5a591327bb98d9f3
Reviewed-on: https://chromium-review.googlesource.com/1000517
Commit-Queue: Ian Vollick <vollick@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549275}

A better fix would be fix PhysicalDisplayAndroid.java, but given this is
fixed in JB MR1, I don't think it's worth the extra effort.

Bug: 829318
Change-Id: Ibe03c8392bf86b69322ff01f9ddf3c63396a161f
Reviewed-on: https://chromium-review.googlesource.com/1001707
Commit-Queue: agrieve <agrieve@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549274}

Bug: 830820
Change-Id: I80da487af6c8b8738dea00f13f2e3f782ec7150a
Reviewed-on: https://chromium-review.googlesource.com/1003138Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Commit-Queue: Tibor Goldschwendt <tiborg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549273}

https://chromium.googlesource.com/angle/angle.git/+log/6c59e4a156c3..bb52c523556e

$ git log 6c59e4a15..bb52c5235 --date=short --no-merges --format='%ad %ae %s'
2018-04-06 oetuaho Invariant declaration doesn't make a variable active

Created with:
  roll-dep src/third_party/angle
BUG=chromium:829553


The AutoRoll server is located here: https://angle-chromium-roll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
TBR=ynovikov@chromium.org

Change-Id: Ie3721859163572a63d911bc96afc473d9c44fdeb
Reviewed-on: https://chromium-review.googlesource.com/1003036Reviewed-by: angle-chromium-autoroll <angle-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: angle-chromium-autoroll <angle-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#549272}

Specifically, this includes metrics reported by ChromeOSMetricsProvider
in the system profile for UKM. The following fields will now be included:
- hardware.hardware_class
- hardware.internal_display_supports_touch
- hardware.bluetooth (and all the sub-fields)
- multi_profile_user_count

A note on the implementation: This reports the new short hardware class
field that is now reported to UMA (as of M67), as enabled by the kUmaShortHWClass
feature. This CL also improves this logic (both for UMA and UKM) by doing it
synchronously which is possible with the new implementation. The bluetooth data
is still retrieve asynchronously however - which is new for UKM service.

In addition, this CL fixes MetricsProvider initialization order in UkmService,
where previously the Init() call on providers was happening before providers were
added. This was not a problem before because the existing providers did not do
anything in Init().

This change also improe

Bug: 807663, 810872
Change-Id: I4b0dcb848e40a467a26feaf757f43aaf442be050
Reviewed-on: https://chromium-review.googlesource.com/996175
Commit-Queue: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549271}

Bug: 830853

Change-Id: I893b5d205d6f3e033e0d5cc7f95d4acc4391fd23
Reviewed-on: https://chromium-review.googlesource.com/1001475Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Dmitry Skiba <dskiba@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549270}

Better enterprise management detection. Detect additional OpenDirectory nodes and alternative identities. Filture out iCloud users.

Change-Id: I36e71f89928e180cfe257cae079a303fd8d7db74
Reviewed-on: https://chromium-review.googlesource.com/999263Reviewed-by: Sorin Jianu <sorin@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Boris Vidolov <borisv@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549269}

These tests cannot invoke Print via the share menu on iOS11, so they
are redundant with the tests in JSPrintTestCase.

BUG=825431,683280

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I0e9965dfddf1e49d583a5304d7392cd59ac63bca
Reviewed-on: https://chromium-review.googlesource.com/990533Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Rohit Rao <rohitrao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549268}

In monochrome webview mode onResourceLoaded currently rewrites all
resource ids inside resource arrays including system resource IDs. This
is a bug.

The first try to fix the bug (cl/952097) caused a performance regression
in webview startup so this is a different idea to fixing the same bug
that should hopefully not suffer from the same performance regression as
the previous.

Since resource IDs are sorted (so system resources are at the beginning
of the array).  This CL finds the index of the first non-system resource
ID and starts rewriting at that point.

NOTRY=true #win7_chromium_rel_ng extremely flakey

Bug: 821425
Change-Id: I9f6f3c517a8c09cbbefb9b584ab6f5bfc9c8477b
Reviewed-on: https://chromium-review.googlesource.com/999003
Commit-Queue: Mohamed Heikal <mheikal@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549267}

As per steimel@'s comment in crrev.com/c/991293 we should always
create the play button as we use it when the video element is
very small.

BUG=821961,821414

Change-Id: Icec781d0cd49529c72dd21c88d54727e81236890
Reviewed-on: https://chromium-review.googlesource.com/1000722
Commit-Queue: Becca Hughes <beccahughes@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549266}

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/da5abe6..aef0b3a

Bug: 806557, 829541, 830046
Change-Id: I2c1b6f58e8005094f3174b7c9a228a67ee2d379b
Cq-Include-Trybots: master.tryserver.chromium.win:win_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_angle_rel_ng;master.tryserver.chromium.angle:win_angle_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/996896
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549265}

We have evidence of DownloadCurrentCandidateOrAskFaviconService()
crashing due to current_candidate() being null, at least until recent
fixes.

Temporarily and as a precaution, we return early in case the problematic
scenario is reproduced. We suspect this condition is not reached in
trunk, but it's a simple workaround to cherry-pick.

Bug: 828196
Change-Id: I41e2236f341a9ed9e18a950540f096e9de42df0b
Reviewed-on: https://chromium-review.googlesource.com/1002093Reviewed-by: Peter Kotwicz <pkotwicz@chromium.org>
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549264}

These methods are now unused after removing the Bluetooth Classic
implementation of EasyUnlock.

R=khorimoto@chromium.org

Bug: none
Test: none
Change-Id: I5a2a30c7dbd83bc51441f7525030ea94526df32b
Reviewed-on: https://chromium-review.googlesource.com/1000728Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
Reviewed-by: Toni Barzic <tbarzic@chromium.org>
Commit-Queue: James Hawkins <jhawkins@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549263}

It pretends there is no history to query for or modify.
Chromevox calls only chrome.history.search

Bug: b/73383411
Test: local build

Change-Id: Ib46ea54b2a1d21faa380c5738c2cf84ad0244d94
Reviewed-on: https://chromium-review.googlesource.com/976336
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
Reviewed-by: Luke Halliwell <halliwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549262}

Also obsoletes some histograms. There is probably a lot more histograms
that we should remove in followups.

Bug: 788604
Change-Id: I263a3d6ab0fc612d38ea4ad794751f276cc37188
Reviewed-on: https://chromium-review.googlesource.com/999793Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549261}

This reverts commit 98d99996.

Reason for revert: <INSERT REASONING HERE>

Original change's description:
> Avoid crashes if all favicons already processed
> 
> We have evidence of DownloadCurrentCandidateOrAskFaviconService()
> crashing due to current_candidate() being null, at least until recent
> fixes.
> 
> Temporarily and as a precaution, we return early in case the problematic
> scenario is reproduced. We suspect this condition is not reached in
> trunk, but it's a simple workaround to cherry-pick.
> 
> TBR=pkotwicz@chromium.org
> 
> Bug: 828196
> Change-Id: I4cc78ba01780beb59ad01a7388062f6db93b864c
> Reviewed-on: https://chromium-review.googlesource.com/1000453
> Reviewed-by: Mikel Astiz <mastiz@chromium.org>
> Commit-Queue: Mikel Astiz <mastiz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#549053}

TBR=mastiz@chromium.org,pkotwicz@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 828196
Change-Id: I362142e484667d85c784a884c46a07494247e349
Reviewed-on: https://chromium-review.googlesource.com/1003152Reviewed-by: Mikel Astiz <mastiz@chromium.org>
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549260}

The new PasswordManagerProxy class is an abstraction over
chrome.passwordsPrivate, used to test the passsword settings page
bahaviour.

Bug: 802352
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I12fba7cfdb4405477adf49ccb64f64d4b30a3d93
Reviewed-on: https://chromium-review.googlesource.com/883621Reviewed-by: Hector Carmona <hcarmona@chromium.org>
Commit-Queue: Christos Froussios <cfroussios@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549259}

This removes the usage of const scoped_refptr<DecoderBuffer>& in
favor of passing by value and using std::move.

I was experimenting with replacing it with std::unique_ptr,
but there are quite a few copies currently, so keeping it
ref counted seems reasonable for now. The conversion is half
the work, so I just finished it instead of reverting.

This fixes production code and tests which needed fixing to
compile; most other unittests are left untouched in terms of
using std::move optimally. Where possible inner functions have
been converted to const DecoderBuffer& where the pointer is
never expected to be null. Long chains of multiple inner
functions were converted to const DecoderBuffer*.

BUG=none
TEST=passes bots.

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I390bc4e2fd8048e8c1c1f7725e0cc173bdd88850
Reviewed-on: https://chromium-review.googlesource.com/994058Reviewed-by: Kenneth MacKay <kmackay@chromium.org>
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549258}

Android's AccessibilityNodeInfo does not have a separate field
for the value of a text field, but it does have a "hint" field.

Suppose a text field has some accessible label - like a
aria-label or a placeholder. Previously Chrome exposed that
as the field's text if the field was empty, and the hint if
the field had user-entered text. This is confusing because
once the user starts entering text, the label jumps from the
text to the hint.

Instead, always expose the label as the hint, and let the
text be empty initially.

BUG=828969
TBR=aleventhal@chromium.org

Change-Id: I4052a811d645a42b3fecf8e2e1a4b089a7da75b8
Reviewed-on: https://chromium-review.googlesource.com/994132Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549257}

Trigger a refill for select field that were unsuccessfully filled when
their content changes to the fillable value.

Only happen if all of the following are present.
- The select options changes after a user triggered fill
- If it happens less than 2 seconds after the fill
- Once per page
- If the select was set to be filled initially
- If the form has the same "NameForAutofill"

Change-Id: I4861efaa05e73ef281355158c3d3d3fbfa63e182
Reviewed-on: https://chromium-review.googlesource.com/996571
Commit-Queue: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Reviewed-by: Roger McFarlane <rogerm@chromium.org>
Reviewed-by: Moe Ahmadi <mahmadi@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549256}

This DumpWithoutCrashing is not providing any further useful information
so we'll disable it for now.

Bug: 828422
Change-Id: I73a62d09b0755375d8b353e620b4627611e8cd7a
Reviewed-on: https://chromium-review.googlesource.com/1000019Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549255}

Also added mojo::InterfacePtr<>::IsExpectingResponse().

Bug: 672469, 792441
Change-Id: I9c508cafae84b393e226834c4236724d59641829
Reviewed-on: https://chromium-review.googlesource.com/998166
Commit-Queue: Olga Sharonova <olka@chromium.org>
Reviewed-by: Max Morin <maxmorin@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549254}

This is called every time the surface reference is added or removed. It
will be used in Viz DevTools to update the tree of surfaces.

Bug: 816802
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: Id07fc469a8fd395fac114dafb0d7c15e9809192d
Reviewed-on: https://chromium-review.googlesource.com/998411Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Illia Martyniuk <illiam@google.com>
Cr-Commit-Position: refs/heads/master@{#549253}

Now that the waterfall has been updated to use the latest WebView,
remove test filter entries that are no longer needed.

Bug: chromedriver:1295, chromedriver:1941
Change-Id: I0f35c3ad62a0b365ac1d204157c2624546f8d379
Reviewed-on: https://chromium-review.googlesource.com/1000542Reviewed-by: Jonathon Kereliuk <kereliuk@chromium.org>
Commit-Queue: John Chen <johnchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549252}

The "background_page" key in an extension's manifest is restricted
to manifest v1 extensions, which we are removing support for. Remove
the check in ChromeDriver that looks for this.

Bug: 816677
Change-Id: I6835fecc261a4dbf8d2dafec47e3e32acddf107c
Reviewed-on: https://chromium-review.googlesource.com/988135Reviewed-by: Jonathon Kereliuk <kereliuk@chromium.org>
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549251}

Control Flow Integrity [1] indirect call checking verifies that function
pointers only call valid functions with a matching type signature. It
can't verify dynamically resolved function pointers, instead store them
in ProtectedMemory and calls them using base::UnsanitizedCfiCall() to
disable cfi-icall checks.

[1] https://www.chromium.org/developers/testing/control-flow-integrity

BUG=771365

Change-Id: I79b4c8a2bb6b7a77ff35860e7d4f7ad226745dca
Reviewed-on: https://chromium-review.googlesource.com/1000426Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549250}

Manual review of IMAGE/IMAGE+TEXT failures of build 4675 in
fast/text. I skipped all "ellipsis" tests before assuming
they're real failures, but by looking into them, there were
some glyph position differences due to text shaping
improvements.

TBR=eae@chromium.org, mstensho@chromium.org
NOTRY=true

Bug: 591099
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: Ia85c9a976e24f8abeedf4d8f4440ed1d1425fc6f
Reviewed-on: https://chromium-review.googlesource.com/1003013
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549249}

Basically, this CL ensures that when Daydream's 2D-in-VR path is enabled
that we (almost) never show VR-supporting chrome activities in 2D when
the user is in headset, even if Chrome is launched with a 2D intent.

Intents sent to the 2D launcher that can be supported by VR rendering
are forwarded to the VR launcher when the user is in headset (intents
that aren't supported by VR rendering will still show in Daydream's
2D-in-VR rendering path). If a ChromeActivity that supports VR is
launched directly while in headset, we just add the Daydream category to
the intent and continue with intent processing as usual.

If, somehow, Chrome was launched in 2D, then resumed while in headset,
Chrome will still render using the 2D-in-VR flow. This is fine for now
as Chrome will still be usable, and this situation is very difficult to
get into, but the user will probably be confused :P


This CL also avoids showing the request to exit VR prompt when 2D-in-VR
is supported, favoring immediately switching to 2D rendering mode and
showing the dialog or launching the Activity that triggered the request,
then returning to VR rendering after returning to Chrome.

Bug: 826732
Change-Id: I1a09f201554e4e3171f5657b0fb667acc6f4c784
Reviewed-on: https://chromium-review.googlesource.com/999997Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Yash Malik <ymalik@chromium.org>
Commit-Queue: Michael Thiessen <mthiesse@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549248}

local-sdk.py used "gen.py" which was deprecated and removed from
Fuchsia.

Change-Id: I390c7458eb863e19167a6255db2aed6e9b8233c2
Reviewed-on: https://chromium-review.googlesource.com/1003077Reviewed-by: James Robinson <jamesr@chromium.org>
Commit-Queue: Kevin Marshall <kmarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549247}

Bug:830600
Change-Id: If56f9e005014061483dcaa2bc4d39abf8314f09e

NOTRY=true
TBR=eyaich@chromium.org
CC=hablich@chromium.org

Change-Id: If56f9e005014061483dcaa2bc4d39abf8314f09e
Reviewed-on: https://chromium-review.googlesource.com/1002923Reviewed-by: Ashley Enstad <ashleymarie@chromium.org>
Commit-Queue: Ashley Enstad <ashleymarie@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549246}

Following bot results are included.
4673 4677

5 lines were removed and 16 lines were deflaked by consecutive
results since 4639.

TBR=eae@chromium.org, mstensho@chromium.org
NOTRY=true

Bug: 591099
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: I63b7b166f023cb31777ffa840b5844b83b3d92fb
Reviewed-on: https://chromium-review.googlesource.com/1002414
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549245}