1936764 - samsung.com - The page is stuck in a reload-loop

Status: REOPENED

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

Description

[ioanidapop]

Attachment: reload_loop.mp4

Environment:
Operating system: Windows 11/10
Firefox version: Firefox 133.0 (release)/135

Preconditions:

• Clean profile
• Logged in

Steps to reproduce:

1. Navigate to: https://www.samsung.com/us/support/account/products/
2. Observe the behavior

Expected Behavior:
The page is displayed and functions properly.

Actual Behavior:
The page is stuck in a reload-loop.

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:4fcf0b62-cf30-42bb-b3fd-a6e8f68304d0

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

[Daniel Holbert [:dholbert]]

I can reproduce, after visiting the URL in comment 0 and logging in to my Samsung account when redirected.

For me at least, there's a cookie on this site that gets set in Chrome but never gets set in Firefox, named jwt_USA. All the bustage is downstream from there; the site uses that cookie to make various requests. You can see the requests failing in the network panel in DevTools in Firefox vs. succeeding in Chrome - a few relevant requests are for these URLs:

https://us.ecom.samsung.com/v1/sso/jwt/details
https://us.ecom.samsung.com/v4/identity/preferences-and-marketing-optin-info

Those requests fail in Firefox (with status 400 and 401 respectively) vs. they succeed in Chrome, in part because they include the JWT cookie in Chrome but not in Firefox.

If I manually copy Chrome's jwt_USA cookie from Chrome over to Firefox, then Firefox loads the page just fine (no reload loop, and my actual name and account-email-address show up just as they do in Chrome in the part of the page where the comment 0 screencast shows "samsung account" / "payment methods" etc. on the left side of the page)

My manual hackaround to copy that cookie from Chrome to Firefox (to make this work) is to run this in Chrome's devtools when viewing the page in question

window.Cookies("jwt_USA")

...and then copypaste the following into Firefox's devtools when viewing the page in question, swapping in the actual cookie for my placeholder-text "the cookie from chrome":

window.Cookies.set("jwt_USA", "the cookie from chrome")

Comment 3

[Daniel Holbert [:dholbert]]

A few additional updates from my further testing:
(1) If I start out by visiting https://www.samsung.com/us/ and logging in via the avatar-icon at the top right before I attempt to visit the URL from comment 0 here, then everything ends up fine here. Specifically, I get a "jwt_USA" token in my document.cookie for www.samsung.com, and I don't hit any redirect issues when I proceed to visit the URL in comment 0.
(2) I can tell ahead-of-time that I'll be fine because document.cookie.indexOf("jwt_USA") returns a positive number when I'm viewing e.g. www.samsung.com. (This is a clue that this cookie has been set and will be available when I go to the URL linked in comment 0.)
(3) So, the breakage here seems to be specific to the login flow that you follow when you visit the site in comment 0 without being logged in and you get auto-redirected to a login page and proceed to login. That flow works in Chrome (via this "jwt_USA" cookie getting set during login), but that flow triggers this infinite-reload issue in Firefox (apparently because it does not set this "jwt_USA" cookie).
(4) This is not a regression, or at least not a recent one; I can reproduce in Nightly 2021-01-01.
(5) If you test this too aggressively (e.g. repeatedly logging in from fresh profiles), Samsung's login page stops working and tells you they think you're sharing an IP address with a bot. That just happened to me at least. :)

Given that this seems to be cookie-related, I imagine this belongs in the DOM or networking teams for triage. Let's start with networking, but they can kick it over to DOM if that seems more appropriate.

Comment 4

[edgul]

I'm not sure why, but the response that carries the jwt_USA cookie is returning as 502 with firefox.
https://www.samsung.com/aemapi/v6/data-login/afterLogin.us.json

The cookies sent for the request of this resource are quite different, but I'm not sure yet that this is the issue.

Comment 5

[edgul]

Private browsing mode doesn't help the issue.
Neither does using User Agent Switcher and Manager to spoof chrome's user agent.

Comment 6

[edgul]

I also took a quick look at networking logs with cookie:5 enabled, but I didn't see anything obviously wrong. But it might be better to have someone more familiar with necko logging to review as well.

Comment 7

[Kershaw Chang [:kershaw]]

(In reply to edgul from comment #6)

I also took a quick look at networking logs with cookie:5 enabled, but I didn't see anything obviously wrong. But it might be better to have someone more familiar with necko logging to review as well.

Unfortunately, I can't find anything wrong from the log.
I think the problem is that the sever doesn't send Firefox the jwt_USA cookie. I can't tell the reason from the log.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

It doesn't appear this is an issue with cookie handling; they're simply not sending it to us. Probably this needs to go to outreach

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

Still happening. Martin - have we started outreach with Samsung? I'm guessing not since it's in needs-contact

Comment 10

[Martin Balfanz [:mbalfanz]]

I'm not aware of any outreach attempts

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

Samsung appears to have fixed this!
Probably worth having someone else verify, but I tried on linux and windows nightly.

Comment 12

[Raul Bucata]

Verified as REPRODUCIBLE using the RC Build

Tested with:

Browser / Version: Firefox 139.0-candidate build 1
Operating System: Windows 10 PRO x64

Comment 13

[Raul Bucata]

Attachment: rc 139 reproducible

Comment 14

[Daniel Holbert [:dholbert]]

I can still reproduce, too. (fresh profile, Nightly 140.0a1 (2025-05-19) (64-bit) on Linux)

Removing webcompat:needs-diagnosis since I don't think there's more diagnosis needed here; the already-diagnosed issue (on Samsung's end) simply still remains. (This was just closed because we had a guess that it was fixed on the server side, but it doesn't seem to have been.)

Comment 15

[Jeff Muizelaar [:jrmuizel]]

If spoofing the Chrome user agent doesn't cause the cookie to be sent doesn't that mean we should do more diagnosis to figure out why?

Comment 16

[Jeff Muizelaar [:jrmuizel]]

This doesn't happen in Safari

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)

If spoofing the Chrome user agent doesn't cause the cookie to be sent doesn't that mean we should do more diagnosis to figure out why?

That's fair, in comment 14 I was just restoring this to the state that it was in before we'd inadvertently closed it -- but yeah, there's more diagnosis-needed here, since there does seem to be some not-yet-understood Firefox/Gecko-only behavior going on.

FWIW I spent some time today poking at this in a debug build, with MOZ_LOG="cookies:5" to watch cookies being set and rejected. When reproducing this bug, there are a few cookies that Firefox rejects for various reasons, but when I monkeyed with my build to make it accept them (removing the return statements that followed the rejected-cookie logging), I still wasn't able to get good results here. So I don't think any of the cookies from that logging are relevant to the badness here.

So my current hunch is that this is a case where Samsung is deciding not to set a cookie at all for some reason (e.g. taking a different codepath through their JS), rather than a case where they're trying to set a cookie and then we reject it.

Unfortunately this bug gets progressively-more-painful to investigate the longer you're working on it, because Samsung starts showing recaptcha prompts if you repeatedly log in within a few minutes (and the recaptcha sequences get longer, the more they start to suspect that you're up to something). But in any case: I'm hoping the networking and/or DOM teams can finish off the diagnosis here and get to an understanding of what's causing Firefox in particular to fail here.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #16)

This doesn't happen in Safari

That's correct - I just confirmed this locally. Safari gets expected results here.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

ni?me to try to get a pernosco trace (and note to self: then change the password :P)

Comment 19

[Jeff Muizelaar [:jrmuizel]]

It wasn't completely clear to me when I was reading this bug but it seems like the response for the request to https://www.samsung.com/aemapi/v6/data-login/afterLogin.us.json is what is Set-Cookieing the jwt_USA cookie.

Comment 20

[Emilio Cobos Álvarez (:emilio)]

Pernosco recording with cookie and docshell logs: https://pernos.co/debug/d3yByszkZv7sWmeigZLUjA/index.html

Comment 21

[Jeff Muizelaar [:jrmuizel]]

afterLogin.us.json is loaded by https://account.samsung.com/accounts/v1/samsung_com_us/signInComplete which does:

<script>
...
  var redirect = function () {
    pageLogging(() => {
      window.location.href = 'https://www.samsung.com/aemapi/v6/data-login/afterLogin.us.json?auth_server_url=us-auth2.samsungosp.com&code=ahETGNTYIY&code_expires_in=300&state=GLBw5dlmonmey&api_server_url=us-auth2.samsungosp.com';
    });
  }
</script>
<!-- Datadog RUM -->
  <script src="https://account.samsung.com/resources/libs/datadog/1.0.0/datadog.min.js"></script>
    <body onload="redirect()">
    </body>
</html>

Comment 22

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

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

Comment 23

[Randell Jesup [:jesup] (needinfo me)]

In comment 17:

But in any case: I'm hoping the networking and/or DOM teams can finish off the diagnosis here and get to an understanding of what's causing Firefox in particular to fail here.

Moving to DOM team for diagnosis