1915589 - fanczs.com - The page does not load

Status: RESOLVED FIXED

(Core :: DOM: Performance APIs, defect, P3)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 129.0.1 (release)

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://mmo.fanczs.com/scs/home
2. Observe

Expected Behavior:
The page loads

Actual Behavior:
Blank page

Notes:

• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

---

Created from webcompat-user-report:f724d713-6718-462b-93a4-c4a59009b746

Comment 1

[Ksenia Berezina [:ksenia]]

Seeing this error in the console:

Uncaught TypeError: PerformanceObserver.observe: Can't call observe with both `type` and `entryTypes`

Comment 2

[Jeff Muizelaar [:jrmuizel]]

The call to observe looks like: .observe({entryTypes:["resource"],buffered:!0} which the spec says should throw a TypeError. https://w3c.github.io/performance-timeline/#observe-method

We should check if Chrome throws an exception in this case.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Attachment: Reduced test case

Chrome and Safari both don't throw on this test case. We should either update the spec and implementation or get Chrome and Safari to fix theirs.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Hiro, thoughts on what we should do here?

Comment 5

[Hiroyuki Ikezoe (:hiro)]

The buffered argument was added after I implemented the initial v1 spec, so I didn't know about it at all, thus I learned the background.

From what I can tell is the best thing we can do here is to reach out the web site author and ask to stop calling observe() both with entryTypes and buffered.

There's a chromium bug that they have been struggling to change their behavior to throw an exception. It looks to me they've waited for a state where the incorrect usage drops, I am not sure what the threshold of the usage percentage is.

CCing npm@chromium who wrote the spec change for the buffered support.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:twisniewski, since the bug has high severity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Noam Rosenthal]

Noam from Chromium here. The usage is still at ~0.12%. I think the easiest path forward here would be to change the spec.

Comment 8

[Noam Rosenthal]

(In reply to Noam Rosenthal from comment #7)

Noam from Chromium here. The usage is still at ~0.12%. I think the easiest path forward here would be to change the spec.

Sorry, apparently it's on the interop list, will see where that goes.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Hiro, it doesn't sound like Chrome is very likely to change behaviour soon. Can we align our behaviour with Chrome for now and sort things out later as needed.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

I personally think we can. But I'd like to defer the decision to DOM team since I am not sure what the final judge of the interop issue was made.

Hsin-Yi?

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #10)

I personally think we can. But I'd like to defer the decision to DOM team since I am not sure what the final judge of the interop issue was made.

Hsin-Yi?

Sorry for another NI bounce, as I wasn't involved in the interop issue discussion and I think James may know better given he created that GH issue.

Comment 12

[James Graham [:jgraham]]

If we think we need to change behaviours we should do that and not worry about implications for Interop. In practice if that issue is accepted in Interop, and we think the spec as written is not web compatible, that would cover the work needed to align the spec and tests on the defacto required behaviour.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Thank you James. Your comment cleared our my concerns. I am going to post a patch with a (tentative) web-platform test. Thanks!

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1915589 - Allow co-existing entrypTypes and buffered options in PerformanceObserver.observe() method. r?sefeng

It's allowed, but the buffered option is ignored. This is what Blink
does [1], what WebKit does [2]. (Both code blocks are inside the else
branch of if has entryTypes)

The web-platform-test in this change was originally copied from
buffered-flag-after-timeout.any.js and modified.

[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/performance_observer.cc;l=264-273;drc=78780a188fe3c79fe815b170f4ea33e62ceb6e04
[2] https://searchfox.org/wubkat/rev/6c800745251d53d6486443d63b35828504446c5d/Source/WebCore/page/PerformanceObserver.cpp#90-100
[3] https://searchfox.org/mozilla-central/rev/e24277e20c492b4a785b4488af02cca062ec7c2c/testing/web-platform/tests/performance-timeline/buffered-flag-after-timeout.any.js

Comment 15

[Hiroyuki Ikezoe (:hiro)]

I opened a spec issue; https://github.com/w3c/performance-timeline/issues/215

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fb9d78b72655
Allow co-existing entrypTypes and buffered options in PerformanceObserver.observe() method. r=sefeng

Comment 17

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/50003 for changes under testing/web-platform/tests

Comment 18

[Atila Butkovits]

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

Comment 19

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 20

[Ryan VanderMeulen [:RyanVM]]

I moved this over to the DOM: Performance component since that's where the fix ended up landing, but NI Honza to make sure it gets counted in our webcompat fix metrics.

Comment 21

[Hiroyuki Ikezoe (:hiro)]

Oops, I am sorry for confusing. I innocently used this bug to fix the issue without opening a new platform bug. :/

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:hiro, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Comment 23

[Hiroyuki Ikezoe (:hiro)]

Comment on attachment 9446172 [details]
Bug 1915589 - Allow co-existing entrypTypes and buffered options in PerformanceObserver.observe() method. r?sefeng

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Some kind of sites are not able to be used at all
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a one liner change to drop a check whether buffered option is specified, very simple straight forward. It is what other browsers do.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9446172 [details]
Bug 1915589 - Allow co-existing entrypTypes and buffered options in PerformanceObserver.observe() method. r?sefeng

Approved for 135.0b5.

Comment 25

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/7d7ee638db85

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9446172 [details]
Bug 1915589 - Allow co-existing entrypTypes and buffered options in PerformanceObserver.observe() method. r?sefeng

Approved for 128.7esr.

Comment 27

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/6006471e52ac