Cannot access TidBITS in Firefox 91

Firefox 91 can’t find Tidbits and some other sites when I try to enter the HTML address directly or when I use the Search box to bring up the address and click on it. I type in the address, hit return, and the HTML address returns back to the original one before I entered the address. Same thing happens when I click on a link. When I clicked a link (TidBITS Talk - TidBITS Talk) to Tidbits Talk in Macintouch, Firefox opened a new link that did open the page, and I could move to other Tidbits pages, but I could not log in – that is, the LogIn Box did not respond to me clicking on it. When I clicked on a Macintouch link to the Tidbits home page, it opened a new link with in window (without html etc), but displayed nothing on the page. I can get in with Safari (which is what I’m using now), and Firefox does access many other sites, but not all of them. I tried cleaning out cookies and cache but that achieved nothing but messing up cookies needed to access some other sites. FWIW, I am using the Mojave edition of OS/X.

Is anybody else seeing such problems with Firefox? Any idea what might be the matter? I was away last week, so I don’t know when this started; it was working before August 14.

Jeff Hecht

I just updated to Firefox 91 and it’s loading fine. What addons do you have installed?

Strange. All I can say is that Firefox 91 in Big Sur works fine here for accessing our sites.

Perhaps try in another user account to eliminate the possibility of Firefox preference corruption?

I’m using 91(.0.2) on Mojave, and it seems fine. As suggested, you can try from a different user account, or create a new Firefox profile and use that (in Terminal do /Applications/ -p). Also try turning off all your Add ons and if that works, do a binary search (turn on half, if that works turn on half of those still off, etc.) to see which is the problematic one.

Thanks for the suggestions
The only extensions I have are AdBlock Plus and the Cisco Web Extension.
The only Plugins are the OpenH264 Video Codec from Cisco and the Widevine Content Decryption module from Google.

As far as I can see, there are two specific problems. One is contacting the home page, which shows up blank. The other is contacting the LogIn; clicking the Login does nothing but make the tab label blink.

Turning off AdBlock Plus on the page does not change how Firefox behaves.

Wondering if there might be a ‘can’t get there from here’ problem, I tried Traceroute and got
Traceroute has started…

traceroute: Warning: has multiple addresses; using
traceroute to (, 64 hops max, 72 byte packets
1 fios_quantum_gateway ( 12.369 ms 6.787 ms 5.587 ms
2 ( 8.937 ms 7.720 ms 7.394 ms

I did have some other problems before trashing cookies and caches, but I have not come across any since (beyond the consequences of trashing cookies and caches).

I have work to do and can’t invest much more time in debugging right now.

Two other notes:
I don’t have any other users on this Mac, so I can’t try that easily. When I tried the “SignUp” option in the version of this conversation in Firefox, it also did not respond - just like when I was clicking on LogIn.

To add to the mystery, I have successfully logged in here using Firefox 91.0.0 on my Macbook Air also running Mojave. The Mac that could not log in successfully was my desktop. That seems to suggest that something is wrong with the Firefox 91.0.2 on my desktop. What I can’t tell is whether the problem is the combination of Firefox 91.0.2 and Mojave is the problem or whether the Firefox on my desktop is damaged. Is it worth restoring an earlier version of Firefox from Time Machine?

Thanks, Jeff

I’m a little suspicious of that traceroute. Could you really be only one hop from, or is something one hop away erroneously answering packets sent to that address?


If you have access to an admin account, you can just create a new user account for this purpose. You can delete it when you’re done with it.

You can also use the Firefox Profile Manager to create new profiles within your own account.

Either of the above can rule out a Firefox problem.

Agreed. I see 9 hops from my location (in Northern Virginia) to the TidBITS server:

> host has address has address has IPv6 address 2606:4700:3037::ac43:d539 has IPv6 address 2606:4700:3033::6815:17c7 mail is handled by 0

> traceroute
traceroute to (, 64 hops max, 52 byte packets
 1  gatewayrouter (  0.594 ms  0.343 ms  0.283 ms
 2 (  9.850 ms  9.021 ms  8.885 ms
 3 (  8.959 ms  9.016 ms  8.484 ms
 4 (  14.567 ms  17.597 ms  14.195 ms
 5 (  14.951 ms (  17.693 ms (  16.091 ms
 6 (  15.088 ms  16.953 ms (  16.254 ms
 7 (  46.644 ms  39.125 ms  20.348 ms
 8 (  17.017 ms (  18.414 ms (  15.557 ms
 9 (  16.795 ms  15.071 ms  17.423 ms

> traceroute
traceroute to (, 64 hops max, 52 byte packets
 1  gatewayrouter (  0.620 ms  0.431 ms  0.313 ms
 2 (  9.231 ms  9.132 ms  10.550 ms
 3 (  8.038 ms  9.397 ms  9.331 ms
 4 (  14.712 ms  13.215 ms  14.512 ms
 5 (  16.812 ms  24.845 ms  16.997 ms
 6 (  16.890 ms (  17.051 ms (  15.528 ms
 7 (  16.965 ms  18.398 ms  16.734 ms
 8 (  18.650 ms  30.860 ms (  14.439 ms
 9 (  20.188 ms  21.193 ms  13.855 ms

In both cases, there’s my home router (line 1), then three unidentified Comcast nodes (2-4), then two Comcast backbone nodes in Ashburn, Virginia. Then a Comcast backbone node in San Jose California. Then one unidentified node before the TidBITS destination.

Even if you’re sharing the same ISP with the TidBITS server, there should be at least one router between you and the destination.

I was surprised by the short traceroute, but I get it on everything I try, even on my personal domain hosted by siteground. Maybe Verizon is hiding a lot and has direct connections to everywhere from fios_quantum_gateway ( 12.369 ms 6.787 ms 5.587 ms. It’s a mystery to me – anybody else out there have FiOS?

Although I didn’t have direct access to another user on my desktop, I did have a Macbook Air elsewhere in the house, and it can access Tidbits using Firefox 91.0.0 and Mojave. That looks to me like the problem is the version 91.0.2 of Firefox on my desktop – either because it’s been damaged or because it doesn’t work with something else. (Both machines are on my home network).

Your “fios_quantum_gateway” is the router in your home. If everything appears as if it’s only one hop away, then Verizon is playing some games in their network to hide all the intermediate nodes.

… And after some web searching, it appears that Yes, Verizon is playing games with ICMP. It appears that UDP-based traceroute doesn’t do this.

Do these two commands show different results for you?

> traceroute -P icmp

> traceroute -P udp

Linux and macOS Catalina appear to be using UDP by default. According to the linked article, Windows uses ICMP by default. Of course, since you’re doing your traces from a Mac, Verizon may now be playing the same games with both UDP and ICMP.

Either way, it’s not the cause of your problem if another computer on your LAN is working OK. Definitely try running Firefox in Troubleshoot (safe) mode. Also try creating a new profile. If either works, then consider doing a profile refresh. The refresh will reset most setttings (but not your bookmarks, history and passwords) to factory default.

1 Like

It occurred to me that people might be curious what Verizon is doing to make traceroutes hide all of the intermediate hops. While I don’t know for sure, I can make an educated guess.

All IP packets have a “TTL” (time-to-live) field. When you send a packet somewhere, your computer initializes it to some default value (often 64, 128 or 255). Every time the packet passes through a router, it is decremented by 1. If it reaches 0 before it gets to its destination, then the router that did the last decrement will drop the packet and send an ICMP Time Exceeded packet back to the originator.

Traceroute uses this mechanism to generate an educated guess for the path taken by packets.

It first sends three packets with the TTL field set to 1. This will cause the first router to send back ICMP Time Exceeded packets. It will record the source of those ICMP packets (the first router’s IP address) and report it.

Then it sends three packets with the TTL field set to 2. This will cause the second router to send back the ICMP Time Exceeded packets.

It will continue in this fashion, incrementing the TTL by 1 every 3 packets until it get a response from the destination address, at which point, the protocol stops.

Traditionally, traceroute would send ICMP Echo Request packets, expecting the destination to reply with an ICMP Echo Response packet. These are the same packets used by the ping utility. But this doesn’t work if the destination doesn’t respond to ICMP Echo Request (ping) packets - in which case, the trace never ends - the destination just silently drops everything, making the traceroute utility think the packets are not being delivered (which is technically true).

When used with UDP, it uses a high-numbered port (the macOS man page says it is 33434) where it is very unlikely there will be a service running. When the packet arrives at the destination, it will send back an ICMP Destination Port Unreachable message.

Anyway, there are two possible things Verizon could do to make everything appear to be only one hop away.

One is that it can ignore the TTL value provided by your computer and immediately set a high value (e.g. 64 or 128). This means none of the intermediate nodes will send any ICMP responses. The packet will go straight to the destination, which will reply immediately. Verizon may be doing this as a security measure, in order to hide the topology of their internal network from the rest of the world.

The other possibility is that they’re not sending the packets at all, but are intercepting it at the first Verizon router (e.g. the central office at the other end of your fiber) and are directly sending a response. Hopefully, they’re not doing this because it has the potential to mess up all kinds of Internet traffic if they end up confusing legitimate data packets with traceroute packets.

1 Like

You’re right - quite a difference in the two Traceroutes, and Verizon has been hiding a lot under the rug with ICMP.

[MacMini:~] jeffhecht% traceroute -P icmp
traceroute: Warning: has multiple addresses; using
traceroute to (, 64 hops max, 72 byte packets
1 fios_quantum_gateway ( 8.020 ms 7.178 ms 5.594 ms
2 ( 8.698 ms 9.666 ms 9.403 ms

[MacMini:~] jeffhecht% traceroute -P udp
traceroute: Warning: has multiple addresses; using
traceroute to (, 64 hops max, 52 byte packets
1 fios_quantum_gateway ( 11.788 ms 6.655 ms 7.370 ms
2 * * *
3 ( 15.166 ms ( 9.541 ms 11.073 ms
4 ( 16.246 ms 16.840 ms ( 17.176 ms
5 * * *
6 * * *
7 ( 19.607 ms ( 15.715 ms 18.185 ms
8 & ( 22.060 ms 16.432 ms 15.988 ms
9 ( 16.806 ms ( 15.587 ms 16.214 ms
10 ( 15.214 ms 16.350 ms 16.190 ms
[MacMini:~] jeffhecht%

I’ll take a look at Troubleshoot mode later.

1 Like

I tried using Time Machine to replace Firefox 91.0.2 on my desktop with 90.0.2, and authorized the sign-in but have not yet synched to Firefox on my Laptop. That let me access Tidbits and LogIn on it. Tentatively this seems to have solved the problem. (I think it also created a new profile). I’ll see what happens after I synch and update, but I hope this fixes the problem.

FYI: There’s no need to go to Time Machine to downgrade Firefox. All prior versions may be downloaded from here:

The US-English Mac build of 90.0.2 is here:

As you already discovered, Firefox has a “downgrade protection” feature which automatically creates a new profile if you install an older version. This is designed to prevent profile corruption, since old versions may not be able to handle newer profiles (there is code to upgrade, but not downgrade profile data).

You should be able to copy your old profile folder from Time Machine if you want to keep your profile (as it was before the upgrade).

See also: Install an older version of Firefox | Firefox Help

Thanks - I hadn’t thought about Firefox’s archive of older versions. Although it’s also nice to have Time Machine as an alternative.

But isn’t it possible that it’s the profile that was causing this issue in the first place? Seems more likely to me than it being the version of Firefox. Though I may have missed some details in reading this thread.

I could not pin down the problem; I encountered it on my desktop, but not my laptop, and the two had Firefox properties synched between them, so it was some peculiarity on the desktop. I had to set up a new profile after going back to the older version via Time Machine, and it’s been a bit of a nuisance, it does give me a chance to shake out some of the cruft that’s accumulated. I’ll eventually allow the upgrade on one machine to see if it’s the cause.

Sometimes I wonder if our software technology is reaching a point where new options and upgrades are causing more problems than they solve.

1 Like

I encourage you to keep at least one permanent additional admin account. If for no other reason, then at least in case you need to have your Mac serviced, you don’t have to give up your personal password and account. It’s also useful for testing in a relatively pristine environment, as in this scenario.

1 Like

Absolutely, which is why my initial suggestions were designed to determine that. If @jeff1 hasn’t already tried that, he should, since reinstalling an old profile and re-upgrading will probably re-introduce the same profile corruption.

Synched? In what way?

If you’re using Firefox Sync, then you may be seeing a bug in the sync system. (FWIW, I sync bookmarks, passwords and history, but nothing else.)

If you’re rolling your own sync service (e.g. by synchronizing the Profile file in each Mac’s ~/Library folders using a file-sync service), then you may have caused the problem, especially if they two aren’t running the same version of Firefox, or if both are running at the same time.

1 Like