Pale Moon forum

vannilla wrote: ↑

2021-03-22, 21:35

In both cases the served document is the same, it's just the value of the header to change.

So that's an error on the side of the website then. A very peculiar error, but most definitely something we can't do anything about as the browser does exactly what it should be doing in that case (headers take precedence over in-document doctype identifiers).

Indeed, but at least we know where the error is.
I'm going to quote myself to reiterate what I suggested:

You might want to shoot a mail to the drivehq developers telling them to change the header to text/html.

And I'm going to add to that to ask them to simply drop the user agent sniffing since they serve one type of document only.

But why

Moonchild wrote: ↑

2021-03-18, 00:22

There is an unescaped & there but that does not trigger an error.

and

jobbautista9 wrote: ↑

2021-03-18, 04:05

I just downloaded a 28.16.0 Linux binary from archive.palemoon.org and accessed drivehq.com on 12pm PHT. Made an account, tried login. Both works fine.

Wouldn't those have the same problem?
I have
general.useragent.compatMode;1
general.useragent.compatMode.firefox;false
general.useragent.compatMode.gecko;true

I don't remember changing those things (getting Citibank to work is next challenge) and can't find what current string is.

moonbob69 wrote: ↑

2021-03-23, 10:23

Wouldn't those have the same problem?

Because the default compatibility mode is "Firefox Compatibility", which is why I didn't have the problem.

I just set the compatibility mode to "Gecko Compatibility" and "Native", and both of them resulted in a XML parsing error.

moonbob69 wrote: ↑

2021-03-23, 10:23

I don't remember changing those things (getting Citibank to work is next challenge) and can't find what current string is.

Maybe you installed an extension before that for some reason changed those prefs, and then when you uninstall it, it didn't reset the prefs back to default.

This is why it's so important to provide troubleshooting info, and to try testing it in a fresh profile before reporting.

In their first email after the problem was explained to them, drivehq.com didn't seem to know what a "content-type header" was.

But its fixed now, for any of the compatibility options.

moonbob69 wrote: ↑

2021-04-02, 20:07

drivehq.com didn't seem to know what a "content-type header" was.

Oh snap!
This isn't exactly something in their favour.

For the service they are marketing? No, that's quite damning.