GitLab

BUG=635908

Review-Url: https://codereview.chromium.org/2566203002
Cr-Commit-Position: refs/heads/master@{#438098}

Reason for revert:
Test is no longer flaky.

Original issue's description:
> Disable flaky test
>
> ResourcePrefetchPredictorBrowserTest.LearningJavascriptAppendChild was
> detected to be flaky by chromium-try-flakes.
>
> TBR=lizeb@chromium.org
>
> BUG=673028
>
> Committed: https://crrev.com/8ae700640b7237af3acc10025827497be8376aab
> Cr-Commit-Position: refs/heads/master@{#437907}

TBR=asargent@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=673028

Review-Url: https://codereview.chromium.org/2575453002
Cr-Commit-Position: refs/heads/master@{#438097}

Chrome build fails when use_ozone is true.

R=sky@chromium.org, warx@chromium.org
BUG=496681

Review-Url: https://codereview.chromium.org/2562233002
Cr-Commit-Position: refs/heads/master@{#438096}

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

BUG=670836
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2552163003
Cr-Commit-Position: refs/heads/master@{#438094}

BUG=555132

Review-Url: https://codereview.chromium.org/2566873002
Cr-Commit-Position: refs/heads/master@{#438093}

These were added & used on the CrOS side, but not documented here.

BUG=599960

Review-Url: https://codereview.chromium.org/2572633002
Cr-Commit-Position: refs/heads/master@{#438092}

TBR=nasko@chromium.org,waffles@chromium.org
BUG=672652

Review-Url: https://codereview.chromium.org/2565853003
Cr-Commit-Position: refs/heads/master@{#438091}

FrameFetchContext is containing too many things. We'd like to slim it
down to hold basically only things that receive and handle notifications
from ResourceFetcher.

The methods for ClientHintsPreferences on FrameFetchContext is placed
there (I guess) just not to introduce dependencies from core/fetch to
core/loader, core/frame, etc. See
https://codereview.chromium.org/1189523015 which introduced this logic
initially.

----

Compatibility analysis:

It's safe to directly pass frame() to FrameClientHintsPreferencesContext
in FrameFetchContext::dispatchDidReceiveResponseInternal(). If the
passed ResourceFetcher is already clearContext()-ed, we never reach
dispatchDidReceiveResponseInternal(). So, we can assume that the
ResourceFetcher passed to updateFromAcceptClientHintsHeader() was
always not yet clearContext()-ed.

HttpEquiv::processHttpEquivAcceptCH() was passing document.fetcher()
to updateFromAcceptClientHintsHeader(). Document::m_fetcher is cleared
only in Document::shutdown(). Therefore, document.frame() being non-null
at the beginning of processHttpEquivAcceptCH() means that the Document
hasn't yet shutdown.

context().frame() call on document.fetcher() returns document.frame()
unless clearContext() was called. This is true even when
setImportsController() was called on the Document. This is clarified by
a separate CL https://codereview.chromium.org/2547843002/.

There're three callers of ResourceFetcher::clearContext(). One of them
is Document::shutdown(). So, we don't need to care it. The other cases
are:
- setImportsController() called by LinkImport::process() while
  Document::loader() is null
- DocumentLoader::detachFromFrame() was called

However, I think this behavior was not intended initially and was
introduced just accidentally as stated above.

R=yhirano@chromium.org
BUG=671533

Review-Url: https://codereview.chromium.org/2544933003
Cr-Commit-Position: refs/heads/master@{#438090}

Recast the conditionally-eager finalization of Animation objects - only
needed if the Animation object has a CompositorAnimationPlayer attached -
wrapping instead the player object inside an eagerly-finalized object.

By doing so, we remove the need to support explicit prefinalizer
registration.

R=haraken
BUG=673645

Review-Url: https://codereview.chromium.org/2570503002
Cr-Commit-Position: refs/heads/master@{#438089}

They're not doing anything specific to the ResourceFetcher but just
consulting the FrameFetchContext via ResourceFetcher. Especially,
didReceiveResponse() contains a lot of back calls to the ResourceLoader.
The logic should just be implemented inside the ResourceLoader.

defersLoading() is also removed since it's used only by the unit tests
and can be replaced by invocation of public method context().

Renamed unary didFail() to handleError() as it's not a WebURLLoaderImpl
implementation and therefore it's confusing that it has the "did"
prefix.

R=yhirano@chromium.org,japhet@chromium.org,tsepez@chromium.org,kinuko@chromium.org
BUG=669383

Review-Url: https://codereview.chromium.org/2533683002
Cr-Commit-Position: refs/heads/master@{#438088}

BUG=555132

Review-Url: https://codereview.chromium.org/2565173002
Cr-Commit-Position: refs/heads/master@{#438087}

Service executables don't live alongside other build artifacts, so in component builds
Windows doesn't normally know where to look for them at runtime. This overrides the
DLL search path temporarily before launching any service child process.

BUG=None
R=ben@chromium.org

Review-Url: https://codereview.chromium.org/2574653002
Cr-Commit-Position: refs/heads/master@{#438086}

Review-Url: https://codereview.chromium.org/2573673002
Cr-Commit-Position: refs/heads/master@{#438085}

BUG=669690
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2545243002
Cr-Commit-Position: refs/heads/master@{#438084}

Currently, ChromeVox sends all queued speech output to the speech panel.

This unfortunately causes performance issues.

For example, in Gmail, if ChromeVox sends ~500 utterances, which can happen if we have a large block of text (since we split on sentences), ChromeVox stops responding to key commands.

ChromeVox should stay responsive in any situation especially if a user taps on the control key repeatedly.

This change makes it so we only show the currently spoken text which gets around the potentially expensive calls to send text to the panel background page (which blocks).

BUG=672955
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2570593002
Cr-Commit-Position: refs/heads/master@{#438083}

- try to scroll to the view's bounding rectangle when a client requests make visible
- add switch as a checkbox (matched for that predicate)

BUG=673048

Review-Url: https://codereview.chromium.org/2572573002
Cr-Commit-Position: refs/heads/master@{#438082}

Implement FakePepperInterfaceGoogleDriveFs, and implement
FakeDriveURLResponseInfoInterface and FakeDriveURLLoaderInterface, which
FakePepperInterfaceGoogleDriveFs uses.  FakePepperInterfaceGoogleDriveFs
is going to be used by the unit tests of the future code.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_nacl_sdk;master.tryserver.chromium.mac:mac_nacl_sdk;master.tryserver.chromium.win:win_nacl_sdk

Review-Url: https://codereview.chromium.org/2538163003
Cr-Commit-Position: refs/heads/master@{#438081}

I noticed a lot of complex logic in content_layer.cc and
static_tab_scene_layer.cc that appears to do nothing useful anymore.  I
simplified it by:
1) Always detaching and reattaching the live and static sublayers
instead of trying to preserve the existing structure.  (There shouldn't
be any performance cost to this.)
2) Following a much simpler policy for positioning and clipping.  I
compared the behavior of the old and new logic in a variety of device
rotation, tab switcher and URL-bar-hiding scenarios, and I haven't
yet observed any regression.

BUG=662427

Review-Url: https://codereview.chromium.org/2566753004
Cr-Commit-Position: refs/heads/master@{#438080}

The shader cache code is going to move into //gpu/ipc/host. However, the
singleton is content only. So factor out the code that deals with the
singleton instance inside content.

BUG=604369

Review-Url: https://codereview.chromium.org/2565223003
Cr-Commit-Position: refs/heads/master@{#438079}

This also includes DevToolsSession::Dispatch utility method
which offers message to DevToolsManagerDelegate.

BUG=664683
TBR=pfeldman

Review-Url: https://codereview.chromium.org/2548263002
Cr-Commit-Position: refs/heads/master@{#438078}

I've root caused this and the problem was introduced in this CL:
https://codereview.chromium.org/2446053002

That CL moved the logic which reported the worker process launch from the
IPC Channel Connected method to an IO completion port listener.  This works
fine on un-official builds, however it breaks on official builds.  The
reason for the failure is that the remoting_desktop process on official
builds are signed and include 'UiAccess' in their manifest.  When the
launcher process uses ShellExecuteEx to launch the worker process in this
scenario, we actually see two processes get launched sequentially.  The
first starts and exists with error code 'STATUS_ELEVATION_REQUIRED' and
the second launches with the correct permissions.  This behavior worked
fine before as we listened for the connection to the IPC channel which
was done by the second, successful process launch.  With the new code,
we observed the first process launch, set up the Mojo channel for it, and
tried waiting on its process handle which exits immediately.  The second
process then starts and fails to connect to the Mojo channel.

I investigated whether UiAccess is truly required for the desktop binary
and I think that it is.  For the Ctrl+Alt+Del scenario, there are registry
keys that can be set which will require that flag.  For Alt+Tab, it is
possible that some windows might not be accessible if they have a high
high enough integrity level (+ UiAccess themselves).

So instead of removing the UiAccess flag, my approach is to listen for the
worker process creation and exit events.  I store the value of the last seen
worker process id and use that in our process launch detection code once the
launcher process exits.  This allows both un-official builds (which do not
require the extra permissions hop) and official builds will work consistently.

BUG=666992

Review-Url: https://codereview.chromium.org/2568983004
Cr-Commit-Position: refs/heads/master@{#438077}

Refactoring only, no observable change intended.

A test is added that fails if the continue statement were dropped, as
apparently there was no coverage for this.

Note: This CL is also a test for the WPT export process.

BUG=402376

Review-Url: https://codereview.chromium.org/2565183002
Cr-Commit-Position: refs/heads/master@{#438076}

Revert of Restrict transmission of external exp ids to signed in users. (patchset #6 id:140001 of https://codereview.chromium.org/2558913003/ )

Reason for revert:
Speculative revert for recent flakiness in
Contextual Search related test failures on
"Android Tests" bot:

https://build.chromium.org/p/chromium.linux/builders/Android%20Tests?numbuilds=100

e.g. https://build.chromium.org/p/chromium.linux/builders/Android%20Tests/builds/35779

I'm not very confident that this is the real
offender; if it's not, I will reland this CL.

Original issue's description:
> Restrict transmission of external exp ids to signed in users.
>
> Since external experiment ids are not based on Chrome's low
> entropy source, they do not have the same guarantees about
> not identifying a user as Chrome's variations. As such, we
> should only transmit them for signed in users, whose identity
> is already known by Google so there's no risk of identifying
> them through these headers.
>
> Note: The signed-in state checking in this CL is only done for
> web content area requests and not other internal requests,
> like to the suggestion service, where it treats the state as
> "not signed in". This is fine to do because variations service
> ids are still sent, which is what the other call sites are
> interested in.
>
> BUG=672532
> TBR=mpearson@chromium.org,mattm@chromium.org,donnd@chromium.org,afakhry@chromium.org
>
> Committed: https://crrev.com/9ed7b5611a61505c3dba734fe55b92211df3c2f6
> Cr-Commit-Position: refs/heads/master@{#437959}

TBR=jwd@chromium.org,mathp@chromium.org,treib@chromium.org,mmenke@chromium.org,mpearson@chromium.org,mattm@chromium.org,donnd@chromium.org,afakhry@chromium.org,asvitkine@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=672532

Review-Url: https://codereview.chromium.org/2569973002
Cr-Commit-Position: refs/heads/master@{#438075}

Revert of Add ubsan_no_recover_hack to missing ubsan builders. (patchset #1 id:1 of https://codereview.chromium.org/2538103002/ )

Reason for revert:
UBSan is noisy and can't be enabled for explicit crash behavior on builders. On ClusterFuzz, it will be still enabled to create testcases.

BUG=673488

Original issue's description:
> Add ubsan_no_recover_hack to missing ubsan builders.
>
> R=inferno@chromium.org, ochang@chromium.org, phajdan.jr@chromium.org
> BUG=669566
>
> Committed: https://crrev.com/a50c295543d07efaedd8534d117f3860a3df52e8
> Cr-Commit-Position: refs/heads/master@{#435317}

TBR=ochang@chromium.org,phajdan.jr@chromium.org,mmoroz@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=669566

Review-Url: https://codereview.chromium.org/2568883003
Cr-Commit-Position: refs/heads/master@{#438074}

This CL fixes some colors in MD History that were low contrast. It also
makes a bunch of colors consistent and pulls most colors into
shared_vars.html so we can better manage our vast color spectrum.

BUG=670836
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2549133003
Cr-Commit-Position: refs/heads/master@{#438073}

Changed EOverflowAnchor to an enum class and gave it an unsigned
underlying type.

Changing it to an enum class enforces better namespacing and code
practices. Adding the unsigned underlying type is pre-work for when the
class is eventually stored as an enum bitfield (it would be done in this
patch, except a presubmit warning already exists that prevents that. The
presubmit warning needs to be updated before that change can occur.)

This is also pre-work to move EOverflowAnchor to be generated in
ComputedStyleBase.

BUG=628043
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2561973002
Cr-Commit-Position: refs/heads/master@{#438072}

This patch marks a few tests that are being flaky as so.
Will try to find owners for these tests.

BUG=673632

Review-Url: https://codereview.chromium.org/2565233005
Cr-Commit-Position: refs/heads/master@{#438071}

This removes a bunch of calls which end up with a WebString pointing to
the global empty string, which was showing up in profiles.

BUG=348655

Review-Url: https://codereview.chromium.org/2555983003
Cr-Commit-Position: refs/heads/master@{#438070}

Flip quic flags by 12/12/2016 18:30 PST
https://codereview.chromium.org/2569703003/

relnote: Protected by --quic_fix_beta_last_max. Fix conservative decrease for n-connection emulation.
Merge internal change: 141565085
https://codereview.chromium.org/2569723004

relnote: Allow changing initial flow control window via connection options. Protected by --quic_large_ifw_options. Partially reverts internal change: 128225749
Merge internal change: 141507430
https://codereview.chromium.org/2569113002

rel-note: automated rollback of internal change 138108562
Merge internal change: 141469809
https://codereview.chromium.org/2566943003

relnote: Use event_time instead of ApproximateNow() in QUIC cubic code. Protected by --quic_use_event_time
Merge internal change: 141384938
https://codereview.chromium.org/2571643002

relnote: Remove unused QuicClock member of BbrSender.
Merge internal change: 141366593
https://codereview.chromium.org/2566333002

relnote: Non-functional change. Cleanup pg3 support for quic_packet_reader
Bring it more inline with Chromium source but cleanup the definition of
MMSG_MORE macro to exist in the header so that there's no violation of
ODR for QUicPacketReader class based upon inclusion.
Merge internal change: 141357226
https://codereview.chromium.org/2570703002

relnote: Protected by --quic_fix_cubic_bytes_quantization. Fix CubicBytes Quantization. iDue to an unfortunate ordering of operations in the actual "cubing" part of the CWND calculation, we were inadvertantly quantizing the congestion-window calculation.  (Note: The "reno" part of the cubic algorithm wis smooth and not quantized before.)  Switching the order of operations obviates the problem.
Additionally, removed parameterization from cubic_test.cc and
cubic_bytes_test.cc, because the parameterization was getting
unwieldy.  Instead, the parameters are controlled by command-line
flag.
Merge internal change: 141183279
https://codereview.chromium.org/2569873002/

BUG=

Review-Url: https://codereview.chromium.org/2566403002
Cr-Commit-Position: refs/heads/master@{#438069}

Add StyleDifference::needsPaintPropertyUpdate() to indicate a style
change directly needs paint property update, and set the flag on
changes of css clip, transform, etc.

Move two tests from their original directory into paint/invalidation.

BUG=645667
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2570463004
Cr-Commit-Position: refs/heads/master@{#438068}

BUG=665948

Review-Url: https://codereview.chromium.org/2563883002
Cr-Commit-Position: refs/heads/master@{#438067}

https://chromium.googlesource.com/external/github.com/catapult-project/catapult.git/+log/c69690acc34b..e6e0862c8165

$ git log c69690acc..e6e0862c8 --date=short --no-merges --format='%ad %ae %s'
2016-12-12 eakuefner [Telemetry] Increase timeout after sending SIGTERM

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

If the roll is causing failures, see:
http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel
TBR=catapult-sheriff@chromium.org

Review-Url: https://codereview.chromium.org/2571713003
Cr-Commit-Position: refs/heads/master@{#438066}

SSLClientCertificateSelectorCocoaTest.HideShow is failing on macOS Sierra,
blocking 10.12 rollout for Chrome. Fix this using the same refactor as seen in
r400627, which ignores mouse events instead of resizing the certificate selector
window when it's hidden.

BUG=650898

Review-Url: https://codereview.chromium.org/2559763003
Cr-Commit-Position: refs/heads/master@{#438065}

Revert of ash: Use system tray mojo interface to show system update tray icon (patchset #6 id:100001 of https://codereview.chromium.org/2558043006/ )

Reason for revert:
Broke compile on Google Chrome ChromeOS:

https://build.chromium.org/p/chromium.chrome/builders/Google%20Chrome%20ChromeOS/builds/26896

../../chrome/browser/component_updater/pepper_flash_component_installer.cc:94:3: error: no type named 'SystemTrayClient' in namespace 'chromeos'; did you mean simply 'SystemTrayClient'?
  chromeos::SystemTrayClient* tray = chromeos::SystemTrayClient::Get();
  ^~~~~~~~~~~~~~~~~~~~~~~~~~
  SystemTrayClient
../../chrome/browser/ui/ash/system_tray_client.h:27:7: note: 'SystemTrayClient' declared here
class SystemTrayClient : public ash::mojom::SystemTrayClient,
      ^
../../chrome/browser/component_updater/pepper_flash_component_installer.cc:94:38: error: no member named 'SystemTrayClient' in namespace 'chromeos'; did you mean simply 'SystemTrayClient'?
  chromeos::SystemTrayClient* tray = chromeos::SystemTrayClient::Get();
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~
                                     SystemTrayClient
../../chrome/browser/ui/ash/system_tray_client.h:27:7: note: 'SystemTrayClient' declared here
class SystemTrayClient : public ash::mojom::SystemTrayClient,
      ^
2 errors generated.

Original issue's description:
> ash: Use system tray mojo interface to show system update tray icon
>
> Change the flow so that Chrome explicitly asks ash to show the icon
> rather than having ash ask Chrome whether there is an update available.
>
> * Add ShowUpdateIcon to system_tray.mojom
> * Introduce update.mojom
> * Migrate ash to using ash::mojom::UpdateSeverity internally
> * Migrate update methods from SystemTrayDelegate to SystemTrayClient
> * Add a new SystemTrayClientTest and move existing Flash test there
>
> Also add docs for SystemTrayItem (used by TrayUpdate) since tray view
> vs. default view vs. detailed view always confuses me.
>
> BUG=647412
> TEST=chrome browser_tests, ash_unittests
>
> Committed: https://crrev.com/196ee3b66b3700733cecb8472d63d872d99e3783
> Cr-Commit-Position: refs/heads/master@{#438051}

TBR=msw@chromium.org,kerrnel@chromium.org,tsepez@chromium.org,waffles@chromium.org,sky@chromium.org,jamescook@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=647412

Review-Url: https://codereview.chromium.org/2568413002
Cr-Commit-Position: refs/heads/master@{#438064}

This CL introduces two changes in the restriction of FetchEvent.respondWith().

1. Allow responding to non-navigation requests which redirect mode is 'manual'
   with opaque-redirect responses.
   Ex:
     SW: self.onfetch = evt => { evt.respondWith(fetch(evt.request)); };
     Page: fetch(new Request("/redirect-url", {redirect: 'manual'}));
     Server: Returns a redirect response to somewhere.
     Before this CL: fetch() fails.
     After this CL: fetch() returns the opaque-redirect response.

2. Add a deprecation warning for responding to requests which redirect mode is
   not 'follow' with redirected responses. Not to suddenly break existing sites
   we allow responding to navigation requests with redirected responses and show
   two warning messages. One in the DevTools attached to the service worker from
   RespondWithObserver::responseWasFulfilled(). And one in the DevTools attached
   to the page tab from DocumentLoader::finishedLoading().

BUG=658249

Review-Url: https://codereview.chromium.org/2526343003
Cr-Commit-Position: refs/heads/master@{#438063}

That way, we don't have to consider the same RuleSet multiple times for
invalidation on active stylesheet update. This fixes a regression in
PerformanceTests/CSS/StyleSheetInsert.html which would have been
introduced by https://codereview.chromium.org/2557533005

This works because the same style element source text used multiple
times will make us use the same StyleSheetContents from the cache and
hence the same RuleSet for all 50 sheets added in that test. It's a bit
like cheating, but this will also make sure we don't invalidate for the
same RuleSet twice if we re-order stylesheets by removing/inserting a
style element where the CSSStyleSheet pointer will be different, but
the RuleSet stays the same.

R=sashab@chromium.org,esprehn@chromium.org
BUG=567021

Review-Url: https://codereview.chromium.org/2569733003
Cr-Commit-Position: refs/heads/master@{#438062}

ServiceWorker: Replace RegistrationCallback and GetRegistrationsCallback with CallbackPromiseAdapter

This is a cleanup CL and does not change behavior.

BUG=n/a

Review-Url: https://codereview.chromium.org/2564363002
Cr-Commit-Position: refs/heads/master@{#438061}

BUG=670180

Review-Url: https://codereview.chromium.org/2570503003
Cr-Commit-Position: refs/heads/master@{#438060}

R=yhirano@chromium.org
BUG=none

Review-Url: https://codereview.chromium.org/2572493002
Cr-Commit-Position: refs/heads/master@{#438059}