1947479 - yonobusiness.sbi - The login page fails to open

Status: NEW

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

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 128.6.0 (esr)

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://yonobusiness.sbi/
2. Click on the "LOGIN" button and observe

Expected Behavior:
The login 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
• Refreshing the page solves the issue

---

Created from webcompat-user-report:d593a2be-8fcb-4e56-ad57-6de8ffe4b1cc

Comment 1

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Dennis Schubert [:denschub]]

ERROR DOMException: The operation is insecure.

Probably related?

Comment 3

[Sean Feng [:sefeng]]

So we have a limitation for pushState that can be controlled by dom.navigation.navigationRateLimit.count. Changing this to 0 fixes site.

It appears that Chrome doesn't do a hard stop when the site reaches the limit, instead they throttle the navigation. I've filed bug 1948035 to discuss a fix on the platform site.

Comment 4

[Peter Van der Beken [:peterv]]

This also broken in WebKit, I see a large number of exceptions in the console saying SecurityError: Attempt to use history.pushState() more than 100 times per 10 seconds. Note that 100/10s is even lower than Firefox's limit which is 200/10s.

Comment 5

[Peter Van der Beken [:peterv]]

For me changing the limit to 130/s makes the page work, but this really looks like an issue with this site. That seems like a very big number of pushState calls per second for a non-abuse case.

Comment 6

[Sean Feng [:sefeng]]

Just by looking at Chrome's code, we seem to have the exact limit as them, 200/10s.

Then just by randomly search through the code, I see something like this. It looks like Chrome doesn't throw an exception, but we do?

Comment 7

[Sean Feng [:sefeng]]

Peter, if I comment out https://searchfox.org/mozilla-central/rev/a80b3969c6d78ac5ba2552a5bce5e5c7a74f3a9b/dom/base/nsHistory.cpp#253, Firefox starts to work.

Do you have ideas about this? Is it Chrome not following the spec?

Comment 8

[Peter Van der Beken [:peterv]]

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

Then just by randomly search through the code, I see something like this. It looks like Chrome doesn't throw an exception, but we do?

I already pointed that out in bug 1948035 comment 3 (side note: these dual platform/webcompat bugs often end up splitting and duplicating conversations). The spec allows Chrome's behaviour, probably because it was adapted to their behaviour, even though (as can be seen in their code) they also seemed to want to throw. Given that WebKit also throws an exception, Olli and I are not too eager to match Chrome's behaviour. Not throwing can potentially break other applications, and makes this API more unreliable.

Olli and I considered other options, for example an intervention that catches the exception, or a site-specific pref that allows tuning the rate limit.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Has anyone tried to contact the site? It is after all broken in multiple browsers, so they might be rather eager to fix the issue.
Asking also in Matrix webcompat channel, in case someone from webkit side has already contacted them.

Comment 10

[Sean Feng [:sefeng]]

added webcompat:needs-contact to indicate the fact that we want to contact the site.

Comment 11

[James Graham [:jgraham]]

Given that WebKit also throws an exception, Olli and I are not too eager to match Chrome's behaviour

Have we filed a spec issue, or an issue on the chromium bug tracker? Whilst we might be able to get this site fixed we should assume the underlying issue might affect other sites, and make sure we're not in a limbo where there's no plan for aligning implementations.