Closed Bug 1724645 Opened 1 year ago Closed 5 months ago

Update PerfomanceMark APIs to User Timing L3

Categories

(Core :: DOM: Performance, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
101 Branch
Tracking Status
firefox101 --- fixed

People

(Reporter: saschanaz, Assigned: mcomella)

References

Details

Attachments

(6 files, 1 obsolete file)

Currently they return nothing.

This change happened in User Timing L3. https://github.com/w3c/user-timing/pull/46

Blocks: 1581705

Performance APIs tend to be tracked in the Performance component.

Component: DOM: Core & HTML → Performance

The intro says:

Performance work items and bugs requiring action by the Firefox Performance team

Not sure this is true here or there should be DOM::Performance? Or maybe the text should be revised.

The performance team uses Core::Performance to track all performance-related bugs which include Performance API, I believe this is the right component :)

Priority: -- → P3

Cool, do you happen to know who can modify the component description? I think it would be useful to add "including DOM Performance API", but ignore me if you think otherwise 😉

Flags: needinfo?(sefeng)

I wouldn't be against adding that to the description, however, I am not sure how and who should make the call...

Kim, do you mind read comment 4 and see what we could do here?

(Keeping my NI for the changes of this bug)

Flags: needinfo?(kmoir)

I will defer to Patricia on this

If you want to make this change, I believe you need to open a bug in BMO Administration

https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration

Flags: needinfo?(kmoir) → needinfo?(plawless)

Sure, it makes sense to update the description. I filed this bug to do that: https://bugzilla.mozilla.org/show_bug.cgi?id=1727570

Flags: needinfo?(plawless)
Assignee: nobody → michael.l.comella
Flags: needinfo?(sefeng)

We can't land the pieces of making PerformanceMark support L3 individually (this bug, bug 1758749, bug 1759203) because tests fail in between that we can't suppress so I'm repurposing this bug to do all of PerformanceMark L3 at once.

Summary: performance.mark()/measure() should return PerformanceMark/PerformanceMeasure → Update `PerfomanceMark` APIs to User Timing L3
Duplicate of this bug: 1758749
Duplicate of this bug: 1759203

The web standard linked from MessagePort.webidl doesn't make it quickly clear
what StructuredSerializeOptions is used for so I added a brief summary to make
it quicker to figure out. Note: I don't have much experience with this class so
my description may be incomplete.

To follow the spec more closely, some functionality moved from
performance.mark to the PerformanceMark constructor.

Depends on D142624

In the existing code, these tests will pass if detail is a nonsense value, like
undefined, e.g. since undefined does not equal the original value. The code I
added makes sure the values are accurate too. This pattern already existed in
the first test in the file.

Depends on D142626

Attachment #9267274 - Attachment is obsolete: true

This is mostly complete. I just need to figure out:

  • how to handle shouldResistFingerprinting()
  • if some tests are worth adding
Attachment #9270326 - Attachment description: WIP: Bug 1724645 - document StructuredSerializeOptions. → Bug 1724645 - document StructuredSerializeOptions. r=sefeng
Attachment #9270327 - Attachment description: WIP: Bug 1724645 - update PerformanceMark to User Timing L3. → Bug 1724645 - update PerformanceMark to User Timing L3. r=sefeng
Attachment #9270328 - Attachment description: WIP: Bug 1724645 - add negative PerformanceMark startTime User Timing test. → Bug 1724645 - add negative PerformanceMark startTime User Timing test. r=sefeng
Attachment #9270329 - Attachment description: WIP: Bug 1724645 - make structured-serialize-detail tests more robust. → Bug 1724645 - make structured-serialize-detail tests more robust. r=sefeng

This test tests for a bug I discovered in my code that would crash the browser
if certain User Timing APIs were called on the dying iframe global.

I created a new test, rather than using test_performance_user_timing.html,
because it seemed like the code I added to set up the iframe did not easily fit
into the testing model of test_performance_user_timing.

Depends on D142900

Attachment #9271342 - Attachment description: Bug 1724645 - add test_performance_user_timing_dying_global.html. r=sefeng → Bug 1724645 - add WPT user-timing/dying_global.html. r=sefeng
Summary: Update `PerfomanceMark` APIs to User Timing L3 → Update PerfomanceMark APIs to User Timing L3
Component: Performance → DOM: Performance
Attachment #9271342 - Attachment description: Bug 1724645 - add WPT user-timing/dying_global.html. r=sefeng → Bug 1724645 - add test_performance_user_timing_dying_global.html. r=sefeng
Pushed by mcomella@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b9c1829dd475
document StructuredSerializeOptions. r=smaug
https://hg.mozilla.org/integration/autoland/rev/139ce1e88b31
update PerformanceMark to User Timing L3. r=sefeng,smaug
https://hg.mozilla.org/integration/autoland/rev/ff1c5530b65e
add negative PerformanceMark startTime User Timing test. r=sefeng
https://hg.mozilla.org/integration/autoland/rev/26467e1f89ca
make structured-serialize-detail tests more robust. r=sefeng
https://hg.mozilla.org/integration/autoland/rev/ddc932dd3d80
add tests for 'new PerformanceMark' in WPT mark-errors. r=sefeng
https://hg.mozilla.org/integration/autoland/rev/69f82055f891
add test_performance_user_timing_dying_global.html. r=sefeng,smaug
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/33797 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.