Improve spec-compliance of Performance interfaces#45525
Closed
rubennorte wants to merge 2 commits into
Closed
Conversation
facebook-github-bot
added
CLA Signed
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D59911145 |
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D59911145 |
rubennorte
force-pushed
the
export-D59911145
branch
from
4ca94fd to
ec15f03
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D59911145 |
rubennorte
force-pushed
the
export-D59911145
branch
from
ec15f03 to
aeef9aa
Compare
Differential Revision: D59918519
Summary: Pull Request resolved: facebook#45525 Changelog: [internal] This makes several changes to the Performance API to align it closer with the spec: * Makes fields of `PerformanceEntry` and subclasses read-only. * Returns instances of the correct subclass of `PerformanceEntry` to observers. * Renames `HighResTimeStamp` as `DOMHighResTimeStamp` for alignment with the spec and native Additionally, I realized that the way we handle `performance.measure` is a bit problematic at the moment. When we call the function, we create a `PerformanceMeasure` instance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances of `PerformanceEntry` (not even `PerformanceMeasure`) with the resolved values. At the same time, the `PerformanceMeasure` instance we return doesn't resolve its `startTime` and `duration` based on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when calling `performance.measure`. Reviewed By: rshest Differential Revision: D59911145
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D59911145 |
rubennorte
force-pushed
the
export-D59911145
branch
from
aeef9aa to
c754e21
Compare
Contributor
|
This pull request has been merged in 2a91a70. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Changelog: [internal]
This makes several changes to the Performance API to align it closer with the spec:
PerformanceEntryand subclasses read-only.PerformanceEntryto observers.HighResTimeStampasDOMHighResTimeStampfor alignment with the spec and nativeAdditionally, I realized that the way we handle
performance.measureis a bit problematic at the moment. When we call the function, we create aPerformanceMeasureinstance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances ofPerformanceEntry(not evenPerformanceMeasure) with the resolved values. At the same time, thePerformanceMeasureinstance we return doesn't resolve itsstartTimeanddurationbased on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when callingperformance.measure.Differential Revision: D59911145