Pale Moon forum

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.

Specs:
OS: Windows 8.1 Pro (x64)
CPU: Intel Core i7-4960X, 3.60 GHz.
GPU: Nvidia GeForce GTX 780 Ti
RAM: 8 GB
Security software: Avast (File Shield only)

Could this be related?:
https://bugzilla.mozilla.org/show_bug.cgi?id=1433065

Tomaso wrote:Could this be related?:
https://bugzilla.mozilla.org/show_bug.cgi?id=1433065

Not at all.

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.

Hi there,

I’ve downloaded all the 20 builds and have tested them separately, one by one. Here is the result from my side:

• basilisk-20181106142010-1cfcf17a1.win32: Works fine.
• basilisk-20181106151129-752311fd4.win32: Works fine.
• basilisk-20181106151857-fdbac0959.win32: Works fine.
• basilisk-20181106160657-a2a8c71d7.win32: Works fine.
• basilisk-20181106161215-24a83a813.win32: Works fine.
• basilisk-20181106162134-e0de8181d.win32: Works fine.
• basilisk-20181106162555-e8f913da9.win32: Works fine.
• basilisk-20181106163010-f62eee7c5.win32: NOT FUNCTIONING, started as a no-responding (or ‘pseudo-responding’, more precisely) blank page window.
• basilisk-20181106163413-059397bdd.win32: NOT FUNCTIONING, started as a no/pseudo-responding blank page window.
• basilisk-20181106163825-52b989d53.win32: NOT FUNCTIONING, started as a no/pseudo-responding blank page window.
• basilisk-20181106164309-9dc6bf850.win32: NOT FUNCTIONING, started as a no/pseudo-responding blank page window.
• basilisk-20181106164725-09fec033e.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.
• basilisk-20181106165300-deba73b3b.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.
• basilisk-20181106172440-3b2c342f3.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.
• basilisk-20181106172945-617eb6483.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.
• basilisk-20181106173358-f42d6c39f.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.
• basilisk-20181106173840-030053f1a.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.
• basilisk-20181106174301-90a73cfe2.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.
• basilisk-20181106175324-cc234ff43.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.
• basilisk-20181106182235-1d55939c7.win32: NOT FUNCTIONING, with pseudo-responding Safe Mode notification popped up first and then started in an extremely small window.

Thank you VERY VERY much for testing all those builds.. Expect to see one more build to confirm revering that commit fixes the issue. We're in the home stretch!

My own experience with the build matches that of chutsetien. Same working/not working builds.

kelendral wrote:My own experience with the build matches that of chutsetien. Same working/not working builds.

Good. We have a patch that negates the need for the offending patch at any rate so.. Just look for the confirmation build someone will shove in here very soon.

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.

I can confirm the latest pale moon unstable build is now working for me

Just a heads up to any Interlink unstable users.. I pushed a new unstable at version 6884 for one because of this issue but also.. Changes!

Can confirm the latest Pale Moon unstable (20181106224257) works for me too.

I can confirm that the latest Pale Moon unstable, Basilisk 2018.11.07, and Interlink 6884 no longer exhibits the issue.

Latest portable x64 Palemoon build seems fine for me. Started Basilisk with a clean profile (deleted the AppData) and I get this:



Edit: Looks like I'm late to the party. Time to update
Edit 2: Working! Awesome!

community effort, hooray!

2018-11-07 64 bit installed and my Basilisk install is back to normal operational status.

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 x64
Win 8.1 x64
Win 10 VM
and every single version linked to in this thread worked correctly.

Question? Why only on some systems was it broken?

billmcct wrote:Question? Why only on some systems was it broken?

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

Moonchild wrote:

billmcct wrote:Question? Why only on some systems was it broken?

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

Ah, "So I see said the blind man"

billmcct wrote:Ah, "So I see said the blind man"

You did ask...