Just tried to install the latest 64-bit build of Basilisk (2018.11.04) on my system.I used the upgrade method first, then a proper clean install afterwards.For both methods, the browser seemed to work just fine at my end.

There are 20 builds at 20 different stages of development (sequential commits) now available at ftp://archive.palemoon.org/trybuilds to narrow down exactly which commit caused the issues for the affected users.The builds are in chronological order, which means it should be easy to use bisection: start in the middle, and if the problem isn't there, choose a later build. if the problem is there choose an earlier build. If you pick the middle of the earlier or later builds range each time it should only take a few steps to find where the issue started.Please report back with the latest build that doesn't have the issue and the first build that does.

Last edited by Moonchild on Tue, 06 Nov 2018, 18:47, edited 1 time in total.

Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

Awesome, thanks for testing and the independent verification.I'll probably launch off a build for the Pale Moon unstable channel tonight so that could be used to verify the fix; Basilisk update probably tomorrow.

Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

I have followed this thread since it started. Didn't post because I didn't have the problem.I didn't think it would be helpful to post and say "Works for me".I have tested every version linked to on three systems:Win 7 home x64Win 8.1 x64Win 10 VMand every single version linked to in this thread worked correctly.

Most likely because of a suspected race condition involved in the relevant code which would make this extremely timing-dependent (and therefore directly related to system speed, OS load, specific combination of hardware, etc.). e.g. loading the system components for the browser from omni.ja might as a result not give back the detected document type yet when the check was performed and as a result be blocked incorrectly. It would be possible given a lot of time walking the code to find out exactly where this race occurred, but since this was added code for a problem that has been solved in a different way, there is no reason to delve that deep and just consider the Mozilla code for porting incompatible with our tree but otherwise unnecessary to port.So, a best guess answer is all you're getting, I'm afraid

Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

Most likely because of a suspected race condition involved in the relevant code which would make this extremely timing-dependent (and therefore directly related to system speed, OS load, specific combination of hardware, etc.). e.g. loading the system components for the browser from omni.ja might as a result not give back the detected document type yet when the check was performed and as a result be blocked incorrectly. It would be possible given a lot of time walking the code to find out exactly where this race occurred, but since this was added code for a problem that has been solved in a different way, there is no reason to delve that deep and just consider the Mozilla code for porting incompatible with our tree but otherwise unnecessary to port.So, a best guess answer is all you're getting, I'm afraid