GitLab

This restores UMA reporting for failures in preparing HTTP contexts
and also adds UMA reporting for auth failures in LSO to keep balanced
with silent auth flow. Also fixes error when error page is not shown
in case of GAIA server returns error.

BUG=b/34111604
BUG=b/34108212
TEST=Manually on device. Simulated error case. Made sure that UMA
     is reported and expected error page is shown
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

BUG=678837

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

On Linux,  device scale factor is not set.
On Win, there is no API to offer hotspot of a cursor.
This cl addresses the above two problems.

BUG=676687

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

R=atotic@chromium.org,eae@chromium.org

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

[reland, refactor] - Move textInputInfo() and textInputType() from WebWidget to WebInputMethodController

This CL tries to reland the original CL https://codereview.chromium.org/2508363003
which was reverted since it was making WebViewInteractiveTest.Focus_FocusRestored
flake.

The issue in the initial attempt was that
WebFrameWidget::getActiveInputMethodController() would return nullptr when the
WebFrameWidget did not have page focus (m_imeAcceptEvents == false). This
assumption is not correct and resulted into reporting
ui::TEXT_INPUT_TYPE_NONE for TextInputState right after losing page focus, e.g.,
by moving focus from a <webview> to its embedder (in the reverted CL).

On the other hand, when WebFrameWidget does not have page focus, any IME calls
received from browser should be dropped. Specifically, by not doing so, a call
to WebInputMethodController::finishComposingText would lead to a second commit
for the last ongoing composition. This happens when switching tabs or moving
focus to another WebFrameWidget in OOPIFs. Returning nullptr for active
controller was used as the solution to this problem in the original CL that
landed WebInputMethodController (https://codereview.chromium.org/2333813002/).
This is however incorrect since an unfocused WebFrameWidget could still have
IME state such as TextInputState.

The new attempt will reland the reverted CL and fix the issues by:

    1- Returning WebInputMethodController iff there is a focused local frame
    inside WebFrameWidget. Page focus will not affect this value.

    2- Will not process IME events if RenderWidget::has_focus_ is false. This
    is achieved by adding a new method ShouldHandleImeEvents() which will
    return false when there is no WebFrameWidget or page focus.

This CL also adds a RenderWidgetTest to prevent future regressions of this kind.

BUG=629721

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

As the MediaSession spec changed from using event-listener-based
to callback-based fashion for media controls, we need to keep the
implementation up to date.

Spec PR:
https://github.com/WICG/mediasession/pull/159

BUG=675963

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

This was missed by https://codereview.chromium.org/2539973004

BUG=678600

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

SharedWorker service has a mechanism to forward a message sent from a document
to a worker. With this mechanism, a sender creates a nested IPC message and
sends it to the SharedWorker service in the browser process. The service
interprets the nested message and forwards it to an appropriate receiver.

This mechanism is available for any IPC messages but it has been used only for
worker connection message. If we use it only for one message type, we don't have
to manage such a complex mechanism. Therefore, this CL removes the mechanism and
uses a plain IPC message for connecting to a worker.

This simplification also makes it easier to mojofy SharedWorker.

BUG=612308

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

Driven by change: there is no point in doing the wrapping of
the tooltip text with RTL/LTR formatting, in case there is no view.
Simply bail out earlier.

BUG=

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

Revert of Don't post multiple task for executing blocked scripts. (patchset #2 id:20001 of https://codereview.chromium.org/2609763002/ )

Reason for revert:
Regression in test for time to first meaningful paint: https://crbug.com/678584

Original issue's description:
> Don't post multiple task for executing blocked scripts.
>
> We may post a lot of tasks for executing blocked scripts in the case
> where we insert multiple shadow trees each containing a style element.
> When we start parsing a style element, we mark it as blocking and
> unblock script execution after finishing parsing. Check if the previous
> task is active before posting.
>
> Found while measuring performance for issue 603621.
>
> BUG=603621
>
> Committed: https://crrev.com/26cb3bdcd2a353402b78b716862567226317dff0
> Cr-Commit-Position: refs/heads/master@{#441110}

TBR=pmeenan@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=603621

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

Replace

 if (ENABLE_MOJO_MEDIA_IN_BROWSER_PROCESS)

with

 if defined(ENABLE_MOJO_MEDIA_IN_BROWSER_PROCESS)

The former was working because some compilers predefine FOO to be 1 when
-DFOO is specified. For example:
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html

But I am not sure whether this is true for all compilers. Hence we
probably should not depend on it.

Long term, we should switch to use BUILDFLAG to avoid this.

TBR=mkwst@chromium.org
BUG=596252

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

 - Two IPCs, CreateNewWindow and ShowCreatedWindow, are made to be routed via
   the opener frame. Previously they were routed via the opener view.
 - CreateNewWindow (which is mojofied) stays put but its parameters change
 - ViewHostMsg_ShowView becomes FrameHostMsg_ShowCreatedWindow
 - The corresponding delegate methods move from RenderViewHostDelegate to
   RenderFrameHostDelegate, though the implementation stays in
   WebContentsImpl, which implements both interfaces.
 - Remove the RenderView opener_id parameter from the mojo CreateNewWindow
   params, it can be inferred from the RenderFrame id. This fixes a possible
   bad situation where an unrelated RV/RF route id pair could be supplied.
 - The pending WebContents list is made to be indexed by the main frame
   widget; this turns out to be cleaner than making it frame- based, since
   show() is an operation on the created RenderWidget.
 - The signature of ContentBrowserClient::CanCreateWindow changes to be
   frame-based, which necessitates retooling the android
   SingleTabModeTabHelper to be frame-based also.
 - The ViewMsg_Close message, which cleans up after UI-thread failure of the
   CreateNewWindow operation, is hoisted out to the outermost function where
   failure is possible, RenderWidgetHelper::OnCreateNewWindowOnUI. This
   addresses some possible RenderView leaks when e.g. window.open() races a
   navigation that destroys the opener. These races would have become more
   likely now that we're routing via the frame, since child frames can have a
   shorter lifetime than their RenderViewHosts.
 - The response to ShowCreatedWindow on the opener RenderFrame is a
   ViewMsg_Move_ACK on the openee RenderWidget. This IPC moves to
   WebContentsImpl::ShowCreatedWindow so that it can be sent via the openee
   RenderWidgetHost's IPC::Sender, rather than via the opener RenderFrame.

BUG=431769, 304341
TBR=alokp@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

Download.ActualBandwidth:
Download.PotentialBandwidth:
Download.BandwidthUsed:

  These metrics were being recorded on each network read and were
  assuming that the size of the buffer and the duration between the
  prior read completion event and this one were reliable indicators of
  bandwidth.

  In practice, recording on each read is noisy and not all
  useful when aggregated across all users. Also size_of_buffer /
  elapsed_time is not an indicator of potential bandwidth, which makes
  both the PotentialBandwidth and BandwidthUsed incorrect.

Download.DiskBandwidthUsedPercentage:

  Neither useful nor correct.

SB2.DownloadDuration:

  Was measuring the lifetime of a DownloadRequestCore object, which
  doesn't correspond to the duration of a download.

Download.InterruptedOverrunBytes:
Download.InterruptedUnderrunBytes:

  When reporting UMA, the code was incorrectly picking the histogram
  name. Hence the meanings of the two histograms were switched. Rather
  than deprecating, I switched the descriptions around. The names are
  henceforth a bit odd, but the description should clarify what they are
  measuring.

Download.WriteSize:
Download.WriteLoopCount:

  WriteSize and WriteLoopCount metrics aren't actionable. WriteSize
  depends on the buffer sizes involved and the data is too noisy to be
  useful. Likewise WriteLoopCount counts the number of attempts it takes
  to fully write out a buffer. This isn't actionable.

BUG=none

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

BUG=none

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

This has been the the application context for some time now, so there
is no point in storing it when we can use ContextUtils as needed.

BUG=678787

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

https://chromium.googlesource.com/chromium/src/+/495d8354acfb5

BUG=642454
TBR=robhogan@gmail.com

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

Revert of Delete Mac & Cairo skia::BitmapPlatformDevice impls (patchset #3 id:40001 of https://codereview.chromium.org/2611153002/ )

Reason for revert:
Revert in hopes of fix linux x64 bot: https://build.chromium.org/p/chromium.chrome/builders/Google%20Chrome%20Linux%20x64/builds/15545

Original issue's description:
> Delete Mac & Cairo skia::BitmapPlatformDevice impls
>
> We are no longer performing native drawing on these platforms, use the
> Skia placeholder instead.
>
> BUG=675977
> R=reed@google.com
> TBR=
>
> Review-Url: https://codereview.chromium.org/2611153002
> Cr-Commit-Position: refs/heads/master@{#441750}
> Committed: https://chromium.googlesource.com/chromium/src/+/ccdceaed36d07ad5ab6d5e504ece0459a4aeaddf

TBR=reed@google.com,robertphillips@chromium.org,fmalita@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=675977

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

Reland of Don't paint underline or selections over ellipsis in mixed-flow contexts (patchset #1 id:1 of https://codereview.chromium.org/2615843002/ )

Reason for revert:
This patch was not the culprit for the layout test failures.

Original issue's description:
> Revert of Don't paint underline or selections over ellipsis in mixed-flow contexts (patchset #3 id:40001 of https://codereview.chromium.org/2594983002/ )
>
> Reason for revert:
> Causes test failures on Win10 Win7 bots:
> https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Win10/builds/18739
>
> webkit_tests webkit_tests
>
> unexpected_failures:
> fast/forms/select/menulist-appearance-basic.html
> fast/forms/select/menulist-style-color.html
> fast/forms/select/select-selected.html
> fast/forms/select/menulist-width-change.html
> fast/forms/select/option-text-clip.html
> fast/forms/select/option-script.html
> fast/forms/select/option-strip-whitespace.html
> fast/forms/color/input-appearance-color.html
> fast/forms/select/select-dirty-parent-pref-widths.html
> fast/forms/select/select-initial-position.html
> fast/forms/select/menulist-deselect-update.html
> fast/forms/select/select-change-listbox-to-popup.html
> fast/forms/select/select-background-none.html
> fast/forms/select/menulist-update-text-popup.html
> fast/forms/select/select-baseline.html
>
> Original issue's description:
> > Don't paint underline or selections over ellipsis in mixed-flow contexts
> >
> > Also, ensure the selected text is painted correctly when an ellipsis is present
> > in a mixed-flow context (e.g. ltr text in an rtl container).
> >
> > BUG=642454, 642450, 642460
> > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
> >
> > Committed: https://crrev.com/8691b058b8f8570128d24b4af3c43b3e2c0151e4
> > Cr-Commit-Position: refs/heads/master@{#441486}
>
> TBR=eae@chromium.org,szager@chromium.org,robhogan@gmail.com
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=642454, 642450, 642460
>
> Committed: https://crrev.com/1142d494094d29842cf057bf032c0f3985d7060d
> Cr-Commit-Position: refs/heads/master@{#441599}

TBR=eae@chromium.org,szager@chromium.org,loyso@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=642454, 642450, 642460

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

Revert of Roll WebRTC 15911:15919 (5 commits) (patchset #1 id:1 of https://codereview.chromium.org/2617693003/ )

Reason for revert:
Revert in hopes of fixing linux x64. If doesn't fix it will revert revert http://build.chromium.org/p/chromium.chrome/builders/Google%20Chrome%20Linux%20x64/builds/15545

Original issue's description:
> Roll WebRTC 15911:15919 (5 commits)
>
> Changes: https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+log/af5a0a0..5445b07
>
> $ git log af5a0a0..5445b07 --date=short --no-merges --format=%ad %ae %s
> 2017-01-05 ehmaldonado@webrtc.org Reland of actor webrtc_perf_tests into several source_sets. (patchset #1 id:1 of https://codereview.webrtc.org/2613913002/ )
> 2017-01-05 ehmaldonado@webrtc.org GN: Refactor webrtc_nonparallel_tests and audio_tests to avoid crossing package boundaries.
> 2017-01-05 danilchap@webrtc.org Revert of Refactor webrtc_perf_tests into several source_sets. (patchset #5 id:100001 of https://codereview.webrtc.org/2609403002/ )
> 2017-01-05 mbonadei@webrtc.org Revert of Fixing package-boundary violation with srjar_deps (patchset #5 id:80001 of https://codereview.webrtc.org/2610823002/ )
> 2017-01-05 mbonadei@webrtc.org Fixing package-boundary violation with srjar_deps
>
> TBR=
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_archive_rel_ng;master.tryserver.chromium.mac:mac_chromium_archive_rel_ng
> BUG=
>
> Review-Url: https://codereview.chromium.org/2617693003
> Cr-Commit-Position: refs/heads/master@{#441751}
> Committed: https://chromium.googlesource.com/chromium/src/+/01b8456652e46cc732b7d9282f07fca6e4c99d00

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

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

Previously, layer titles found their way into the resource manager
as ANDROID_RESOURCE_TYPE_DYNAMIC_BITMAP and were left there forever.
Over time, these recources accumulated (easily reproducable by
entering and exiting the tab switcher) and is more than likely the
cause of memory related crashes when entering the tab switcher.
The title layer itself was removed from the LayerTitleCache but the
resources that constitute the title were never correctly managed.

This change adds a function to the ResourceManager that allows the
LayerTitleCache to remove associated resources. Specifically, only
dynamic bitmaps can be manually removed.

BUG=669348

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

BUG=648510

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

It's unused already.

BUG=625089

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

Unfortunately, due to the way this code relies on posting a delayed
tasks that gets run at a later time, writing a unit test is very
difficult.

BUG=678659

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

This API was only being used by tests and most call sites were using it
incorrectly. Calling RemoveAllDownloads() immediately after creating a
DownloadManager is guaranteed to do nothing. Any new or persisted
downloads are added by some other entity asynchronously long after the
the DownloadManager has been created. In Chrome a DownloadManager starts
out empty until the downloads history DB is succuessfully queried.

In addition, this API is quite likely to do the wrong thing. A real
browser would need to pick and choose which downloads it wants to remove
based on whether the downloads are currently in progress or not -- which
is why Chrome was not using this API.

As a side-effect of removing the API, we can also remove the
Download.ClearAllSize UMA metric.

BUG=none

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

Inform the scheduler on resuming activites, so fetching of new
snippets consider this event.

(There is a related CL that triggers a similar event for new tabs:
https://codereview.chromium.org/2592053004/)

BUG=676308

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

DevTools: do not subscribe to global object events from the widgets that are not necessarily disposed.

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

SpellCheckTest.SpellCheckSuggestions_EN_US times out flakily on
Windows Debug. Disable the test on those builds.

TBR=groby@chromium.org
BUG=678753

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

BUG=676391

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

Previously suggestions that are a subset of another suggestion are not
deduped.

With this patch, only the most complete version will be suggested to
the user.

A side-effect of this change is that ContactDetails are now sorted by
relevance in regards or the information required from the merchant
instead of completeness.

For example, considering a profile A with only email and a profile B
with email and phone, and a merchant requires email, phone and name.
Previously the order between A and B would have been decided by
frecency since both were incomplete. With this patch, B would be
suggested first since it has more information.

BUG=674647

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

Fixes a regression where --debug-devtools erroneously no longer used the debug version
of devtools (e.g. minified / unbundled).

Also added an npm command to debug test: "npm run debug-test inspector/test-name.html"

BUG=none

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

Gtk3.20 added CSS names and changed a bunch of widget's classes to be
names instead.  This CL adds a runtime check for Gtk3.20 and uses
names for newer versions, and classes otherwise.  Unfortunately we
must load the symbol for setting the object name dynamically since we
still need to support Gtk3.10 (on Trusty).

BUG=132847
R=erg@chromium.org

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

If there are multiple surfaces from the same FrameSinkId that have
temporary references we might not remove one of the temporary
references.  We track the temporary references in DisplayConfigurator
and remove them when a real reference is added. An iterator is
incremented twice in some cases and we stop tracking one extra temporary
reference we never removed. DisplayCompositor no longer knows about the
temporary reference, so it never gets removed.

BUG=none

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

BUG=624175

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

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

if an initialization error occurs while creating an audio stream.

BUG=678697
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

https://pdfium.googlesource.com/pdfium.git/+log/e4d611c9c6d8..48f776f7e801

$ git log e4d611c9c..48f776f7e --date=short --no-merges --format='%ad %ae %s'
2017-01-05 npm Remove unused CPDF_ImageCacheEntry::GetCachedBitmap
2017-01-05 tsepez remove unused CFX_PtrToInt32 typedef

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

TBR=dsinclair@chromium.org

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

Since both targets require ARC and //ios/chrome/browser/ui has a
public_deps on //ios/chrome/browser/ui:ui_arc, the separation is
no longer necessary.

BUG=624363

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

The code fixes the bug referenced by the bug field. If requested fps is 15 and
the camera supports fps ranges 0 - 30, 10 - 20, 14 - 16 and 15 - 15. Previously,
we would choose 15 - 15 fps. This is bad because it doesn't leave the camera
room to adjust based on the lighting conditions. Heuristic copied from WebRTC
chooses the 10 - 20 fps range instead.

BUG=630266

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

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

Reland of "Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces with embeded content."

- Use SurfaceLayers in embedders and Window Manager to properly position
  the embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead
  they are submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level
  window rather than recursively creating SurfaceDrawQuad for all windows
  in the window tree, since all surfaces are now part of the tree rooted
  at the surface of the top-level window.

Previously landed in crrev.com/441492, but reverted in crrev.com/441522
since it broke some tests on Windows. This CL includes a fix for that
brokenness.

BUG=672943, 669964
TBR=jbauman@ for DEPS change (previously lgtm'ed in the original CL)

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