GitLab

This is a speculative fix for crash which happens on calling
respondToSelector: method on dangling web_controller_observer_ pointer.

BUG=486668

Review URL: https://codereview.chromium.org/1136753004

Cr-Commit-Position: refs/heads/master@{#329415}

BUG=369661
TEST=All tests remain green.

Review URL: https://codereview.chromium.org/1137773003

Cr-Commit-Position: refs/heads/master@{#329414}

Revert of Revert of Adjusts dragging logic to be less likely to trigger false positive switch from snapping to docking (patchset #1 id:1 of https://codereview.chromium.org/1128933005/)

Reason for revert:
This revert probably did not fix the flakiness. I suspect that a revert that actually ended up fixing the bots is this: https://codereview.chromium.org/1139943002.

I will re-land my original change.

Original issue's description:
> Revert of Adjusts dragging logic to be less likely to trigger false positive switch from snapping to docking (patchset #5 id:90001 of https://codereview.chromium.org/1127133003/)
>
> Reason for revert:
> I suspect this is causing a browser_tests failure on the bots:
>
> http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/2069
> https://build.chromium.org/p/chromium.webkit/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/1913
>
> Sorry!
>
> Original issue's description:
> > Adjusts dragging logic to be less likely to trigger false positive switch from
> > snapping to docking.
> >
> > This CL adjusts the logic which selects whether a window will be snapped to
> > half of the workspace width or will be docked at the end of the drag when the
> > window is dragged to the edge of the workspace in the special case of the dock
> > being visible. The CL makes it easier to snap a window to half the workspace
> > width in this special case (and harder to inadvertently dock the window)
> >
> > BUG=484877
> > TEST=None
> >
> > Committed: https://crrev.com/988c697aff35b3fd347dec35f2f2ac159c8328a9
> > Cr-Commit-Position: refs/heads/master@{#329268}
>
> TBR=pkotwicz@chromium.org,varkha@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=484877
>
> Committed: https://crrev.com/0d4f7d597774f7415f1aff374db498c8fbe88a9a
> Cr-Commit-Position: refs/heads/master@{#329301}

TBR=pkotwicz@chromium.org,dpranke@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=484877

Review URL: https://codereview.chromium.org/1140733002

Cr-Commit-Position: refs/heads/master@{#329413}

BUG=483627
TEST=unit_tests

Review URL: https://codereview.chromium.org/1128753003

Cr-Commit-Position: refs/heads/master@{#329412}

The khronos headers are present in GYP, but missing in GN, causing
the build using GN to fail when 'ozone_platform_gbm=true' is used.

BUG=487108

Review URL: https://codereview.chromium.org/1129713003

Cr-Commit-Position: refs/heads/master@{#329411}

Make sure we use the same file in all instances of VaapiWrapper.

Define a refcounted global instance of VADisplayState that is only initialized
(via vaInitialize()) once and destroyed upon release of the last refcount.
This ensures a single drm_intel_bufmgr per fd, and avoids the double-close
problem as seen in bug 464628.

Pipe a PreSandboxInitialization to open the render node before starting sandbox.

After this CL the VEA/VDA unittests need to invoke the PreSandboxInitialization
as well.

BUG=475250
TEST=verify HW video works on link (check histograms) and VDA/VEA unittests

Review URL: https://codereview.chromium.org/1137483002

Cr-Commit-Position: refs/heads/master@{#329410}

Previously it was split between the helper thread and
the main thread. Way back in the day it was only the
helper thread, but there was concern about thread-safety
and part of the process moved to the main thread,
straddling two threads. Now we move all the way back to
the main thread only.

This removes the need to have "WaitFor*Start" in the helper
thread. Otherwise the helper thread would post work to
the main thread, and wait. That makes it very risky w.r.t.
deadlock, since the main thread will join() the helper
thread as part of plugin teardown. We had a bunch of
workarounds like a timeout when waiting on the condvar.

The bad thing about main thread loads is that it blocks
the renderer from doing work (like animation) as the nexe
loads. However, since we bounce work to the main thread
anyway, we block right now without this CL already.
In a later CL we can take advantage of the sel_main_chrome
load status hook to know when the nexe load is about done,
and only then call-back into the plugin when the blocking
is minimized. Hook added here:
https://codereview.chromium.org/1090233003/diff/100001/components/nacl/common/nacl_renderer_messages.h

SRPC client connection is still done on the helper thread.
I'm not sure of the requirement, but it will block
indefinitely if we do that in the main thread so
I left that in the helper thread.

There's still a bunch of pnacl_translate_thread mutexes
and condvars and the *_subprocess_active flags left
in the pnacl_translate_thread. Haven't moved the
activeness tracking out so that's left as is.

BUG= 473474

Review URL: https://codereview.chromium.org/1128943003

Cr-Commit-Position: refs/heads/master@{#329409}

The usual channel for delivering onReceivedTitle (via updating title for
a NavigationEntry) doesn't work in the case of history navigations, because
WebContentsImpl silences no-op updates of entries titles.

Chrome Browser uses another event for updating the title in this case --
via WebContentsDelegate::LoadingStateChanged. This patch enables WebView to
use it as well.

Note that WebChromeClient.onReceivedIcon doesn't need to be re-sent, as
nobody seems to bother checking whether the icon update is a "no-op", so
updates on history navigations just work.

BUG=481570

Review URL: https://codereview.chromium.org/1126383005

Cr-Commit-Position: refs/heads/master@{#329408}

Remove --enable-spdy4 and --enable-npn-http command line flags that used to
force enable and disable both of HTTP/2 and SPDY/3.1, respectively.  They are
obsolete because
 * these protocols are not experimental any more,
 * they are enabled by default,
 * usage of disabling flag is very low and it is unlikely that these flags will
   ever be needed for debugging.

BUG=

Review URL: https://codereview.chromium.org/1130353003

Cr-Commit-Position: refs/heads/master@{#329407}

In particular, the IsValid method had a confusing dual purpose - it was
used both to sanity check the inputs, and to check whether the instances
returned by the Get methods were null (i.e. Get failed). It has been
split into is_null() and DCheckValid(). Note that having DCheckValid as
a method also gives better stacktraces than the old DCHECK(IsValid())
style, since stacktraces will indicate which check failed.

BUG=458592

Review URL: https://codereview.chromium.org/1131303002

Cr-Commit-Position: refs/heads/master@{#329406}

Summary of changes available at:
https://chromium.googlesource.com/chromium/blink/+log/ce7d951..2c4108a

TBR=dpranke@chromium.org

Review URL: https://codereview.chromium.org/1135983003

Cr-Commit-Position: refs/heads/master@{#329405}

Revert of Linux Aura accessibility is enabled only on GNOME desktops (patchset #15 id:280001 of https://codereview.chromium.org/1028553003/)

Reason for revert:
All linux perf bots red, failing on various blink_perf tests. Speculatively reverting this CL since several bisects pointed to it.

BUG=485590

Original issue's description:
> Linux Aura accessibility is enabled only on GNOME desktops
>
> Linux Aura accessibility is not enabled on desktops different than GNOME2.
> GNOME3 has deprecated gconf in favor of gsettings and dconf.
> AT-SPI (cross-platform framework that provides communication between AT
> and application) bus launcher has a property called org.a11y.Bus.IsEnabled
> that could be easily read by dbus call.
>
> In generall this patch adds an additional check to enable accessibility.
> When gconf is available use gnome's accessibility key otherwise
> org.a11y.Bus.IsEnabled property.
>
> BUG=472183,468989,468112
> TBR=stevenjb@chromium.org,jochen@chromium.org
>
> Committed: https://crrev.com/16e2d5a386e3ddd5be818a0d27610b1e9ee9c08e
> Cr-Commit-Position: refs/heads/master@{#328651}

TBR=dmazzoni@chromium.org,plundblad@chromium.org,l.gombos@samsung.com,jochen@chromium.org,stevenjb@chromium.org,dpranke@chromium.org,k.czech@samsung.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=472183,468989,468112

Review URL: https://codereview.chromium.org/1124173005

Cr-Commit-Position: refs/heads/master@{#329404}

BUG=483203

Review URL: https://codereview.chromium.org/1124203006

Cr-Commit-Position: refs/heads/master@{#329403}

Summary of changes available at:
https://chromium.googlesource.com/skia/+log/06f3647..0d5fd11

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
TBR=robertphillips@google.com

Review URL: https://codereview.chromium.org/1132493005

Cr-Commit-Position: refs/heads/master@{#329402}

The DRM platform doesn't support asynchronous page flips.

BUG=none

Review URL: https://codereview.chromium.org/1137053003

Cr-Commit-Position: refs/heads/master@{#329401}

This greatly reduces the variance in test execution time when running
in parallel on a heavily loaded bot, in which setTimeout becomes
increasingly unpredictable. These tests were quite sensitive to load -
they run 200 consecutive setTimeout calls with short timeouts, but if
the machine is under load it can take up to 1000 ms to call back to
a 50 ms setTimeout. This means the test would take 200 * 1000 =
200 seconds to run, but it obviously times out long before then.

Running with this patch, the tests reliably stay under 10 seconds of
execution time even under the most heavy load, which is a massive
improvement to reliability. The only risk I see with this patch is that
the tests will become more resource-hungry when there are resources
available, so maybe they will starve out other sensitive tests?

BUG=472087

Review URL: https://codereview.chromium.org/1132483003

Cr-Commit-Position: refs/heads/master@{#329400}

Setting |job_factory| to |NULL| seems unnecessary since it was being assigned right after.

BUG=None

Review URL: https://codereview.chromium.org/1134093002

Cr-Commit-Position: refs/heads/master@{#329399}

This is a follow-up patch for merging CacheStorageError and ErrorType:
https://codereview.chromium.org/1132683003

BUG=425505
TEST=n/a

Review URL: https://codereview.chromium.org/1138013002

Cr-Commit-Position: refs/heads/master@{#329398}

There's no special logic for this behavior in the Notifications
implementations that's not covered elsewhere. Given that the test
was timing out as well, let's remove them.

BUG=168976

Review URL: https://codereview.chromium.org/1136543004

Cr-Commit-Position: refs/heads/master@{#329397}

Revert of Don't create a sync node when updating an URL that wasn't typed. (patchset #1 id:1 of https://codereview.chromium.org/1126633005/)

Reason for revert:
Suspected to cause failure of
MigrationSingleClientTest.AllTypesIndividually
on Linux GN:

https://build.chromium.org/p/chromium.linux/builders/Linux%20GN/builds/28301

Original issue's description:
> Don't create a sync node when updating an URL that wasn't typed.
>
> TypedUrlChangeProcessor is a HistoryService observer and gets notified
> about changes to all addresses, not just typed ones. This means that
> when HistoryService::SetPageTitle() is called for a non-typed URL,
> TypedUrlChangeProcessor::OnURLsModified() will be triggered and,
> consequently, TypedUrlChangeProcessor::CreateOrUpdateSyncNode().
> As the name suggests, if the modified node was not previously present
> (because it was filtered out by ShouldSyncVisit() in OnURLVisited()),
> it would be created.
> End effect was that *all* URLs that had their title updated (which means
> every page that has a <title> tag) were synced, even if they were not typed.
>
> The solution is to return early in CreateOrUpdateSyncNode() if we detect
> that the URL in question has no typed visits.
>
> (Caused by https://codereview.chromium.org/1087773002/)
>
> BUG=
>
> Committed: https://crrev.com/3be1b71d63be98a42c0e98673ff35fcd4fc738ab
> Cr-Commit-Position: refs/heads/master@{#329370}

TBR=maniscalco@chromium.org,pvalenzuela@chromium.org,mpawlowski@opera.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1127353004

Cr-Commit-Position: refs/heads/master@{#329396}

Since decoder supports GetSupportedProfiles and v4l2 supports
ENUM_FRAMESIZES, this flag can be removed and use runtime detection to
get maximum resolution for a specified profile.

BUG=350197
TEST=manually test pass on peach_pit, peach_pi, nyan_big and veyron_jerry.

Review URL: https://codereview.chromium.org/1097913002

Cr-Commit-Position: refs/heads/master@{#329395}

Revert of Refactor the avatar button/icon class (patchset #14 id:320001 of https://codereview.chromium.org/1009403002/)

Reason for revert:
Very likely has caused the latest flakiness of
BrowserNonClientFrameViewAshTest.AvatarDisplayOnTeleportedWindow
and
BrowserNonClientFrameViewAshTest.AvatarMenuButtonHitTestOnChromeOS

on
ChromeOS dbg:

https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/2069

Original issue's description:
> Refactor the avatar button/icon class.
> Such that they are based on the same base class.
>
> BUG=452524
>
> Committed: https://crrev.com/56078ce434955a67159b59303f6691adb55d7ca1
> Cr-Commit-Position: refs/heads/master@{#329249}

TBR=noms@chromium.org,msw@chromium.org,yiyaoliu@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=452524

Review URL: https://codereview.chromium.org/1139943002

Cr-Commit-Position: refs/heads/master@{#329394}

Add some CHECKs to see if some of the hypotheses in http://crbug.com/486931#c3 (however unlikely they seem) could be right.
This is in line with https://www.chromium.org/developers/coding-style#TOC-CHECK-DCHECK-and-NOTREACHED-.

BUG=486931

Review URL: https://codereview.chromium.org/1139863003

Cr-Commit-Position: refs/heads/master@{#329393}

BUG=None

Review URL: https://codereview.chromium.org/1112493002

Cr-Commit-Position: refs/heads/master@{#329392}

Summary of changes available at:
https://chromium.googlesource.com/chromium/blink/+log/07bc404..ce7d951

TBR=dpranke@chromium.org

Review URL: https://codereview.chromium.org/1134903004

Cr-Commit-Position: refs/heads/master@{#329391}

This should have been part of https://codereview.chromium.org/1136493003.

BUG=419383

Review URL: https://codereview.chromium.org/1139913002

Cr-Commit-Position: refs/heads/master@{#329390}

This patch was autogenerated with https://codereview.chromium.org/1010073002/.

BUG=465354

Review URL: https://codereview.chromium.org/1127153003

Cr-Commit-Position: refs/heads/master@{#329389}

Replaces the DCHECK for validity of the upload url with an explicit runtime
check. If the check fails the client sends a FAILURE_INVALID_URL error to
DMServer and logs a message to the ui log.

BUG=480982

Review URL: https://codereview.chromium.org/1138063006

Cr-Commit-Position: refs/heads/master@{#329388}

[Smart Lock] Smart Lock branding in save password infobar should available only for signed in users and guarded by Finch.

Restrict new title for the smart lock infobar only to the signed in users, who belongs to experiment.

BUG=454815

Review URL: https://codereview.chromium.org/1134863002

Cr-Commit-Position: refs/heads/master@{#329387}

MessageLoopProxy is deprecated.
This basically does a search and replace:

MessageLoopProxy::current() -> ThreadTaskRunnerHandle::Get().

BUG=391045

Review URL: https://codereview.chromium.org/1130753002

Cr-Commit-Position: refs/heads/master@{#329386}

Summary of changes available at:
https://chromium.googlesource.com/chromium/blink/+log/a442694..07bc404

TBR=dpranke@chromium.org

Review URL: https://codereview.chromium.org/1123373006

Cr-Commit-Position: refs/heads/master@{#329385}

WebRTC 9146:9174
Changes: https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+log/6e78b8f..8052935

Libjingle 9147:9171
Changes: https://chromium.googlesource.com/external/webrtc/trunk/talk.git/+log/63f5a59..16f9a02

TBR=
BUG=

Review URL: https://codereview.chromium.org/1135213002

Cr-Commit-Position: refs/heads/master@{#329384}

Since each QuerySyncManager has its own cache, even a moderate
cache size expands to several hundred KB of memory usage. This makes
it slightly smaller to save some of that memory. It is believed
to be unlikely that the cache has to be big anyway.

In ad-hoc testing I've only seen 20 queries in total (unclear how
many of them were in parallel).

(This is alt #1 in bug 485536)

BUG=485536
R=reveman@chromium.org

Review URL: https://codereview.chromium.org/1138463003

Cr-Commit-Position: refs/heads/master@{#329383}

The only thing visible in the content area should be the "Turn on location in Android Settings" link.

BUG=486008

Review URL: https://codereview.chromium.org/1135773002

Cr-Commit-Position: refs/heads/master@{#329382}

BUG=440649

Review URL: https://codereview.chromium.org/1139723002

Cr-Commit-Position: refs/heads/master@{#329381}

BUG=485955
NOTRY=true

Review URL: https://codereview.chromium.org/1135213003

Cr-Commit-Position: refs/heads/master@{#329380}

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/2e4c5505..eaa355a9

Please follow these instructions for assigning/CC'ing issues:
https://code.google.com/p/v8-wiki/wiki/TriagingIssues

TBR=hablich@chromium.org,machenbach@chromium.org,yangguo@chromium.org,vogelheim@chromium.org

Review URL: https://codereview.chromium.org/1139893002

Cr-Commit-Position: refs/heads/master@{#329379}

BUG=484997

Review URL: https://codereview.chromium.org/1129323005

Cr-Commit-Position: refs/heads/master@{#329378}

This CL is took over from issue 1112573005 at patchset 30001 (http://crrev.com/1112573005#ps30001)

BUG=476688
TEST=*ImportController*

Review URL: https://codereview.chromium.org/1126043005

Cr-Commit-Position: refs/heads/master@{#329377}

Revert of Disabled WebRtcBrowserTest.CanSetupCallAndSendDtmf (patchset #1 id:1 of https://codereview.chromium.org/1133063002/)

Reason for revert:
The test should now work with the more aggressive v8 gc() after a gc fix in the test (https://codereview.chromium.org/1138073003/)

Original issue's description:
> Disabled WebRtcBrowserTest.CanSetupCallAndSendDtmf
>
> TBR=tommi
> BUG=486654
>
> Committed: https://crrev.com/fc57f2cec564c344e3e17023b41c008f574b65a7
> Cr-Commit-Position: refs/heads/master@{#329147}

TBR=henrika@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=486654

Review URL: https://codereview.chromium.org/1141533002

Cr-Commit-Position: refs/heads/master@{#329376}