[email protected] wrote:
Lightning is the usual culprit...
By default, Lightning adds it's version info to the browser's user-agent
string. I don't really see any reason for doing that, but have sometimes
found it confuses sites which attempt to adapt to your browser based on
the user-agent string.
Try disabling Edit > Preferences > Advanced > HTTP Networking >
Advertise Lightning installation.
Also try both enabling and disabling "Advertise Firefox compatibility"
at the same place. Although enabling it usually helps (if it has any
effect at all), I have come across some sites which work with that
option disabled but not with it enabled.
Interesting.
For OP, my initial suggestion would have been adjust UA spoofing, so
that it's not showing FF 52. Even though it's still another month before
support for FF 52.9 ESR ends, there's a growing number of sites that are
objecting to 52.x identification. I'm guessing that for many, the
cutoff is probably 57.0.
On my own installation, I do have Lightning installed, and have found
that advertising of Lightning appears even if I'm explicitly spoofing
Firefox (although not other browsers, such as Chrome or Opera). And the
only way that I know that that's happening is seeing that in server logs
that I have access to. It does not show up in either Help -> About or
Help -> Troubleshooting information.
I guess it makes sense that Lightning should be being advertised if
you're using in conjunction with a calendar server. At the moment, I
don't interact with a server, and as such, it's probably safe to turn
off advertising. However, I may be interacting with a server in the
future, and so if I turn it off, I need to remember to turn it back on.
For the privacy-sensitive people who don't like the possibility of
tracking by UA strings, it's probably worth doing.
In the case of Cox, it makes sense that Cox's servers are getting
confused by seeing a UA that shows both "Firefox" and "Lightning",
because Lightning is normally used with Thunderbird. From the
perspective of server admins, Seamonkey isn't widely known, and even if
it is, few server admins will make adjustments for Seamonkey-specific
handling.
That said, I don't believe that a UA string that shows "Seamonkey" in it
is likely to be causing a problem with Cox. From personal experience, I
know that since the time that Seamonkey added the option for Advertise
Firefox Compatibility, I've found it rare that servers will reject a
Seamonkey connection (except, as noted, servers that want more recent
versions of Firefox). Yes, there are a few that don't like seeing a
modified Firefox UA string, nearly all the time, that can be navigated
around by showing a UA that's explicitly Firefox, and a sufficiently
current version).
For me personally, if I'm having problems getting to a site, it's more
often related to some combination of use of AdBlock Plus and/or
NoScript, as well as my pref settings of blocking tracking and third
party cookies.
I've noted before that I keep profiles in both Seamonkey and Firefox
that I call "bare metal", where settings are almost entirely default. If
I'm having problems getting to a site (especially as a one-time thing),
sometimes it's easier to use a bare metal profile, rather than fighting
through tweaking whitelisting prefs. Plus, going that route provides
explicit confirmation that a problem is not "Seamonkey" generically, but
my specific user profile.
Smith
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
