sorry for the hasle, fixed the .ini file, hope bots will be green now

do i need todo anything further, to re-land it?

@valentin i am pretty new to firefox code, is there any better way to run the tests locally!? that verify it, or CI to catch it? it is all green, local and CI it lands and then fails :/

newest upload should fix the last revert-reason, and hopefully is a full-fix!

thanks in for your time and patience with me!

In D276668#9617131, @hjanuschka wrote:

@valentin i am pretty new to firefox code, is there any better way to run the tests locally!? that verify it, or CI to catch it? it is all green, local and CI it lands and then fails :/

newest upload should fix the last revert-reason, and hopefully is a full-fix!

thanks in for your time and patience with me!

I pushed your changes to try: https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=171585
Frequent contributors can apply for level 1 commit rights that allows them to trigger the tests in automation https://firefox-source-docs.mozilla.org/tools/try/index.html

Lacking that, you can build the changes on your own machine and run the tests that are most likely to be impacted:
or

I have found a minor bug in the implementation that needs to be fixed.
But otherwise I think you did a great job with this contribution. Thanks!

thank you! pushed an update! with your suggestion! hope its correct (phabricator is quiet complex, and everything feels so different to e.g. chromium 🙃)

Excellent. Thank you!
I'll push it to autoland. 🤞

thank you hop it sticks now! is there anything like AUTHORS or so where i'd need to add myself?

@valentin sorry that this is such a back and forth :( - could you try this patchset?

In D276668#9640836, @hjanuschka wrote:

@valentin sorry that this is such a back and forth :( - could you try this patchset?

Don't worry about the back and forth 🙂 It's part of the normal development cycle of any sufficiently complex piece of software.

When making updates to the patch, it would be good if you left a comment explaining what changed.
I think the failures on Android were due to the fact that we're setting both responseStart and finalResponseStart to a timestamp::now(), but if the device is slow enough (like android is sometimes), the timestamps will be different which leads to being true in FirstInterimResponseStartHighRes.
In this case, the fix is probably to make sure we use the same timestamp for mFinalResponseHeadersStart when there is no interim response.

Changes in this update:

1. is captured when the status line is FIRST parsed (in at line 2044)
2. now reuses the SAME timestamp as for final responses (at line 2085)

Code analysis found 3 defects in diff 1182741:

• 1 defect found by clang-format
• 2 defects found by clang-format (Mozlint)

You can run this analysis locally with:

For your convenience, here is a patch that fixes all the clang-format defects (use it in your repository with or ).

If you see a problem in this automated review, please report it here.

You can view these defects in the Diff Detail section of Phabricator diff 1182741.

https://treeherder.mozilla.org/jobs?repo=try&revision=7ddd563e4969008381f775d611d43476d5e9321c

In D276668#9663072, @valentin wrote:

https://treeherder.mozilla.org/jobs?repo=try&revision=7ddd563e4969008381f775d611d43476d5e9321c

@hjanuschka both WPT and xpcshell tests seem to be failing.

@valentin
hopefully fixed! Now sets both timestamps to same value for non-interim responses (avoids race on slow devices), and only sets finalResponseHeadersStart later for actual interim responses. HTTP/3 xpcshell tests pass locally

I did another try push. Hopefully this is green now https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=177134

@valentin - can you please kick off another run?
finally, i think i managed to run all the tests locally, and they pass.

@valentin asking for help here, webkit and chromium already shipped it and i am stuck in a nimbus of "idfk" - it says job failed but does not show me error
could you help me through this?

In D276668#9964612, @hjanuschka wrote:

@valentin asking for help here, webkit and chromium already shipped it and i am stuck in a nimbus of "idfk" - it says job failed but does not show me error
could you help me through this?

https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=185181

Hope this works. Sorry I missed the previous comment.

it fails again, but both of the errors dont really ring a bell for me :/ a bit lost on this change

@valentin really feeling bad about all this ping pong, could you PLEASE start it one more time, i thnk i found the missing test expectation updates?

No reason to feel bad about it. I'm really grateful for your contributions!

https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=188120 - mach try auto
https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=188121 - linux64 all wpt + xpcshell

@valentin again please, locally the da** wpt's now pass, is there any chance i could kick of bots on this changeset myself?

Summary

Intent

The changes implement the W3C Resource Timing Level 3 specification for interim response timestamps. Specifically, this adds two new properties — and — to the API. These properties allow web developers to distinguish between the timing of interim HTTP responses (1xx status codes, such as 103 Early Hints or 100 Continue) and the timing of the final HTTP response (2xx/3xx/4xx/5xx). This aligns Firefox's implementation with WebKit and Chromium, which already support these properties.

Solution

The implementation spans multiple layers of the Firefox codebase:

Network Layer (Timing Capture):

• Two new fields ( and ) are added to the used throughout the networking stack.
• In , when HTTP response headers are fully parsed, the code now checks the status code: if it's a 1xx response, it records the timestamp (only setting it once via the flag); if it's a final response, it records . The existing field is updated for backward compatibility — it's set to the first interim response time if one exists, otherwise to the final response time.
• The same interim/final timing logic is added to and to handle HTTP/2 and HTTP/3 protocols respectively.
• New getter and setter methods with mutex-protected access are added to .

Channel Layer (Propagation):

• IDL interface is updated (with a new UUID) to include the two new timestamp attributes in both and forms.
• , , and all implement the new getter methods, reading from either the live transaction or cached timing data.
• abstract interface and its implementations () are extended with the new virtual getters.

IPC Layer (Cross-Process Serialization):

• The IPDL message definitions () for both and are extended with the two new fields.
• serializes the new timestamps into IPC messages, and deserializes them back into the timing struct.
• The IPC serialization () is updated to read/write the new fields.

DOM Layer (Web API Exposure):

• gains the two new member fields and corresponding methods that convert timestamps to values (returning 0 when no interim response was received).
• exposes both properties using the existing TAO (Timing-Allow-Origin) protection macro, ensuring cross-origin timing information is properly restricted.
• The WebIDL definition for adds and as readonly attributes with annotation.

Tests:

• All previously-expected-to-fail WPT test entries for , , and the test files are removed, indicating these tests now pass.

In D276668#10061303, @hjanuschka wrote:

@valentin again please, locally the da** wpt's now pass, is there any chance i could kick of bots on this changeset myself?

https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=188385

If you're interested in contributing more following this patch you could apply for level 1 commit rights. see https://firefox-source-docs.mozilla.org/tools/try/configuration.html
That would allow you to push to try.

In D276668#10061303, @hjanuschka wrote:

@valentin again please, locally the da** wpt's now pass, is there any chance i could kick of bots on this changeset myself?

https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=188385

If you're interested in contributing more following this patch you could apply for level 1 commit rights. see https://firefox-source-docs.mozilla.org/tools/try/configuration.html

@valentin

not sure how frequently i'll contribute, but since i enjoy closing interop gaps, and i have a pretty good chromium track, i bet/hope there'll be some more ff changes in the near future.

filed a request: https://bugzilla.mozilla.org/show_bug.cgi?id=2026703

and could you run the jobs again?

@valentin friendly ping

@valentin may i ask you for a voucher for the level1 access?

In D276668#10185075, @hjanuschka wrote:

@valentin may i ask you for a voucher for the level1 access?

Vouched and pushed to try again. Sorry for the delay, I was on PTO the last week and a but swamped with bugmail.
https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod&landoCommitID=191873

@valentin really appreciate the voucher, and i somehow managed to "./mach try auto" but now i have 100's failing tests.
on your push, it was only a handfull unrelated, but i couldn't retry them (since i was not the job starter)

how did you start the bots?

sorry for hijacking the changeset for such questions, is there a slack/chat/whatever channel for ff devs?

In D276668#10202213, @hjanuschka wrote:

@valentin really appreciate the voucher, and i somehow managed to "./mach try auto" but now i have 100's failing tests.
on your push, it was only a handfull unrelated, but i couldn't retry them (since i was not the job starter)

how did you start the bots?

I also do ./mach try auto
If you post a link I could have a look.

sorry for hijacking the changeset for such questions, is there a slack/chat/whatever channel for ff devs?

Yes, feel free to ask in https://chat.mozilla.org/#/room/#necko:mozilla.org or https://chat.mozilla.org/#/room/#dev-help:mozilla.org

In D276668#10208390, @valentin wrote:

In D276668#10202213, @hjanuschka wrote:

@valentin really appreciate the voucher, and i somehow managed to "./mach try auto" but now i have 100's failing tests.
on your push, it was only a handfull unrelated, but i couldn't retry them (since i was not the job starter)

how did you start the bots?

I also do ./mach try auto
If you post a link I could have a look.

You can also do and select only one platform web-platform-tests
https://firefox-source-docs.mozilla.org/tools/try/index.html

@valentin

please take a look at this bot run: https://treeherder.mozilla.org/push-health/push?repo=try&revision=f82a9b2a7c1575cfde5f6f13c0848dc97e021bd1&tab=tests&testGroup=pr&selectedTest=event-timinglarge-duration-thresholdhtml&selectedTaskId=561088698&selectedJobName=event-timing%2Flarge-duration-threshold.html+test-windows11-32-24h2%2Fopt-web-platform-tests-9

the ones that still fail - are what looks like unrelated.

https://treeherder.mozilla.org/jobs?repo=try&revision=e95c4d767a36638b1c26bc2b96c41a18871c6037

@valentin could we try landing again?