Could it be that setting cookies for the domain was disallowed via the permissions dialog?
When I do that, I see behaviour like you are describing it: when I e.g. tried upvoting jedberg's comment with cookies disallowed, it actually worked. I was redirected to the login page and back to the discussion without staying logged in. After undoing the permission change, logging in and having a look at the exact comment, I saw that the vote actually went through. Posting a new comment showed the same behaviour.
You can find that permission on the "page info" dialog (shortcut Ctrl+I if that isn't localized?)?
Edit: the error message on the console would be different though. The described procedure leads to the message "Setting cookie ... has been denied because of a permission set by the user" (translated from German, so the actual message will be different).
It looks like I was only describing the behaviour when cookies are unavailable and not the actual reason.
A helpful way to debug this is the "copy as Curl" feature in most browsers. That should give you the most true representation of what request is being sent to HN. Do it in private mode and non-private mode and then compare the differences.
I see you tried private browsing and it works, so that would imply a bug in something that runs when not private browsing, so most likely a plugin that is blocking something.
Start doing a plugin bisection and see if you can find the offending plugin.
Well, the idea still stands. Private->ok, not private->not ok. That's your telltale sign, go with the evidence, as a famous TV show says. Maybe you have something on your normal profile, I dunno what, but I like bashing Apple and since you say you're on MacOS, see what Apple does with that profile. Who knows, maybe you encounter a bug and you can get money out of it from Apple's bug hunting program. Good luck!
Have you tried uninstalling Firefox, deleting any residual appdata, and installing again? Have you tried installing the same version of FF Nightly and FF on another macOS computer?
Much less radical is just to use the command line options to create a new profile and see what happens. I have fixed obscure problems in firefox by blowing away the profile. 99% of what I need is stored in firefox sync so it's an easy process to delete an old profile and sync back up. Sounds like OP wants to get to the bottom of this though as a haX0r-ng project.
Did you reuse existing profiles on both versions, or in either case did you start a completely fresh profile? If you haven't yet tested with a newly-created profile (which doesn't require deleting your existing profile), then you need to do so in order to triage whether the problem is with Firefox-by-default or Firefox-and-your-profile.
Since it exists in both versions of FF, could you have anything installed which could be interfering with FF's communication with the rest of the internet? Are you on a network with a router which is able to modify your traffic (requires custom SSL certificate) (long shot)?
I'd try installing your version of FF Nightly on another macOS computer to rule out that possibility. Maybe it's not a config issue but something to do with Nightly which is affecting your other, release FF
When a problem is this specific to a single user, I begin to suspect actual bit-rot.
Probably worth checksumming the whole Firefox install against what it should be (or the poor man's checksum: uninstall it and reinstall it). If that fixes it, it might have been a one-time thing, or it might be the start of the end of that machine.
Ages ago, I had a machine administered by a company with a very robust binary check-summer. All of a sudden, one of the system libraries started failing to run... The check-summer would block any executable that tried to run with a hash that didn't match one on the allow-list. Took it to company IT, and they checked a couple things and said "No, this is a legit block... Your checksum doesn't match what the binary should be. Have you been having any problems with this machine?"
Wasn't until somebody asked that I realized the once-in-a-blue-moon kernel panics the machine would give were probably worth mentioning to someone. They concluded I probably had a disk controller with just enough badness to fail very, very occasionally... Usually the failure would manifest as a kernel panic, but I must have gotten unlucky and had it fail during a write operation without tripping a validation error. Replaced the machine; no further problems.
When Mozilla started making big changes to tracking protection, somewhere around versions 86-90, I started noticing all sorts of broken credential management stuff, and I wonder if this is just another manifestation of that.
With strict ETP turned on, extensions like Cookie AutoDelete stopped working due to some new access restriction[0], and cookies that had been set while strict ETP was turned on—even when it was turned off again—became zombies that could only be deleted through about:preferences.
I’ve had to manually set `privacy.purge_trackers.enabled` to `false` to get it to stop automatically erasing (first-party!) login cookies several times per week. I do not understand what kind of heuristic is being used to decide something is a tracker, but it seems to be not good at it.
For a while, Firefox would also randomly prompt me for a master password after running for about 24 hours. This seemed to stop when I turned off strict ETP, but other people reporting the same problem said they didn’t even have strict ETP turned on to begin with, so who knows? It’s all just so random.
I still have situations today where I navigate (via the address bar or the browser history) to HN, or GitHub, or some other site where I have a valid login cookie, and Firefox just decides that it’s not going to send the cookie this time. If I reload the page, it decides now it will send the cookie. If I perform the exact same navigation that broke a moment ago, now it works fine.
I have no idea what changed, and everything that happens—just like the OP’s problem—is so weird and vague that I cannot even submit a decent bug report. At least this bug is consistent; most of my problems seem to be data races. I hope they are able to figure out what is going wrong and, ideally, that it leads to some fixes for whatever broken logic is causing so much trouble with credential management in general.
Can confirm that I have experienced the same problem you've described (sometimes it just doesn't send the cookies upon initially navigating to a site, and after a refresh suddenly I'm logged in and everything is fine). It's so sporadic I don't know how to report it. At least it's not just me I guess :/
OP here: I created a new profile in "about:profiles". I can login into HN from that profile. The bug is in the profile then, I just need to figure if it is fixable without nuking the profile.
This is the epitome of technological blue balls. I really want to know what's going on. Have you tried making a completely new profile rather than modifying an existing one? Trying in private browsing mode? Making a new user in osx, installing Firefox for that user and trying to login?
I expect an update post when you finally get to the bottom of this!
I tried that, it didn't work. I love containers, and it was one of my attempts to solve it. I forgot to include that one in the post, I've tried so many things...
At this point, I'd create a new profile and try again. I know that you've already tried both Stable and Nightly, but there is a possibility that both of their profiles have been corrupted by some external factor. If the issue is not at the container level, then it's probably at the profile level.
It does. But damn, two corrupt profiles? One on each Firefox? What is the chance of that?!
Anyway, my last attempt will be to create a new profile. I was avoiding that because it feels like quitting. It feels like destroying everything and replanting the soil hoping for a better outcome even though you have no idea what happened before.
It's just a debugging step. Don't delete your existing profile. If you confirm that it's fine in a stock profile, then you can use various methods to see what's different and find the bug (eg. “what non-default settings overrides are set in my profile”).
Make an entirely new profile, I bet it will work. I'm guessing both the existing profiles have something set that is breaking login. No idea what it can be, unless you explicitly blocked cookies from the domain. Not something that you can do accidentally though.
Yeah I've been down this frustrating route before. Somehow your profile has gotten corrupt. You'll probably never know why.
Has happened to me for Chrome and Firefox. Creating a new profile works. Or if you're feeling paranoid, remove any trace of it from the system and do a fresh install.
Try looking at about:support to see if there are any third-party modules (antivirus etc. loaded). That has been a cause of problems like this in the past. More likely on Windows and I saw you're running macOS, but worth a shot.
The only plugins in the Plugins section of about:addons should be the OpenH264 plugin and the Widevine plugin (only if DRM is enabled). Both can be disabled there.
Private browsing mode is always my first test for these weird issues. Usually it then boils down to an extension, cookies or cache. It sounds like you only cleared ycombinator related cookies. Maybe it’s worth clearing everything?
I experience the same issue, seemingly randomly, on firefox on Android. I log in, it redirects me to the home page, but I am not logged in. I retry over and over with the same result. The form is filled by my password manager, so I know it is right (I have manually typed in credentials as well, same result).
I just switch to chrome when it happens, and it seems to resolve itself at random. Last time it happened was a few months ago.
Debugging stuff like this is a real nightmare sometimes, but hey, maybe you’ll learn something cool in the process!
One thing I’d try would be to make a new profile - you can launch Firefox with the -P option to bring up the profile manager. I know it doesn’t work with either of your existing Stable or Nightly profiles, but maybe a clean profile will do the trick?
> That problem lasted just some minutes. I’m back logged in in Safari.
You were probably rate limited. I've gotten the "We're having trouble serving your request" thing many times when I accidentally open 20+ HN bookmarks.
HN limits POST requests to one every 2 seconds or so per IP address. I'm often getting this when upvoting/posting and then immediately performing an action in a different tab. I suspect this is a fairly recent change because I don't remember this being a problem a year ago or so.
Yes, but it was the only story I remembered on the spot that had a very personal devil that challenged only the main character :-)
I too am hoping this has a happier ending. All wisdom here points towards making a new profile, which is something I'm avoiding, but if there is no other choice I might try it later.
This sounds exactly like the issue I've been having with my company's instance of Nexus Repository 3 for the past several months. It's a SPA, so I can "log in" and the UI reflects being logged in, but all of the API calls to the backend return a 403. However, this doesn't happen if I use private mode.
I've tried logging off and on HN, and logon is fine (Linux, version 91).
May be you can try:
1. Check the clock on your machine. Make sure it's not running at a time beyond 2038.
2. Check the disk space on your machine, especially where the profile is stored. Out of space error can be causing other errors.
3. Check the file system read/write permission on the profile folder.
4. Make sure there's not another instance of Firefox running. In fact, reboot just to be sure.
5. Try older versions of Firefox, with the portable versions. There's a command line argument to use an existing profile or a new one. Try those. This would narrow the problem down to whether it's caused by your machine or versions of Firefox.
https://mozilla-firefox-portable.en.uptodown.com/windows/ver...
Maybe try running Wireshark and check that the request from FF to HN is sending the cookie?
If the server is fine, the only cause I can imagine is that the request after login does not report the cookie as set. Wireshark should help confirm whether the request is ok.
Then run strace on Firefox and check that the request written out by FF is ok. If that's fine too, then Mac OS must be fudging the request somewhere between when FF writes to the socket and when it actually leaves your machine?
No need for a proxy to check it. HN is very old-school, it is very easy to see the raw requests and stuff. Everything looks as it should be, it just doesn't work.
I'm inclined to believe there is something funky going on with both my profiles. The odds of that happening is very low, but I don't see other options.
That used to be a thing with Firefox profile corruption so they had a tool to copy all your data to a new profile and start there. I think that was pre 2014 ish?
Considering it worked with new profile it is very likely that is what happened here. I am not sure if the profile migration is still there though.
If you are on Windows and your Firefox profile got borked, try ShadowExporer to restore the profile version that still worked. Also check if File History is on and has a copy of your profile (those two are separate features). Then check if you have image backup enabled.
An annoying "feature" of firefox is that if you (even temporarily) run low on storage it will go into a mode where localstorage (and indexdb?) stop working. This makes a lot of sites break for seemingly no reason. You have to restart Firefox to fix it.
Fortunately, HN is not such an abomination that relies on all these “features” when static html, a tiny bit of CSS, and a light sprinkle of JS to gracefully enhance the experience would suffice.
The one thing I noticed is that the updates you posted are at least 3 hours in the future from me (EST). Where are you located? Maybe it has something to do with you being in a certain timezone?
Can you try Lynx/Brave/Waterfox as well? I'd personally be curious to diff the HN cookie stored in each browser and see if there's a difference unique to FF.
I'd also be curious to diff the HTTP requests sent from each browser, particularly FF vs FF forks.
It looks like it, but it is happening on two separate profiles. Both my Nightly profile and my Firefox stable version profile. Unless both profiles are corrupt, which would be odd.
If you've got this dated view about Firefox it might be worth giving it another try. It's come on leaps and bounds, pretty much equally on par of speed against Chrome/Edge etc.
Only/One thing I hate about Firefox (under Windows) is it updates in the background with the helper service but the update isn’t fully applied until next launch. So you start Firefox, wait the requisite time for the entire browser to load, then your screen flashes and FF disappears, then it relaunches again for real.
The old experience of manually updating it yourself when you felt like it was less annoying than this evergreen implementation!
If you use multiple profiles (e.g. i have a "personal" and a "work" profile), the experience is pretty bad -- if you close all windows of one profile, it considers itself as "exited" and overwrites the program files. And then your other profile windows no longer work: any page navigation results in "We're sorry, we just need to do one small thing" and a required restart of your browser.
> "We're sorry, we just need to do one small thing"
I get that even with a single profile. It's infuriating, because it happens when I go to a new site, and that new site is often not restored after it restarts - sometimes I lose it completely.
Containers is amazing but is missing one key feature: addons isolation.
My Profile A have only ublock + bitwarden installed (my most trusted extensions)
My Profile B have random useful extensions for sites like reddit and youtube that I don't necessarily trust but I don't care if only reddit data or my unlogged youtube profile gets compromised as it doesn't mix with my personal profile.
I know that there's a permission system for addons but it's ridiculously bad as many extensions simply need/want permission for all your browsing data or access to all your tabs, history, etc.
Firefox is basically as good as Chrome but it also has a default stance of protecting the users instead of giving all of your data directly to Google. Certainly it isn't perfect, but you feel like a bit less of a product when you use it. To make the HN crowd happy they have (re)written a bunch of the codebase in Rust.
Tongue out of cheek, I worry less about Firefox's future than I would a browser with an equivalent market share but without a lot of developers aware of how the sausage is made backing it out of opposition to a Google monopoly. It might be a minority brower, but by virtue of who it attracts that minority is pretty important when it comes to the web.
Except for Google using it to track every single website and URL you visit.
And preventing you from using a real ad blocker.
And running background processes on your computer that tell Google what other programs you have installed, the visible SSIDs from your WiFi chipset, etc.
When I do that, I see behaviour like you are describing it: when I e.g. tried upvoting jedberg's comment with cookies disallowed, it actually worked. I was redirected to the login page and back to the discussion without staying logged in. After undoing the permission change, logging in and having a look at the exact comment, I saw that the vote actually went through. Posting a new comment showed the same behaviour.
You can find that permission on the "page info" dialog (shortcut Ctrl+I if that isn't localized?)?
Edit: the error message on the console would be different though. The described procedure leads to the message "Setting cookie ... has been denied because of a permission set by the user" (translated from German, so the actual message will be different). It looks like I was only describing the behaviour when cookies are unavailable and not the actual reason.