Skip to content

GitLab

T
tangled
Switch branch/tag
  1. 27 Nov, 2018 4 commits
    • Hiroshige Hayashizaki's avatar
      Reland: Add omt-worker-fetch/external/wpt/referrer-policy · 16f64c71
      Hiroshige Hayashizaki authored 
      Reland of https://chromium-review.googlesource.com/1330903
with renaming due to crbug/906964.

Bug: 835717, 880027, 906964
Change-Id: I0eeca00cc7a0db2cb2efb16588b0cf52c14883f0
Reviewed-on: https://chromium-review.googlesource.com/c/1344434
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: default avatarHiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610983}
      16f64c71
    • Scott Violet's avatar
      Revert "Start gpu channel and compositor mojo pipe collection eagerly" · b04f16c9
      Scott Violet authored 
      This reverts commit 66794d00.

Reason for revert: This breaks mash_browsertests. See https://crbug.com/908623

Original change's description:
> Start gpu channel and compositor mojo pipe collection eagerly
> 
> When a RenderWidget is frozen, its compositor is stopped. However when
> the main frame is being navigated, we want to start requesting mojo
> pipes for the gpu and display compositor immediately so that it can
> happen in parallel with the navigation loading.
> 
> Previously, we just always did this when creating a RenderWidget, and
> left them active when freezing the RenderWidget. After 678f025f
> however, we don't, and this causes time-to-first-pixels regressions
> on navigation.
> 
> So we add a WarmupCompositor() method to RenderWidget, and call this
> from RenderFrameImpl::CreateFrame() when it makes the provisional
> frame, and the WebFrameWidget, since we expect to make use of the
> main frame RenderWidget shortly.
> 
> Then, if RenderFrameImpl::FrameDetached() occurs, due to the
> navigation failing, we will AbortWarmupCompositor() to drop the
> mojo pipes instead of holding onto them indefinitely.
> 
> This recovers the loading regressions introduced, while also not
> allocating mojo channels for frozen RenderWidgets indefinitely.
> 
> In order to do this reasonably, we drop the "callback" from the
> request to RenderThreadImpl::RequestNewLayerTreeFrameSink so that
> it always returns something immediately. This way RenderWidget
> does not need to worry about having a task run to collect the
> new frame sink, and ordering with tasks from the compositor to
> collect it.
> 
> R=​piman@chromium.org
> 
> Change-Id: I6007e26e1622006652ce3619cdd080539d11e7b0
> Bug: 905191
> Reviewed-on: https://chromium-review.googlesource.com/c/1341073
> Commit-Queue: danakj <danakj@chromium.org>
> Reviewed-by: danakj <danakj@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Antoine Labour <piman@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#610909}

TBR=danakj@chromium.org,dcheng@chromium.org,sergeyu@chromium.org,piman@chromium.org

Change-Id: Ifadae837dd5dbd8c1c31212704c6ee88843bd0d1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 905191
Reviewed-on: https://chromium-review.googlesource.com/c/1351808Reviewed-by: default avatarScott Violet <sky@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610982}
      b04f16c9
    • Liquan(Max) Gu's avatar
      [UserTimingL3] Move mark API logic to performance-user-timing · 776ef981
      Liquan(Max) Gu authored 
      We have the Performance class and the PerformanceUserTiming class. The
Performance is used to connect different performance APIs, one of which is the
UserTiming's mark API. The PerformanceUserTiming should be the main part to
deal with UserTiming logic. Currently, too much UserTiming logic is stored in
Performance. We should move them to PerformanceUserTiming.

This CL is intended for the refactoring.

Bug: 738685
Change-Id: I77c3b685a1a7f6df49539f6661c41492f0a44b7f
Reviewed-on: https://chromium-review.googlesource.com/c/1348865Reviewed-by: default avatarNicolás Peña Moreno <npm@chromium.org>
Commit-Queue: Liquan (Max) Gǔ <maxlg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610981}
      776ef981
    • dpapad's avatar
      Settings WebUI: Fix a11y errors revealed by page/subpage animation changes. · ab0c2e92
      dpapad authored 
      For an unknown reason, the a11y tests currently miss these failures. These are
triggered somehow by the changes in an upcoming CL (1324915), maybe indicating
a timing issue in a11y tests (should be investigated separately,
filed crbug.com/907676).

Tests that are fixed:
 - SettingsAccessibilityTest.ABOUT_image_alt
 - SettingsAccessibilityTest.ABOUT_region
 - SettingsA11ySignOut.SIGN_OUT_button_name

This CL is in preparation of removing neon-animation from Settings WebUI.

Bug: 907333
Change-Id: I9fd7c03a5f1f6105b144403aa3fc358fcd4333e2
Reviewed-on: https://chromium-review.googlesource.com/c/1345127
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: default avatarScott Chen <scottchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610980}
      ab0c2e92
  3. 26 Nov, 2018 36 commits