2045229 - www.mercy.net - Login does not work

Status: NEW

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

Description

[Calin Tanase]

Environment:
Operating system: Windows 10
Firefox version: Firefox 151.0

Preconditions:

• account needed

Steps to reproduce:

1. Go to https://www.mercy.net/app/login
2. Log into your account.

Expected Behavior:
It logs in.

Actual Behavior:
Does not log in.

Notes:

• The issue is believed to be valid, but was not reproduced as it requires a login

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

Comment 1

[Mark Horstman]

(In reply to Calin Tanase from comment #0)

Environment:
Operating system: Windows 10
Firefox version: Firefox 151.0

Preconditions:

• account needed

Steps to reproduce:

1. Go to https://www.mercy.net/app/login
2. Log into your account.

Expected Behavior:
It logs in.

Actual Behavior:
Does not log in.

Notes:

• The issue is believed to be valid, but was not reproduced as it requires a login

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

I too have been having this issue

Browser / Version: Firefox 151.0
Operating System: Mac OS X 10.15
Tested Another Browser: Yes Safari

I have a mercy.net login and would be willing to help diagnose.

Comment 2

[Calin Tanase]

I have a mercy.net login and would be willing to help diagnose.

Hi Mark, I'm not sure if you've been contacted about the credentials yet, but if they didn't could you please send them on my email? ([e-mail])

Comment 3

[Mark Horstman]

(In reply to Calin Tanase from comment #2)

I have a mercy.net login and would be willing to help diagnose.

Hi Mark, I'm not sure if you've been contacted about the credentials yet, but if they didn't could you please send them on my email? ([e-mail])

I can't give you the credentials because they're to my private health account on mercy.net. But if you can give me specific instructions (turn on specific logging or somesuch) that I can capture helpful data, I'd be happy to do that.

Comment 4

[Daniel Holbert [:dholbert]]

Hi Mark - thanks for being willing to help! I totally understand not wanting to share credentials due to the private health data here.

One tier removed from that, perhaps... Would you be willing to schedule a zoom video conference and screen-share, and we can reproduce the bug and compare to Chrome results, and I can talk you through a few different diagnostics to try to figure out what's working differently? If so, we can coordinate over email and try to schedule a time that works. Thanks!

(I wish there were a good set of diagnostics that I could give you to run to just get to the root of the problem, but right now I'm not clear enough on what's going wrong or why to know what to ask for. Looking at the linked sumo threads in https://github.com/webcompat/web-bugs/issues/221539#issuecomment-4621743908 , I do see someone asked for whether the web console or network devtools show any interesting errors or failed loads - that might be worth checking. I also see that MarkRH (maybe that's you) observed that clearing cookies for the site seemed to help at one point, but doesn't help anymore, perhaps.)

Comment 5

[Mark Horstman]

I'd be happy to do the zoom call. I'm retired and have lots of time on my hands. I'm in USCentral TZ. Send me a zoom invite and we'll meet up and figure it out.

Comment 6

[Daniel Holbert [:dholbert]]

Met with Mark over Zoom, and we got some really good useful observations:
(1) When the bug happens, you just end up back at the login page (https://www.mercy.net/app/login ) after completing the whole login flow.

(2) Activating chrome mask does not help.

(3) There are no suspicious entries in Web Console (there was one JS error that looked maybe-relevant, but it was also present in Web Console in Safari in a session where login succeeded there).

(4) Starting with a completely fresh Firefox user profile, he was able to log in to mercy exactly once. But then after logging out, he would reliably hit the bug going forward from that point.

(5) ...and after he had hit the bug, he was able to get back to a working state by clearing cookies and site data for mercy.net (by going to about:preferences | Browsing Data | Clear data for Specific Sites, and then typing "mercy.net" and clicking "Remove" and "Save changes). But as in (4), that would only let him log in once (and then he'd have to clear cookies again to log in again). This matches what MarkRH observed in a support thread.

(6) We captured some performance profiles of the issue, and they showed a series of network requests that looked relevant/interesting:

• The "good" profile had several successful XMLHttpRequests (Request Status: NS_OK) to https://www.mercy.net/mymercywebapi/authenticated
• The "bad" profiles had a single XMLHttpRequest to https://www.mercy.net/mymercywebapi/authenticated , and that request was shortly followed by an XMLHttpRequest to a "logout" endpoint, https://www.mercy.net/mymercywebapi/logout

That spontaneous load of the "logout" endpoint seems to be a sign of the relevant problem here, and the question is why we're hitting it (it seems to have something to do with cookie state, given 3 and 4).

(7) Safari is able to log in / log out / log in again, repeatedly, with no issues.

Comment 7

[Daniel Holbert [:dholbert]]

Mark and I exhausted the limits of remote-debugging-over-zoom, so I'm hopeful we can get a test account or something along those lines to push further. I just spoke to a tech support rep at the MyMercy website using their phone tech-support number, and they passed along my info to someone who can hopefully help on their end. I'll update the bug when I learn more.

Comment 8

[Daniel Holbert [:dholbert]]

(The tech support rep that I spoke to sounded like they were aware of the issue -- it's something users call to get help with -- and they typically ask users to clear cookies. They did think they'd gotten a few reports of this affecting other browsers as well, but I think their perception was that Firefox was most-affected. They thought they recalled this issue starting a couple months ago, which matches the timeline from our GitHub webcompat report where the user (on May 19, 2026) said: "I've used Firefox to log into mychart for years and in the past 3 months, I can no longer login")

Comment 9

[Daniel Holbert [:dholbert]]

Mark tested some old Nightly builds too, via mozregression, and he found that old builds are all "bad" (first login succeeds, second fails).

2025-10-01: first login succeeds, second fails
2025-06-01: succeed, fail
2024-06-01: succeed, fail
2023-06-01: succeed, fail

Based on Mark's experience, and that of the person who submitted the report on WebCompat.com, the issue started happening in or around 2026. So: given that these much older builds are currently giving "bad" results, that suggests that the proximal change here was on the website's end. (Still could be a Firefox bug, but a long-standing one, only newly triggered by this site; not just a change we made this year that we could backout or iterate on.)

Comment 10

[Daniel Holbert [:dholbert]]

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

(The tech support rep that I spoke to sounded like they were aware of the issue -- it's something users call to get help with -- and they typically ask users to clear cookies. They did think they'd gotten a few reports of this affecting other browsers as well, but I think their perception was that Firefox was most-affected.

FWIW, on other browsers being possibly-affected -- I found a reddit thread about this issue with a few comments:
https://www.reddit.com/r/firefox/comments/1t3w3cm/problems_logging_into_mymercy_it_just_loops_back/
...and there's a mention there of one user hitting this issue on multiple browsers (though that's not everyone's experience).

That makes me wonder if this is some sort of race condition in Mercy's login logic, where Firefox-with-Mercy-cookies happens to "lose the race" for whatever reason, and other browsers sometimes lose the race too, depending on network quality / hardware / etc.