1623461 - navigation-timing/test_performance_attributes.sub.html.ini WPT FAIL with Fission

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Chris Peterson [:cpeterson]]

https://searchfox.org/mozilla-central/source/testing/web-platform/meta/navigation-timing/test_performance_attributes.sub.html.ini

if fission: FAIL

Comment 1

[Chris Peterson [:cpeterson]]

The DOM Fission team is relying on feature teams to debug and fix Fission failures in their tests. If the failure looks like a bug in Fission's DOM or IPC changes, you can send the bug back to me.

We're hoping to enable Fission for a subset of Nightly users in early Q3, so we would like WPT tests to be green for Fission by end of Q2. Whether a particular test failure actually blocks shipping Fission is up to the discretion of the feature team. You all would know better than the DOM Fission which test failures are most important.

You can enable Fission when running WPT tests locally using mach wpt --enable-fission.

Comment 2

[Alastor Wu [:alwu]]

I will take a look.

Comment 3

[Alastor Wu [:alwu]]

This bug is unrelated with media code which is related with performance-timing.

[1] https://www.w3.org/TR/navigation-timing/#dom-performancetiming-navigationstart

Comment 4

[Chris Peterson [:cpeterson]]

Tracking WPT Fission bugs for Fission M6b (Q2)

Comment 5

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 6

[Matt Woodrow (:mattwoodrow)]

Attachment: Bug 1623461 - Clear nsDocShell::mBlankTiming when providing an existing timing object from a process switch. r?jya

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c49a40eece91
Clear nsDocShell::mBlankTiming when providing an existing timing object from a process switch. r=jya

Comment 8

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/c49a40eece91

Comment 9

[Sean Feng [:sefeng]]

Matt, I still see the "navigationStart being late" issue in 20200702094606 Nightly build

Comment 10

[Matt Woodrow (:mattwoodrow)]

(In reply to Sean Feng [:sefeng] from comment #9)

Matt, I still see the "navigationStart being late" issue in 20200702094606 Nightly build

How are you testing this? Do you have a reduced testcase?

Comment 11

[Sean Feng [:sefeng]]

I missed your message, sorry Matt.

I just open a new firefox window, navigate to a page, and then doing performance.timing.navigationStart < performance.timing.connectStart in the console. And it always returns true for the first navigation.

Comment 12

[Matt Woodrow (:mattwoodrow)]

(In reply to Sean Feng [:sefeng] from comment #11)

I missed your message, sorry Matt.

I just open a new firefox window, navigate to a page, and then doing performance.timing.navigationStart < performance.timing.connectStart in the console. And it always returns true for the first navigation.

true or false? I think 'true' is the expected/correct result, right?

I think you also need to use <=, since it seems possible that they'll be the same (and frequently are in my local tests).

Using <=, I can't reproduce it ever being false, always true.

Comment 13

[Sean Feng [:sefeng]]

Ah you are right, sorry!