1897395 - in.investing.com - Blank page displayed

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P1)

Description

[Andreea Zlata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 126.0/128.0a1 (2024-05-16

Steps to reproduce:

1. Access https://in.investing.com/charts/advinion.php?version=6.3.1.0&domain_ID=56&lang_ID=56&timezone_ID=23&pair_ID=8985&interval=5H
2. Observe the page

Expected Behavior:
The page is loading.

Actual Behavior:
Web page does not load at all.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/137056

Comment 1

[Andreea Zlata]

Attachment: Screenshot_12.png

Comment 2

[Dennis Schubert [:denschub]]

Might be a different issue, but on https://in.investing.com/charts/live-charts, the charts appear to be completely blank, too.

Comment 3

[Alice0775 White]

(In reply to Dennis Schubert [:denschub] from comment #2)

Might be a different issue, but on https://in.investing.com/charts/live-charts, the charts appear to be completely blank, too.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=14d68154a5bee022c96b908cfcf492dcb4f7f085&tochange=7cdb37e233eb8ff913e8aa2214f90659a7e261c3

yes, different issue, I have filed Bug 1897995.

Comment 4

[Daniel Holbert [:dholbert]]

I can reproduce this in Firefox Nightly. It actually loaded successfully for me, once (!), but it failed to load on other attempts. It seems to load properly in Chrome.

When this bug here does reproduce, the DOM is simply not populated at all; the page has <div id="layoutId1"> which is just an empty DOM node (whereas when the page loads properly, that element has a <div id="chart-full-page-div-modal"> child node with tons of <canvas> descendants.

In all cases (Chrome and Firefox, both working and not-working), the page is blank for 5s or so (with <div id="layoutId1"> being empty). Then, for the working loads, the content gets suddenly dynamically appended at that point.

Comment 5

[Daniel Holbert [:dholbert]]

A few observations:
(1) When this fails, it looks like it's because we're getting a 403 response from the site (hosted on cloudflare) for particular resources, like this one:
https://advcharts.investing.com/static/advinion/6.3.1.0/ChartUI/version/prochart.version.json.js?1717623035119
Note that the ?[number] changes on each load; I think it represents milliseconds-since-the-epoch, i.e. new Date() / 1 or similar. But, if I filter my network devtools for the URL without that suffix, I see this request failing in pageloads-that-fail.
The request is shown in devtools with OPTIONS as the method, which I think means it's a pre-flight request to see if it's permitted to make the same request using CORS, or something along those lines?

(2) This seems to fail less-reliably in older builds -- e.g. 2022-03-01 seems to load it successfully more than current Nightly does. In older builds, I observed that the first load typically still fails to load, but the second or third load is typically fine; and once it's loaded successfully, then subsequent loads are all typically fine as well in these older builds, until/unless I do "Clear Recent Data" (ctrl+shift+del)

Comment 6

[Daniel Holbert [:dholbert]]

Here's a profile in aforementioned Nightly 2022-03-01 using "Networking" settings, with a bunch of attempts at loading this page:
https://share.firefox.dev/45atzoQ

In that profile, most of the loads succeeded, but several of them failed (particularly after I did clear-recent-data operations). You can easily find the failing cases by mousing across the screenshots track and looking for red network-request responses in my devtools pane, in the screenshotted Firefox window. (When recording, I was filtering that pane for prochart.version to focus in on the resource that matters per comment 5.)

Comment 7

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=229e905d571ebbe18c9d2e5a6fd1a9b654db6afb&tochange=03d170b7fb27d2ed449a19ad74e3a000a24892f7

FWIW,
Setting network.http.http3.enable to false works on Nightly128.0a1 Windows11.

Comment 8

[Daniel Holbert [:dholbert]]

Thanks, Alice0775! Sounds like this is specific to our http3 implementation, then.

I ended up finding a later regression range than Alice0775, where we went from partly-good to essentially-entirely-bad:
Last good revision: 4d770d6a88770f9af267a8a34e002f955b0c37cd (2022-03-02)
First bad revision: e5ebdee1eac6efa37b7e83861bc179b155f98ae4 (2022-03-03)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4d770d6a88770f9af267a8a34e002f955b0c37cd&tochange=e5ebdee1eac6efa37b7e83861bc179b155f98ae4

Comparing builds before/after that range:

• In "good" builds before that range, I get a successful pageload in fewer-than-5 hard-reloads (the first load is pretty much always bad, but I get a good load often on the first hard-reload, or within a few tries).
• In "bad" builds after that range, I tried reloading 20+ times and never got a successful load (and network devtools filtered for prochart.version show that some or all of the loads failed).

I confirmed that range several times, with targeted mozregression --launch [datestamp] runs with the good/bad build, just to be extra sure.

Assuming that range does correctly include something that made us regress on this particular page, here are the only possibly-network-related commits that I'm seeing there:

https://hg.mozilla.org/mozilla-central/rev/c6adb5930b38fbc5aff51f488f7bd2b8ab3cbf53
Bug 1756709 - Remove NS_HTTP_ALLOW_KEEPALIVE for AltSvcTransaction
(note, I tried backing this out in a local build, since it trivially backs out, but the local build still gave me "bad"-flavored results; so that might mean this commit is unrelated)

https://hg.mozilla.org/mozilla-central/rev/7ecdcfe5cb4afb1ddbc6034f5fc858873c03e7ea
Bug 1753980 - land NSS NSS_3_76_RTM UPGRADE_NSS_RELEASE

https://hg.mozilla.org/mozilla-central/rev/639f4b5dc473d0cc86a378975b677e76963a8378
Bug 1755372: Cut Over Connection to finer-grained RFP Check
(note, I'm not using resistFingerprinting or any other custom config; so if this commit is truly RFP-specific, then it's probably unrelated)

https://hg.mozilla.org/mozilla-central/rev/4000eb2cd181169c6952b47362ccd3ab403cca2b
Bug 1750787 - get CRLite enrollment list from cert-revocations.

kershaw, maybe you or someone on the networking team could take a look here? See the profile in comment 6 which has both good and bad loads, in case that's useful.

Comment 9

[Daniel Holbert [:dholbert]]

(Note, I think :dshin observed at least one "bad" load from Chrome when we were discussing this bug earlier, so there might be a browser-agnostic server-side issue involved at some level here. However, Chrome seems to load the site properly almost every time, whereas current Firefox seems to fail almost every time, so there's something on our end that's different from Chrome that's seems to be heavily involved here.)

Comment 10

[Kershaw Chang [:kershaw]]

I can't find anything wrong at the networking side.
Looks like the failed load is related to this cors preflight request.

E/nsHttp nsHttpChannel 156a1a800 created nsHttpTransaction 152fe4e10
E/nsHttp nsHttpTransaction::Init [this=152fe4e00 caps=400011]
E/nsHttp nsHttpTransaction 152fe4e00 SetRequestContext 0
E/nsHttp http request [
E/nsHttp   OPTIONS /static/advinion/6.3.1.0/ChartUI/layouts/layout1/init.json.js HTTP/1.1
E/nsHttp   Host: advcharts.investing.com
E/nsHttp   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0
E/nsHttp   Accept: */*
E/nsHttp   Accept-Language: en-US,en;q=0.5
E/nsHttp   Accept-Encoding: gzip, deflate, br, zstd
E/nsHttp   Access-Control-Request-Method: GET
E/nsHttp   Access-Control-Request-Headers: content-type
E/nsHttp   Referer: https://in.investing.com/
E/nsHttp   Origin: https://in.investing.com
E/nsHttp   Connection: keep-alive
E/nsHttp   Sec-Fetch-Dest: empty
E/nsHttp   Sec-Fetch-Mode: cors
E/nsHttp   Sec-Fetch-Site: same-site
E/nsHttp   Priority: u=4
E/nsHttp   
E/nsHttp ]

For some reason, the server returns 403 for this request.

D/nsHttp nsHttpTransaction::HandleContent [this=152fe4e00 count=0]
D/nsHttp nsHttpTransaction::HandleContentStart [this=152fe4e00]
I/nsHttp http response [
E/nsHttp   HTTP/3 403 
E/nsHttp   date: Thu, 06 Jun 2024 12:07:05 GMT
E/nsHttp   content-type: text/html; charset=UTF-8
E/nsHttp   accept-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
E/nsHttp   critical-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
E/nsHttp   cross-origin-embedder-policy: require-corp
E/nsHttp   cross-origin-opener-policy: same-origin
E/nsHttp   cross-origin-resource-policy: same-origin
E/nsHttp   origin-agent-cluster: ?1
E/nsHttp   permissions-policy: accelerometer=(),autoplay=(),browsing-topics=(),camera=(),clipboard-read=(),clipboard-write=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()
E/nsHttp   referrer-policy: same-origin
E/nsHttp   x-content-options: nosniff
E/nsHttp   x-frame-options: SAMEORIGIN
E/nsHttp   cf-mitigated: challenge
E/nsHttp   cf-chl-out: 6ANqzMhPF7goFhFMogPZWsNOG/Eb4Qg1cIRZVvxb6MsG26FnsPHc7bJ1p13QBsGkluxc13CWPBH3wrXAfBST6qRWU5WiEVISKs8DN3rh2uyuxEeOUZqQC3jWdp0rLIg7tYpH1OAeXVA37bjZGcWSWA==$kFyXywUzdFkMBU/FdLf3fw==
E/nsHttp   cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
E/nsHttp   expires: Thu, 01 Jan 1970 00:00:01 GMT
E/nsHttp   set-cookie: __cf_bm=XJHGHEXx1yyjk92pX9ayFxg0aW0CphCYVfmg_Rcmyxw-1717675625-1.0.1.1-aDURFWoFRcykw7Sv3bTe12v0sUUdXt8knJLpFsrmr_sN95KOZAJDgM6290wSE8OFpoSnR5A1e1rq8m31YS1LILIwvyIWWFJ6YTFq6kGZLnU; path=/; expires=Thu, 06-Jun-24 12:37:05 GMT; domain=.investing.com; HttpOnly; Secure; SameSite=None
E/nsHttp   vary: Accept-Encoding
E/nsHttp   server: cloudflare
E/nsHttp   cf-ray: 88f847b29c841c34-FRA
E/nsHttp   content-encoding: br
E/nsHttp   alt-svc: h3=":443"; ma=86400

However, sometimes the server do return 200 OK to the same request.
I think this is maybe a server side issue.

Comment 11

[Kershaw Chang [:kershaw]]

I don't think this is a regression. It's possible that this issue is just easily triggered by using HTTP/3.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Kershaw Chang [:kershaw] from comment #10)

I think this is maybe a server side issue.

I agree -- though we do seem to be uniquely/specially hitting it for some reason. Safari and Chrome very rarely hit this issue, somehow. It would be worth getting to the bottom of what's going on here, in order to either mitigate it on our end, or notify investing.com and/(or cloudflare?) folks about the circumstances that trigger the issue, or both.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Kershaw Chang [:kershaw] from comment #11)

It's possible that this issue is just easily triggered by using HTTP/3.

(In reply to Daniel Holbert [:dholbert] from comment #12)

Safari and Chrome very rarely hit this issue, somehow. It would be worth getting to the bottom of what's going on here

Note, Chrome at least does use HTTP/3, and somehow still doesn't hit this issue. Safari does not broadly use HTTP/3 yet, I guess, based on caniuse and visits to test-pages https://quic.nginx.org and https://http3.is (with a reload). So Safari is presumably avoiding this issue at least in part due to not bothering with HTTP/3 here. To-be-determined whether they hit this issue or not when HTTP/3 is enabled. (I can't find a way to turn it on, in my current Safari versions; some googling suggests it used to be available in their settings UI, but it doesn't seem to be there anymore.)

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

This may not be something we should treat as a webcompat issue since it does work in other browsers. If we move this out of webcompat, and investigate it further, where does it belong? Core:Networking?

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Liz Henry (:lizzard) (relman/hg->git project) from comment #14)

This may not be something we should treat as a webcompat issue since it does work in other browsers.

That still fits the definition of webcompat issues. :)

Either way, we do need to do something about it, whether it's outreach vs. landing some sort of site-specific intervention vs. changing Gecko.

If we move this out of webcompat, and investigate it further, where does it belong? Core:Networking?

Yeah -- at this point, the underlying behavior-difference here seems to be in our networking code.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Dennis, can you help find an owner for this P1 issue? Thanks!

Comment 17

[Kershaw Chang [:kershaw]]

(In reply to Liz Henry (:lizzard) (relman/hg->git project) from comment #14)

This may not be something we should treat as a webcompat issue since it does work in other browsers. If we move this out of webcompat, and investigate it further, where does it belong? Core:Networking?

Can we contact cloudflare and maybe ask them to take a look?
FWIW, we have another bug 1902931 which is also about HTTP/3.

Comment 18

[Dennis Schubert [:denschub]]

As for which component this belongs to, it doesn't matter too much. We can keep track of the bug here, but we can also move it into Core::Networking if we think it belongs there - but from what I can tell in the bug, we don't actually understand the behavior difference here?

Given that this is now the second h3 bug related that looks to be Cloudflare-specific, we really should spend some time here to understand the difference, if there is any. It looks like HTTP/3 is still off by default for Cloudflare customers, but the potential for widespread breakage is big, and especially if this is intermittent, it can really frustrate users.

+1 to reaching out to Cloudflare. Kershaw, I think you're in a good position to get that started? :)

Comment 19

[Kershaw Chang [:kershaw]]

(In reply to Dennis Schubert [:denschub] from comment #18)

As for which component this belongs to, it doesn't matter too much. We can keep track of the bug here, but we can also move it into Core::Networking if we think it belongs there - but from what I can tell in the bug, we don't actually understand the behavior difference here?

Given that this is now the second h3 bug related that looks to be Cloudflare-specific, we really should spend some time here to understand the difference, if there is any. It looks like HTTP/3 is still off by default for Cloudflare customers, but the potential for widespread breakage is big, and especially if this is intermittent, it can really frustrate users.

+1 to reaching out to Cloudflare. Kershaw, I think you're in a good position to get that started? :)

I've sent an email to them regarding bug 1902931 but not for this bug. I think this bug might be more related to the site's behavior rather than Cloudflare. For what it's worth, the URL in comment #0 always works for me now, but I cannot see the chart on https://in.investing.com/charts/live-charts even with HTTP/3 disabled.

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to Kershaw Chang [:kershaw] from comment #19)

For what it's worth, the URL in comment #0 always works for me now

Same! Hooray! (This was previusly broken nearly-all-of-the time for me, per comment 4.)

Andreea Zlata / Alice0775 White: since you both were also able to reproduce, would you mind double-checking that this is fixed for you too, using the URL from comment 0? (Note that the site does render blank for ~5 seconds as part of its normal load process, so be sure wait through that.)

but I cannot see the chart on https://in.investing.com/charts/live-charts even with HTTP/3 disabled.

That's unrelated; see comment 2 - comment 3. That's tracked in Bug 1897995 (and is caused by a Nightly-only thing; release users are unaffected).

Comment 21

[Alice0775 White]

The page of comment#0 works for me too.
The page appeared about 5 seconds after the loading indicator on the tab stopped. (this is a bad UX...).

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to Alice0775 White from comment #21)

The page of comment#0 works for me too.

Thanks! I think we can consider this WFM then.

The page appeared about 5 seconds after the loading indicator on the tab stopped. (this is a bad UX...).

Yeah, that's what happens in Chrome, too. The page is literally lacking any content for the first few seconds, per the end of comment 5, and then it runs some JS to dynamically stitch in the content. shrug.