2018.11.04 File menu bar, address bar, blank window Topic is solved

[Tomaso]

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)

[Tomaso]

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

[Moonchild]

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

Not at all.

[Moonchild]

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.

[chutsetien]

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.

[New Tobin Paradigm]

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!

[kelendral]

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

[New Tobin Paradigm]

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.

[Moonchild]

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.

[Telanor]

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

[New Tobin Paradigm]

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!

[Macca]

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

[FranklinDM]

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

[BrainDedd]

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!

[fillerup]

community effort, hooray!

[kelendral]

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

[billmcct]

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?

[Moonchild]

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

[billmcct]

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"

[Moonchild]

Ah, "So I see said the blind man"

You did ask...