Open Bug 2038269 Opened 1 month ago Updated 1 month ago

connect.sunlife.ca - page is empty

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 151
Platform:
Desktop
Windows
Type:
defect

Tracking

(Webcompat Priority:P1, Webcompat Score:8, firefox-esr115 unaffected, firefox-esr140 unaffected, firefox150 affected, firefox151 affected, firefox152 affected)

Project Flags:
Webcompat Priority P1
Webcompat Score 8
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- unaffected
firefox150 --- affected
firefox151 --- affected
firefox152 --- affected

People

(Reporter: ksenia, Unassigned)

References

(
URL
)

Details

(Keywords: webcompat:needs-contact, webcompat:site-report, Whiteboard: [webcompat-source:product])

User Story

platform:windows,mac,linux,android
impact:site-broken
configuration:general
affects:all
branch:release
diagnosis-team:webcompat
user-impact-score:1000

Environment:
Operating system: desktop
Firefox version: Firefox 150.0.1 (release)

Preconditions:

  • Clean profile

Steps to reproduce:

  1. Navigate to: https://connect.sunlife.ca/s/login/?language=en_CA
  2. Observe the page

Expected Behavior:
Page loads and shows a login form

Actual Behavior:
Page is blank

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:69cea3d1-7412-4fa5-b5e0-965d34fdd556

It works as expected on the first load.
However, it fails on subsequent loads. In this case, If Clear cookies and site data is executed, it will start working again.

Regression window:
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=654fd8ff04cc239ef2e99c2ac148bb7cf001ec71&tochange=e65fa93d92aff32b5b7e61d905ba771595ef5a26

On Windows 11 Nightly 152.0a1, spoofing the UA as follows does the trick.
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0");

They're using Akamai, so it could be related. But the symptoms don't match.

Severity: -- → S2
User Story: (updated)
Webcompat Priority: --- → P2
Webcompat Score: --- → 6
Keywords: webcompat:needs-contact, webcompat:needs-sitepatch
Priority: -- → P2
User Story: (updated)
Webcompat Priority: P2 → P1
Webcompat Score: 6 → 8

Simply changing the UA string doesn't seem to fix it on my end, when I reproduce the problem. I think we need more info here before we know if a site-patch is feasible.

User Story: (updated)
Keywords: webcompat:needs-sitepatch
You need to log in before you can comment on or make changes to this bug.