New issue
Advanced search Search tips

Issue 805566 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 758385



Sign in to add a comment

[UserTimingL3] clean up the codes after UserTimingL3 become stable

Project Member Reported by maxlg@google.com, Jan 24 2018

Issue description

1.The codes include the flag logic of UserTimingL3 and the codes that simulate the behaviors of the old API for consistency.

2.Change the flag name from CustomUserTiming to UserTimingL3 and the test names, folder names.
 

Comment 1 by maxlg@google.com, Jan 24 2018

Blockedon: 758385

Comment 2 by maxlg@chromium.org, Apr 12 2018

Description: Show this description

Comment 3 by maxlg@chromium.org, Apr 12 2018

Description: Show this description

Comment 4 by maxlg@chromium.org, Apr 12 2018

Summary: [UserTimingL3] clean up the codes after UserTimingL3 become stable (was: [CustomUserTiming] clean up the codes after CustomUserTiming become stable)

Comment 5 by maxlg@chromium.org, Apr 12 2018

Description: Show this description

Comment 6 by maxlg@chromium.org, May 15 2018

https://chromium-review.googlesource.com/c/chromium/src/+/769932/8/third_party/WebKit/Source/core/timing/PerformanceBase.h#145

Tim, given that we are about to migrate to L3, do we want to remove all of this counter, including the navigation-timing types?
Cc: npm@chromium.org
Sounds reasonable to me.

Nicolas, can you think of any reason we should keep these around?

Comment 8 by npm@chromium.org, May 15 2018

Why were the counters added in the first place? If it was to determine whether to land UTL3 or not, then they can be removed. But if they are useful in determining whether UTL3 can break current usage, then we should keep them around a little longer.

Comment 9 by maxlg@chromium.org, May 15 2018

They were used to estimate the impact to the current users using L2. The use counter cares mostly about the edge case. i.e., passing an object or time into the L2 API which will be interpreted as strings. These are abnormal edge cases that shouldn't appear in correctly functioning programs as well.

Comment 10 by npm@chromium.org, May 15 2018

I'm not sure it's correct to say 'These are abnormal edge cases that shouldn't appear in correctly functioning programs as well.', otherwise why wouldn't we just fix the implementation? But if the UseCounters have served their purpose (prove that the cases where L3 is incompatible with L2 are almost never used) then removing SGTM.

Comment 11 by maxlg@chromium.org, May 15 2018

Sorry for the ambiguity, by correctly functioning programs, I meant users may misused the L2 user timing API by, for example, calling performance.measure('name', performance.now(), 'end'). These were the L2 edge cases, now L3 extend the functionality by changing the behaviors of these edge cases.
Project Member

Comment 12 by bugdroid1@chromium.org, May 17 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a383fbd435a731a4f270b6fb9072b8cafc30144b

commit a383fbd435a731a4f270b6fb9072b8cafc30144b
Author: Liquan(Max) Gu <maxlg@chromium.org>
Date: Thu May 17 16:59:52 2018

[UserTimingL3] Clean up L2 use counter of start & end argument

The following use counters was used to estimate the impact to the existing users
if introducing UserTiming L3:

Performance.PerformanceMeasurePassedInParameter.StartMark
Performance.PerformanceMeasurePassedInParameter.EndMark

Since we've gathered enough data, the use counter can be removed now. This
change is a reversion of
https://chromium-review.googlesource.com/c/chromium/src/+/769932

Bug: 805566
Change-Id: I22785c0b1766b5bce4f908c90725638eb8d2c274
Reviewed-on: https://chromium-review.googlesource.com/1059581
Reviewed-by: Nicolás Peña Moreno <npm@chromium.org>
Reviewed-by: Jesse Doherty <jwd@chromium.org>
Reviewed-by: Yuta Kitamura <yutak@chromium.org>
Commit-Queue: Liquan (Max) Gǔ <maxlg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559574}
[modify] https://crrev.com/a383fbd435a731a4f270b6fb9072b8cafc30144b/third_party/blink/public/platform/web_feature.mojom
[modify] https://crrev.com/a383fbd435a731a4f270b6fb9072b8cafc30144b/third_party/blink/renderer/core/timing/performance.cc
[modify] https://crrev.com/a383fbd435a731a4f270b6fb9072b8cafc30144b/third_party/blink/renderer/core/timing/performance.h
[modify] https://crrev.com/a383fbd435a731a4f270b6fb9072b8cafc30144b/third_party/blink/renderer/core/timing/window_performance_test.cc
[modify] https://crrev.com/a383fbd435a731a4f270b6fb9072b8cafc30144b/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/a383fbd435a731a4f270b6fb9072b8cafc30144b/tools/metrics/histograms/histograms.xml

Ping from bug triage. Is this done? 
It's still blocked (crbug/758385). The API has not fully upgraded to L3 yet. 
Cc: maxlg@chromium.org
 Issue 785430  has been merged into this issue.

Sign in to add a comment