Jump to content

My Browser Builds (Part 2)

roytam1
 Share

Recommended Posts

roytam1

roytam1

Posted
  • Author
Posted
1 hour ago, VistaLover said:

Another not welcome :angry: (at least by me) implemented change in latest NM 27.9.7 (32-bit) (2021-02-19), as a result of backporting Fx 41.0 code, is the disappearance of extensions' version numbers inside addons-manager (AOM)

alright I just missed this change, partly reverted.

3
Link to comment
Share on other sites

roytam1

roytam1

Posted
  • Author
Posted
2 hours ago, VistaLover said:

5. Changed Fx related entries inside install.rdf to 


        <em:minVersion>41.0</em:minVersion>
        <em:maxVersion>45.*</em:maxVersion>

... so it could install and work in FxESR 45 fork (hopefully...)

min version doesn't need to be changed since new syntax works in old versions.

Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted
53 minutes ago, roytam1 said:

I just missed this change, partly reverted.

https://github.com/roytam1/palemoon27/commit/3bb6519

Hugely indebted :wub: ; if I might ask, what exact part of #1161183 was not reverted? IOW, will NM27's TychoAM look the same as in previous build 27.9.7 (32-bit) (2021-02-12) ?
Using Aris' extension [Add-ons Manager - Version Number v1.0.1] in latest NM27 isn't a complete solution, because while it does restore version numbers, it takes away the "blue/red dot" feature of TychoAM; I guess this is because said extension uses files from Fx 40.0, not PM27... :(

55 minutes ago, roytam1 said:

min version doesn't need to be changed, since new syntax works in old versions.

Thanks for that :thumbup ; I wasn't sure if that was the case (... I don't speak Javascript :(, remember?), plus I was feeling lazy to test in Fx < 41.0, so to be on the safe side I hardcoded <em:minVersion>41.0</em:minVersion>, with the expectation that Fx < 41.0 users could always continue using v2.1.9 of the extension... :P

Best regards :)

Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted
38 minutes ago, VistaLover said:

Using Aris' extension [Add-ons Manager - Version Number v1.0.1] in latest NM27 isn't a complete solution, because while it does restore version numbers, it takes away the "blue/red dot" feature of TychoAM; I guess this is because said extension uses files from Fx 40.0, not PM27... :(

I think I fixed this with "add_ons_manager_version_number-1.0.2-nm27.xpi" : 

t2gy5KS.jpg

It'll have to do until next week's NM27 build is released... :P

Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted
22 minutes ago, roytam1 said:

the others in https://github.com/rmottola/Arctic-Fox/commit/559bfa7a5245f672235834334bd88be1799a7261

Thanks for the clarification and screengrab :) ; so, the AOM will definitely look as "before", but not act completely as "before" :P ; I browsed briefly the changes inside extensions.js & extensions.xul, what I gathered (at this early morning hour here) - and is proven correct by your image - is that we'll have both the "fixed" version number (as before) and the version number as a tooltip (conceived by Mozilla to replace completely the former :angry: ), when cursor placed inside the extension's entry...

Link to comment
Share on other sites
qjcf

qjcf

Posted
Posted (edited)

Are x86 and x64 profiles interchangeable for Basilisk 52 and 55?

I.e. if I have .\profile folder of Basilisk 52 of x86 version can I copy it to Basilisk 52 x64\profile and expect everything working in the same way, plus better performance due to x64? Or, e.g. if I have .\profile folder generated by Basilisk55 x64, can I copy it to Basilisk55 x86\profile and expect everything working?

To clarify, I don't plan to use Basilisk52 profile with Basilisk55 and vice versa.

Edited by qjcf
Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted (edited)
5 hours ago, qjcf said:

Are x86 and x64 profiles interchangeable for Basilisk 52 and 55?
(snipped)
To clarify, I don't plan to use Basilisk52 profile with Basilisk55 and vice versa.

Profiles of Serpent 52.9.0 are basically architecture independent, except if you have extensions with binary components (very few exist), plus you'll need the x64 versions of some plugins (e.g JRE) if you want them to load in a x64 browser profile... However, I can't currently test with a x64 OS, so take what I said with a very minute (!) pinch of salt... :P

As you noted, mixing profiles of different applications isn't advised - and profile migrations within the same application should only be attempted when updating from an older to a newer application version/build (i.e. not backwards).

Edited by VistaLover
1
Link to comment
Share on other sites
asdf2345

asdf2345

Posted
Posted
7 hours ago, ArcticFoxie said:

I benchmarked x86 versus x64 once-upon-a-time and x86 has better performance than x64, not the other way around.

I do admit that this was a couple years ago, but the results were so CONVINCING and UNDENIABLE that I've never bothered with an x64 browser ever since.

Was it very old Firefox builds?

Link to comment
Share on other sites
exogenesis

exogenesis

Posted
Posted

Security Issue

Newmoon - Palemoon

Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.3a1.win32-git-20210220-729367b92-uxp-2b6effbf2-xpmod-sse.7z

Browser is always set for no cache = 0

After using version above on a commerce site I find after closing this browser In I find in C:\Documents and Settings\USERNAME\Local Settings\Temp these files both of the same size. Each having E-Commerce details including login and email and transactions all security related all should never happen. Not even ever a temporarily file ever to be made which can be recovered by many means inc file recover means. Please fix.

980 KB (1,004,024 bytes)
clipboardcache
clipboardcache-1

I cannot post these files for the same security reasons. We need a fix since most all web sites now need this browser to view sites.

Link to comment
Share on other sites
roytam1

roytam1

Posted
  • Author
Posted
2 hours ago, exogenesis said:

Security Issue

Newmoon - Palemoon

Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.3a1.win32-git-20210220-729367b92-uxp-2b6effbf2-xpmod-sse.7z

Browser is always set for no cache = 0

After using version above on a commerce site I find after closing this browser In I find in C:\Documents and Settings\USERNAME\Local Settings\Temp these files both of the same size. Each having E-Commerce details including login and email and transactions all security related all should never happen. Not even ever a temporarily file ever to be made which can be recovered by many means inc file recover means. Please fix.

980 KB (1,004,024 bytes)
clipboardcache
clipboardcache-1

I cannot post these files for the same security reasons. We need a fix since most all web sites now need this browser to view sites.

since there is no related changes between previous build to this build, and I'm unable to reproduce the issue, I can't give any advice.

Link to comment
Share on other sites
XPerceniol

XPerceniol

Posted
Posted (edited)

I'm using the PaleMoon/28.10.3a1 - Build ID: 20210218230304.

My C:\Documents and Settings\USERNAME\Local Settings\Application Data\Temp folder is empty even after posting and logging in to a few sites upon closing the browser.

I'm not sure if my prefs are helping me with this, but here they are just in case.

user_pref("privacy.clearOnShutdown.connectivityData", true);
user_pref("privacy.clearOnShutdown.offlineApps", true);
user_pref("privacy.clearOnShutdown.passwords", true);
user_pref("privacy.clearOnShutdown.siteSettings", true);
user_pref("privacy.firstparty.isolate", true);
user_pref("privacy.sanitize.migrateFx3Prefs", true);
user_pref("privacy.sanitize.sanitizeOnShutdown", true);
user_pref("privacy.sanitize.timeSpan", 0);
user_pref("privacy.userContext.ui.enabled", true);

EDIT:

The only file remaining on my system upon closing the browser, is in:

C:\Documents and Settings\USERNAME\Local Settings\Application Data\Moonchild Productions\Pale Moon\Profiles\PROFILE\startupCache:

startupCache.4.little [1.65 MB] Upon examination, it appears to contain nonsense and I don't see any personal information within it ?

 

Edited by XPerceniol
typos :(
Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted (edited)

@exogenesis, @roytam1

https://bugzilla.mozilla.org/show_bug.cgi?id=335545

https://bugzilla.mozilla.org/show_bug.cgi?id=335545#c14

Quote

This bug still exists in FF 52.0. Additionally, clearing all context via ctrl/shift/del doesn't delete the files, either.
I have attached a POC that creates a 16MB clipboardcache file in the running account's |temp| folder.

https://forums.linuxmint.com/viewtopic.php?t=208270

Quote

Size of clipboard content matters. It's not everything, just content over 1MB currently. It may not happen to everyone. It may be due to some difference in firefox settings which trigger it, but not obviously related to that setting

Google searches also implicate browser extensions...

clipboardcache files are also created by your OS's clipboard manager, when you copy to the clipboard content exceeding some minimum size:

http://jonathan.lalou.free.fr/?p=121

If you want absolute privacy, don't copy/paste login credentials in your browser, type them instead directly (unless, of course, you've been infected with keyloggers :P ) ...

FWIW, #335545 was "resolved" in Fx 60 ...

Edited by VistaLover
2
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...