@saii626 I find it strange that you have to disable it.
mine has the standard profile, with fingerprinting being blocked, and there isn’t a problem logging into gitlab.com - have you tried a private window in Firefox? Have you also tried in Brave/Chrome and do you have the same problem normally or incognito mode? Have you also tried disabling any plugins you have that might be affecting your ability to login?
I tried in private window in firefox and disabled my plugins. Still nothing. I have Enhanced Tracking Protection at Standard too. It works in chrome. Only way it worked for me on firefox is by disabling fingerprinting.
Anyway, I have found a difference between my “personal gitlab account” and my “work for money” firefox profiles. Both are running the same Firefox version 93, and quite similar configuration.
Looking at the console, one of the cloudflare cookies has wrong time set when the browser tries to set it: https://megous.com/dl/tmp/9e8e10b5e5e57cb9.png This does not happen in my personal firefox profile.
But when I clear all cookies and local storage, my work profile keeps getting some https://megous.com/dl/tmp/de84fa2394b9b999.png experimental_subject_id cookie set and my personal does not https://megous.com/dl/tmp/dbcbf61395e86643.png
So it’s either cloudflare or gitlab doing some A/B testing. Probably trying to see how many people leave their platform when they block them from accessing their web UI for work.
Do you want a direct answer to your A/B tests here on the forum? Because I can provide one. LOL 
Maybe check some “ No A/B tests on our customers, please” checkbox in your cloudflare config.
I don’t think that has anything to do with it, since I just browsed gitlab.com on my private profile and I have the experimental_subject_id cookie. If that was the case, then mine would fail as well.
You may be part of a different experiment perhaps?
Anyway whatever variant of their experimental code cloudflare is serving to me, is broken.
As I said, that has nothing to do with it, if it did then it would affect everyone. Have you tried running a VPN to change your location, and visit the site from a different IP than your current internet connection? There are plenty of free VPN services you can try to check/test.
Perhaps also try a clean Firefox profile that hasn’t had it’s default configuration changed, as we can then see if it’s related to your profile/settings or not.
I’ve tried with a default Firefox profile. Works as expected.
I then logged out, enabled privacy.resistFingerprinting and tried again. I got stuck at the “Checking Browser” page.
I switch on my VPN and tried again, no dice.
I fail to see how the issue isn’t the “privacy.resistFingerprinting” being enabled. This seems to be a recent development as well as I’ve used LibreWolf to use GitLab in the past which has “privacy.resistFingerprinting” enabled by default and it hasn’t caused an issue until recently.
I’ve tried with a default LibreWolf config, same issue.
I turn of privacy.resistFingerprinting, works fine.
Follow up question, what is GitLab checking from the browser? Is it checking in the user has dark mode enabled by any chance? I’m pretty sure “privacy.resistFingerprinting” prevents that information being sent.
Is there a solution that doesn’t involve me changing my privacy settings ?
I never had resistFingerprinting enabled in that profile.
I already stated that it gitlab works on the same computer in my personal firefox profile (that one has much tighter privacy settings) or in chrome. So it’s not an IP address. It’s some cloudflare issue.
Anyway, it’s not resistfingerprinting. It’s 1735193 - privacy.resistFingerprinting makes Cloudflare DDoS protection loop forever
dom.enable_resource_timing = false
Changing that to true, makes cloudflare shut up and load the page.
Weird, I had dom.enable_resource_timing set to true already, still no dice. Changing it to false made no difference either of course.
Same problem here. Disabling Enhanced tracking protection didn’t help. Disabling uBlock and allowing gitlab.com in Noscript didn’t help either.
I have privacy.firstparty.isolate=true and privacy.resistFingerprinting=true as well as some other privacy settings and I assume that some of these are to blame.
These issues are related:
I’m using an un-customized Firefox in a VM and the login page works normally. But I find it lame that using these privacy features makes the Cloudflare(?) check script not work.
Also having this problem suddenly after a year. I didn’t change anything in my browser, it just stopped working a few days ago. Apparently something has changed on CloudFlare’s side to not allow me past this screen. It just locks up forever on the “Checking your browser” page.
Changing privacy.resistFingerprinting to false seems to fix it. So I’ve set it to false, logged in, and changed it back to true.
For me it didn’t work with privacy.resistFingerprinting=false. With this option gitlab.com/users/sign_in was loading for several minutes. I changed to privacy.resistFingerprinting=true and everything works fine now. gitlab.com/users/sign_in is loaded withing a second. Ubuntu 16.04, Firefox 88.0
A colleague who is blind was attempting to login while using Safari with images disabled (under the Developer menu), this caused the browser check to get stuck in a loop. I’m also going to report this directly to Cloudflare; hopefully they can develop a smarter/fallback system.
Hope this helps 
This keeps happening to me on and off with random regularity on iOS Safari.
I have not messed around with any settings privacy or otherwise on it, and whenever I get stuck with this browser checking, I can’t proceed.
And then, other times it accepts me as already logged in user without a problem.
I highly doubt it is something with my browser settings. Even if it is, the bit protection is obviously faulty on GitLab side.
I had the same issue here on Fedora 35.
It was the Fedora User Agent plugin for me. I disabled it and the magic happen. Problem solved.
Hope it helps someone.
Thanks for this – why cloudflare needs to browser fingerprint, I don’t know. Why the user-agent would break cloudflare’s fingerprinting, I can’t fathom.
Gitlab: please reconsider this intrusive monitoring of your users.
