Jump to content

My Browser Builds (Part 1)


Recommended Posts

1 hour ago, VistaLover said:

"Advanced" users in the mozillazine forums deciphered the "blocking code" and offered this fix for Firefox 53; yes, it works in the same way in Fx53, too: 

I just "refreshed" my memory by doing some tests with Release Firefox v53.0.3 32-bit (patched the executable so it would launch under Vista) and it turns out things are a bit different to how I remembered them in the Nightly 52.0a1 branch:

1. By default, Fx 53.0.3 does not ship with the "plugin.load_flash_only" hidden pref; instead I find the following ones:

plugins.flashBlock.enabled;false
plugins.navigator_hide_disabled_flash;false

2. Default "pluginreg.dat" file has version string "0.18t"; of the NPAPI plugins, only Flash is enabled by default (the rest are marked as [INVALID]).

3. In "about:config" I create a boolean pref named "plugin.load_flash_only" with value "false". I restart the browser!

4. New "pluginreg.dat" file is generated, with version string "0.18f"; all available NPAPI plugins are enabled; I did not have to delete previous version of the file (?).

So, it seems at some point the Mozilla devs lifted the restriction that made the deletion of previous "pluginreg.dat" file mandatory in order to restore full NPAPI support in nightly-52.0a1...

As to what it actually was that prohibited @Mathwiz's Serpent55 copy from detecting all available NPAPI plugins in his system, I am still questioning myself; one thing is sure: if you start transplanting existing profiles into other Mozilla forks, things are bound to break; Serpent 52.9.0 != FirefoxESR 52.9.x and, to a greater extent, New Moon 28.5.0a1 != FirefoxESR 52.9.x or even New Moon 28.5.0a1 != Serpent 52.9.0 ! (despite sharing the same platform). Likewise, Serpent 52.9.0 != Serpent 55 and Serpent 55 != FirefoxESR 52.9.x

People changing browsers should always start with new, clean profiles, then selectively migrating parts from their previous profiles (bookmarks, passwords, etc) - extensions should be transferred with extra caution; what worked in one browser (e.g. FxESR 52) might not in the new one (e.g. St55); this is the cumbersome/tiresome way, but the safest way! :yes:

  • Like 1
Link to comment
Share on other sites


Like Mathwiz, I was not aware of the "container tab" until it is removed. I am trying with it in Serpent52 20190323 and becoming fond of it immediately. So I am in those people hoping Roytam would add it back in the next release of Serpent52; For extensions I use I will not going for 52 above.

p.s. I have a question for a pref involved. I assume it means long pressing the "+" sign, but It seems not function here, long pressing opens a normal tab.

1.PNG

Edited by luweitest
more question
Link to comment
Share on other sites

51 minutes ago, VistaLover said:

People changing browsers should always start with new, clean profiles, then selectively migrating parts from their previous profiles (bookmarks, passwords, etc) - extensions should be transferred with extra caution; what worked in one browser (e.g. FxESR 52) might not in the new one (e.g. St55); this is the cumbersome/tiresome way, but the safest way!

Basically agree with this, but my transition from Firefox ESR52.9.1 -> Serpent 52 20190323 may be an exception: I extracted serpent program file (basilisk52-g4.1.win32-git-20190323-0d9f3396a-xpmod.7z),  made a copy of my Firefox profile folder, made profile.ini (in C:\Documents and Settings\<user>\Application Data\Moonchild Productions\Basilisk) point to that copied directory, then ran basilisk.exe, and everything seemed get working right away. The only thing refused to work was ublock origin, and I found there's a legacy version which only lacks script blocking, but I use Noscript so there's no problem. My profile has evolved for more than 10 years and it seems could last even longer...

 

Edited by luweitest
Link to comment
Share on other sites

VistaLover said:


3. In "about:config" I create a boolean pref named "plugin.load_flash_only" with value "false". I restart the browser!
4. New "pluginreg.dat" file is generated, with version string "0.18f"; all available NPAPI plugins are enabled; I did not have to delete previous version of the file (?).
So, it seems at some point the Mozilla devs lifted the restriction that made the deletion of previous "pluginreg.dat" file mandatory in order to restore full NPAPI support in nightly-52.0a1...


May well be, just as another possibility, a pref not visible in about:config doesn't necessarily mean its default value isn't active anyway - just hidden from users yet deeper. Like all the "permissions.default.xxxx" prefs except "image" (others are subdocument, script, xmlhttprequest, stylesheet, media, object, etc. Values if visible are 1/2/3, but with "invisible" working like 1 too)

About a mysterious hidden place with lingering cached effects from addons, some candidates: in the far past it was definitely xul.mfl in profiles (perhaps along with another *.mfl), and later the startupCache folder in profiles, and thought I had once discovered similar cached stuff in "Local Settings" folder but then couldn't reproduce it anymore, and also not sure anymore which version and how. Perhaps because my profiles are usually portable.
  • Like 2
Link to comment
Share on other sites

9 hours ago, luweitest said:

I have a question for a pref involved. I assume it means long pressing the "+" sign, but It seems not function here, long pressing opens a normal tab.

1.PNG

It looks like you may be using an extension which alters the operation of the "+" button. Try disabling it and see if long presses start working.

If so, your only hope is to let the extension developer know about the issue. It wouldn't surprise me if (s)he didn't even know about the container tabs feature!

BTW (I'm pretty sure the OP already did this, but just for the benefit of others): the privacy.userContext.longPressBehavior pref doesn't exist by default; you have to create it with right-click / New / Integer. Then enter the new pref name (privacy.userContext.longPressBehavior) and value (2). Long-pressing the "+" will then bring up the "New container tab" menu so you can easily choose a container for your new tab.

  • Like 1
Link to comment
Share on other sites

11 hours ago, Mathwiz said:

Moebius doesn't seem to respect the app.releaseNotesURL pref, so the "What's new" link in the Help / About Serpent dialog is going to the Basilisk release notes page again (I had pointed it to http://rtfreesoft.blogspot.com/search/label/browser).

In Moebius, that "about:config" pref only controls the Release Notes link in the "about:" "internal" tab; the patch to make it also control the "What's new?" link in the "aboutDialog" box (pop-up window) was only committed by Moonchild during the UXP platform development phase; so it applies to Serpent 52 (and to the Release notes link in PM28) , but not its predecessor, Serpent 55; @roytam1 probably never thought it worthwhile to backport that UXP "cosmetic" feature to Moebius... ;)

Edited by VistaLover
Link to comment
Share on other sites

@DanR20 @Mathwiz @VistaLover Thank you very much for the info, it's been very helpful :) .

 

Just wondering also, what's the proper procedure for updating Serpent without losing custom tweaks and Addons?

 

On 3/30/2019 at 4:18 AM, roytam1 said:

New build of post-deprecated Serpent/moebius for XP!
* Notice: This repo will not be built on regular schedule, and changes are experimental as usual.
** Current moebius patch level should be on par with 52.8, but some security patches can not be applied/ported due to source milestone differences between versions.

And, does the above mean the current release of Serpent/moebius is less secure than FF 52.9.0 ESR?

 

Thanks.

Link to comment
Share on other sites

For an update, you merely need to replace the contents of (whatever) program folder with the contents of the new .7z file. Or you can use @i430VX's installer.

But to migrate from one platform to another, the "proper" procedure is:

11 hours ago, VistaLover said:

People changing browsers should always start with new, clean profiles, then selectively migrating parts from their previous profiles (bookmarks, passwords, etc) - extensions should be transferred with extra caution; what worked in one browser (e.g. FxESR 52) might not in the new one (e.g. St55); this is the cumbersome/tiresome way, but the safest way! :yes:

But - manually reinstall every add-on, user pref, and bookmark? Cumbersome/tiresome is an understatement! "Impractical" comes closer to the mark.

I just re-migrated Serpent from UXP to Moebius to make sure everything would be the same as before, to the extent that's possible. The method I used was simply to copy my two profiles from the old browser profile folder to the new browser profile folder, then create new profiles in the new browser, specifying the folders I just copied. Back in the day, that's also how I migrated from FF 52 to Serpent/UXP in the first place.

IOW, I did exactly what @VistaLover said not to do! :crazy: It may be that going directly from FF to Serpent/Moebius this way is what caused my plus-ins not to work.

But I didn't run into any plug-in issues this time; the main problem I did run into was WE add-ons falsely being flagged as incompatible. Luckily there's a fix for that. From this thread's first post:

On 10/1/2017 at 11:47 AM, roytam1 said:

Q: Extensions/Themes not working after updating binaries.
A: If you encounter extensions not show icon, clicking options button of extension causing browser unresponsive, etc. please try following actions:
1.a Killing palemoon.exe process
1.b Copy whole extensions folder out of profile folder (to somewhere else for example, desktop)
1.c Restart browser without restoring previous sessions
1.d Goto about:addons page
1.e Drop XPI files from the copied-out extensions folder to about:addonss page One-by-One.
1.f After all XPI files are dropped and installed/updated, restart browser

In my case, I didn't need to copy my extensions folder first; I just dragged the .xpi files from the extensions folder of old browser profile onto the about:addons page. Going in the "forward" direction (FF to UXP, or UXP to Moebius), almost everything should be compatible; in my case it all seemed to work except for Tab Mix Plus (which I don't need anyway). Going in the "backward" direction, you're more likely to find incompatible add-ons when you drag and drop; if that happens, you'll have to find and download an older version of the incompatible add-on.

Quote

And, does the above mean the current release of Serpent/moebius is less secure than FF 52.9.0 ESR?

Yes; the PM team has made several fixes to UXP that aren't in Moebius, including some security fixes. UXP browsers (Serpent and NM 28) are probably the most secure browsers available for XP and Vista. But Moebius is still pretty secure, and a bit better in terms of add-on support.

Edited by Mathwiz
  • Like 1
Link to comment
Share on other sites

A question about the future of Pale Moon came up over at the PM forum ( Pale Moon topic )  :

Quote

... is the Pale Moon team's small size an issue regarding new web technologies? For example, if they come out with a WebAssembly 2 allowing for sophisticated user-side AI's, then Pale Moon will have to implement it from scratch because the only other engines supporting it would be Servo and WebKit/Blink, which are incompatible...

As much as I love Pale Moon, and as stupid as Web 2.0 tends to be, I'm slightly concerned about this project's longevity.

 

Here's Matt Tobin's reply:

Quote

And why do you think we have any interest in "sophisticated client-side AI"? That sounds dangerous as hell. Black box artificial intelligence bytecode running in the browser.. I would call that a pandoras box of security risks. Not to mention privacy.

As for the longevity.. The Pale Moon project has been around for 10 years now and has evolved exponentially in the past five years. It isn't even just Pale Moon or even just Moonchild Productions anymore. There is a partly declared alliance now and none of us have any intention of stopping any time soon because there just wouldn't be anything left if we did.

It is abundantly clear that for everyone else total destruction in the name of progress is the name of the game so now more than ever we have to work together to preserve our past and build our future based upon the foundation we inherited.

Put simply, it comes down to the fact that we are the agents of our own salvation. Not Mozilla and certainly not GoogleMicrosoftAppleOperaVivaldiBrave.

"There is a partly declared alliance now and none of us have any intention of stopping any time soon because there just wouldn't be anything left if we did...  now more than ever we have to work together to preserve our past and build our future based upon the foundation we inherited."    

:thumbup  :yes::cheerleader:

Edited by taos
  • Like 1
Link to comment
Share on other sites

On 4/2/2019 at 10:47 PM, VistaLover said:

especially as @roytam1 went the extra mile to patch, after my report, the non-working "preview tab" under the "submit-a-comment" section...

And that thing was broken again, and eventually not fixed this time :(

Btw, why GitHub needs UA spoofing at all for Firefox 52 ESR if the code is compatible?

On 4/2/2019 at 10:47 PM, VistaLover said:

2. Opera 36.0.2130.80 and 37.0.2178.54 (last working in Vista) would support GitHub natively, but they no longer do (even when spoofed to later Chrome/Opera/Firefox versions...).

How did you find that out if the UA spoofing does not help? Because there are no errors in Console?

On 4/2/2019 at 10:47 PM, VistaLover said:

ut you can resume GitHub functionality if you install aforementioned extension (User-Agent Switcher for Chrome) and add a permanent spoof (i.e. SSUAO) "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0" for domain "github.com"

Why spoof UA to Firefox and not to newer Chrome?

On 4/2/2019 at 10:47 PM, VistaLover said:

Selecting a different branch via the dedicated button/wizard is broken; clicking the ellipsis in the commit title to expand it is broken; clicking the dedicated button to copy commit hash broken; various other more complex functions are broken, too (editing a previous issue/comment, "preview" tab in posts, etc.) :realmad:

You listed broken functions; but they are not new. I asked about the new ones. It seems there are no such :)

On 4/2/2019 at 10:47 PM, VistaLover said:

I don't use GitHub myself for code authoring/manipulation, but for every other feature I use it for, I encounter no issue when using latest New Moon 28[5.0.a1]/Serpent 52.9.0 with a SSUAO/FirefoxESR 52.9.x with a SSUAO; granted I, too, get a CSP error in WebConsole:

It seems it does not work for me in NM 28 because my 28 branch version is from October/November 2018. Is it too old for GitHub now? :(

On 4/2/2019 at 10:47 PM, VistaLover said:

you seem very well versed when it comes to Javascript language, perhaps you should explain in more detail where exactly GitHub fails for you; other coders here could offer substantial assistance (other than me saying GitHub just works in NM28

Maybe that's right, it seems I fixed the main problem, but I can't test the results because replacing of JS files does not work; and it does not work because of very strange CSP bahaviour :(

So I really need someone's help here...

Thanks for all your info, though. As a temporary measure I have set up a Windows 7 Lite Edition VM for myself recently... It performs not very bad on Win XP x86.

 

Regards, Alex654.

Edited by Alex654
Link to comment
Share on other sites

On 4/3/2019 at 4:44 AM, siria said:

The only catch is that all those header addons must be disabled to avoid hijacking.

@siria , hat do you mean by hijacking? Some malicious JS extension code?

On 4/3/2019 at 4:28 PM, Mathwiz said:

which wouldn't be bad if it didn't look so much like Win 10

It can be styled. There are many nice looking themes in the catalogue, and which is more important, you can go further and edit userStyle.css (I even made a video on YouTube about it about a year and a half ago).

Personally I use Basic Blue theme (one of the first ones) that is heavily modified using custom styles. The result looks like this:

 

2017-11-29_172621.png

Edited by Alex654
Link to comment
Share on other sites

16 hours ago, luweitest said:

p.s. I have a question for a pref involved. I assume it means long pressing the "+" sign, but It seems not function here, long pressing opens a normal tab.

Works as expected here with Serpent 52.9.0 2019.03.23 (32-bit) in a new/clean profile, even without the preference in question (i.e. privacy.userContext.longPressBehavior;2):

EChS7LZ.jpg

Works also in my heavily "dirty" Serpent 52 profile, but I don't have any tab-bar modifying extensions (actually, I do have Classic Theme Restorer, if that counts...). In your screengrab it looks as though you are using an extension which makes the tab-bar render in a vertical fashion (is it Tree-Style Tabs?), so the "new-tab-button" offered by that extension lacks the "Container Tabs" functionality exhibited by the original "+" button in the native tab-bar; IOW, @Mathwiz is right:

7 hours ago, Mathwiz said:

It looks like you may be using an extension which alters the operation of the "+" button. Try disabling it and see if long presses start working. 

 

  • Like 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.


×
×
  • Create New...