1949743 - enphaseenergy.com - Fails to redirect to sign up page, returns to login page

Status: NEW

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

Description

[Calin Tanase]

Attachment: enlighten FF vs Chrome.mp4

Environment:
Operating system: Mac/Windows 10
Firefox version: Firefox 136.0b4 (aurora)/135/137

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://enlighten.enphaseenergy.com/manager/dashboard
2. Click on "Sign up for Enlighten".

Expected Behavior:
Redirects to sign-up page.

Actual Behavior:
Returns to login 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:c34b22a8-eb9b-4d27-9f5a-af3cddeec77b

Comment 1

[Calin Tanase]

On a clean profile if you go to https://enlighten.enphaseenergy.com and click on "Sign up for Enlighten" it will redirect to Register page but if you go back and try to access it again, the issue reproduces.

Comment 2

[Calin Tanase]

Attachment: logged in FF vs Chrome.mp4

Since the URL is pointing to a dashboard, I've created an account and tested this issue while logged in as well. The behavior is similar with the initial scenario. On Firefox it redirect to the welcome page, on Chrome it shows the actual page.

Comment 3

[Calin Tanase]

Attachment: console-export-2025-2-21_15-36-55.txt

Comment 4

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

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

Comment 5

[Daniel Holbert [:dholbert]]

The screencasts show that we're briefly redirected to https://enlighten.enphaseenergy.com/manager/dashboard/error .

I'll take a closer look tomorrow if nobody gets to it before me.

Comment 6

[Daniel Holbert [:dholbert]]

Here's a performance profile of the bug, in case it ends up being useful:
https://share.firefox.dev/4hQBdu8

Comment 7

[Daniel Holbert [:dholbert]]

Here's another profile of the bug with throttling set to "3G" to spread things out a bit more in time, which might make it easier to analyze or check theories about what's going on:
https://share.firefox.dev/3D3s8yX

And here's a profile of expected results under the same conditions but after clearing local site-data (ctrl shift del):
https://share.firefox.dev/3QvpViS

(As noted in comment 1, the STR seem to give expected-results when you're starting from a fresh profile or after deleting local data; but it's not quite as clear-cut as that, because I do sometimes continue to get expected-results even after repeating the STR a few times.)

Comment 8

[Daniel Holbert [:dholbert]]

FWIW:

• It seems to be important that you start out at https://enlighten.enphaseenergy.com/manager/dashboard as noted in the STR. (This redirects you to a login page, but if you just go directly to the login page, the bug doesn't reliably repro for me. It's important that you bounce through this dashboard URL, which I think triggers some sort of "whoops, let's get you signed out" state (even though you're never actually signed in) which is important to trigger the badness.
• Safari 18.1 (latest) gets the same bad "actual results" as Firefox here.

Comment 9

[Daniel Holbert [:dholbert]]

I can also reproduce the bug in Chrome v79 (fairly old) and earlier, on Win11. Chrome v80 (the next version) and newer give EXPECTED RESULTS

Comment 10

[Daniel Holbert [:dholbert]]

Googling for Chrome 80 changes to find clues, I do see some mentions that they shipped a major cookie change in that release:
https://www.zdnet.com/article/chrome-80-released-with-silent-notification-popups-support-for-same-site-cookies/
https://docs.mapp.com/v1/docs/how-to-prepare-for-the-google-chrome-80-update-samesite

Given that combined with the fiddly dependency on exact-steps here (per first bullet in comment 8), this seems likely to be related to cookie state. --> Reclassifying to diagnosis-team:networking for further investigation.

Comment 11

[Daniel Holbert [:dholbert]]

Hmm... I used Chromium's "bisect-builds.py" script to bisect to find the first "good" chromium build, and I got this range:
https://chromium.googlesource.com/chromium/src/+log/75e5efb67afdc2ed6f13a9d02d2aeb56fb657277..34ae61a82e48857507d440b79ee53d7c58121dad

...which is just this one commit: https://chromium-review.googlesource.com/c/chromium/src/+/1895400

Update V8 to version 8.0.136.

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/aadf1619..b3cc49df

I confirmed the fix range and it held up, just testing the last-bad and first-good commits (though swapping the meaning of "good" and "bad" in my interaction with the tool, since it's designed for finding regressions rather than finding fixes), with this invocation of bisect-builds.py:

python3 bisect-builds.py -g 711964 -b 711965 --verify-range  -- --no-sandbox https://enlighten.enphaseenergy.com/manager/dashboard

The summary of changes in that V8 version update just has a few things:
(1) A version-bump https://chromium-review.googlesource.com/c/v8/v8/+/1893697 (almost certainly irrelevant)
(2) Enabling the JS optional-chaining operator https://chromium-review.googlesource.com/c/v8/v8/+/1895427
(3) Reverting an earlier JS change related to a fuzz bug (reverting "Correctly handle global stores when global object has proxies") https://chromium-review.googlesource.com/c/v8/v8/+/1893194

Presumably this was due to (2) or (3). Considering (2) for the moment... Firefox and Safari also support the JS optional-chaining operator (bug 1566143 for us) so this can't be just a simple dependency on that feature, but maybe there's a dependency on that feature plus a dependency on something else that's Chrome-specific...?

Comment 12

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

Daniel - Thanks!
It sounds like this isn't a cookie bug, if it's one of those 3 commits.
Can we apply (or revert) those patches one at a time to a local build to verify which one is the culprit?

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #12)

It sounds like this isn't a cookie bug, if it's one of those 3 commits.

I think that's right, yeah.

Can we apply (or revert) those patches one at a time to a local build to verify which one is the culprit?

I don't know; I don't have much experience with building Chromium, but given that (as I've heard & recall) it's pretty massive, and those 3 commits are from ~6 years ago (and one of them is itself a backout), I don't have a lot of confidence that they'd backout cleanly/usefully at this point.

In theory we could checkout the rev for the "first good" build and then backout those commits one at a time, but that revision is ~5 years old. Given all the tooling and dependencies involved in building Chromium, I'm pretty sure that building a 5-year-old snapshot is a recipe for pain/failure...

Comment 14

[Daniel Holbert [:dholbert]]

My theory from the very end of comment 11 was that this is sort of a combination of optional-chaining-operator plus something else chrome-specific; lack of the optional-chaining-operator breaks things in Chrome, but the presence of that operator lets Chrome (with whatever other Chrome-specific feature/quirk is involved in the breakage here) get to a successful outcome here

In other words, I'm guessing that the chrome behavior-change (discussed in comment 9 - 11) is probably mostly a red herring -- just an indication that if we go back far enough, it breaks in (maybe?) a different way in Chrome (due to a dependency on the optional-chaining operator); and that failure-mode happens to have the same symptoms as the failure-mode that Firefox and Safari also hit here, but I don't have a lot of confidence that it's the same root cause.

I think the cause of the Firefox/Safari failure mode is still mysterious. It might be somehow related to the commits in comment 11, but I don't think we know that for sure.

Comment 15

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

Outreach might be worthwhile here if Firefox & Safari break. They claim to be compatible with FF 41+ IIRC. Tracking down the error for them or trying to fix it from the outside looks tough