Closed Bug 1623461 Opened 5 years ago Closed 4 years ago

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

Categories

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

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla80
Project Flags:
Fission Milestone M6b
Tracking Flags:
Tracking Status
firefox76 --- wontfix
firefox80 --- fixed

People

(Reporter: cpeterson, Assigned: mattwoodrow)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Bug 1623461 - Clear nsDocShell::mBlankTiming when providing an existing timing object from a process switch. r?jya
(deleted), text/x-phabricator-request
Details

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.

status-firefox76: --- → affected

I will take a look.

Assignee: nobody → alwu
Priority: -- → P3

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

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

Assignee: alwu → nobody
Component: Audio/Video → DOM: Navigation

Tracking WPT Fission bugs for Fission M6b (Q2)

Fission Milestone: M6 → M6b

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.)

Severity: normal → S3
Assignee: nobody → matt.woodrow
Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c49a40eece91 Clear nsDocShell::mBlankTiming when providing an existing timing object from a process switch. r=jya

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

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox80: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla80

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

(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?

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.

Flags: needinfo?(matt.woodrow)

(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.

Flags: needinfo?(matt.woodrow) → needinfo?(sefeng)

Ah you are right, sorry!

Flags: needinfo?(sefeng)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: