VistaLover

360EEv11 (EOL build 2251) has the following flag: The default setting is "Disabled", but, per your suggestion, have flipped it to "Enabled" (and restarted, ofc ), which is the state depicted in the screenshot... I have been running the browser like that for more than 12hr and I have to say I haven't witnessed, sadly, any noticeable decrease in RAM consumption... My session now comprises 17 pinned tabs, of which 13 are internal "chrome://*" URLs; I have 2 additional normal web tabs, a total of 19 tabs open; with #enable-site-per-process in its default disabled stage, I can count 24 individual 360chrome.exe processes in Windows Task Manager (=number of tabs + 5); when the setting is enabled and the very same session of 19 tabs is reloaded, the number of 360chrome.exe processes in TM increases to 26 (=number of tabs + 7) and no appreciable RAM decrease is observed... Opening 360EE's Task Manager reveals that the additional 360chrome.exe processes are due to iframes/subframes, which is consistent with the flag's description in the pic... So, using the suggested flag ends up generating more browser processes, thus I fail to see (and verify, at least in my setup) how that would, in turn, result in a drop in used RAM ... From just reading the flag's description, this is more of a "security/privacy" related flag, than a RAM reducing one...

Yes, from experience, version X of the uninstaller will uninstall ALL (NPAPI, PPAPI, AX) Flash versions <=X This one has a digital signature (SHA-2 only) of Dec 22nd 2020 ; to be honest, I'm quite reluctant to try it out; Adobe are known to be very insidious , so I fear they may have artificially blocked any Flash version from being installed after this tool has been run... But I'm just being paranoid, I suppose... As for version 34, I think in China (and probably in Enterprise distributions) Flash hasn't died with version 32.0.0.465...

For me, this has been rectified as of Jan 12th 2021, ca. 15:00 GMT Thanks to those involved ...

While chrome://net-export/ is indeed a feature of Chromium 69 on which 360EEv11 builds, the Chinese makers of it have not unlocked it in their v11 fork However, that Chromium flag is available in 360EEv12 (Chromium 78 fork) and 360EEv13 (Chromium 86 fork) The bulk of the Chinese telemetry is being removed when the official chrome.dll file is treated with what is known as Patch_by_El_Sanchez, and this process is being done by the Russian RePackers prior to releasing their modified versions of 360EE... From what you have reported in your previous messages, you had what appears to be a major profile (User Data) corruption, so the browser had to revert to a new fresh state... My educated quess is that this process doesn't involve core browser binaries, just profile data... Just some friendly advices: Chromium-type browsers are notorius for being RAM-gobblers, what with having each tab in a separate process... Since you appear to be running 360EEv11 in a low-resourced hardware, with limited RAM/CPU, you'd better avoid opening concurrently a great number of tabs... In chrome://settings/browser make sure you select "Continue where I left off" to have your session remembered when you relaunch; don't install a big number of extensions, as these also consume additional RAM... Go to chrome://flags/#enable-javascript-harmony and set ENABLED, then restart browser; your v11 will then be able to handle more adequately recent webpages... The last version of uBlock Origin that is fully compatible with 360EEv11 is 1.26.2; later ones have serious GUI issues... Take frequent back-ups of your profile (User Data directory); important files there are: Bookmarks Cookies Current Session Current Tabs Last Tabs History Login Data Preferences Secure Preferences Top Sites Web Data (= search engines) For the record, I'm using a 2008 era Vista SP2 32-bit laptop with 3GB of RAM and have never suffered the kind of browser crash you described; with no more than 6 (session) tabs, it takes less than a minute for a "cold" browser start - not using any kind of session manager either, just the built-in one... Using a slightly customised portable repack... Kind regards

... Whatever I posted located inside %windir%\system32\macromed\Flash was from a fresh NPAPI install here, minus the FlashPlayerTrust dir, which was inherited from years of Flash usage... Update on my issues... I had to use the latest Flash Uninstaller (v32.0.0.468) as admin, followed by a system restart to have a clean slate wrt Flash... After system booted, I installed anew latest (v32.0.0.465) Flash NPAPI, and modified the newly created mms.cfg file, as per your instructions: SilentAutoUpdateEnable=0 AutoUpdateDisable=1 DisableAnalytics=1 EOLUninstallDisable=1 EnableAllowList=0 AllowListUrlPattern=file:* AllowListUrlPattern=https://wwwimages.adobe.com/ AllowListUrlPattern=*://chat.kongregate.com/ Then, at long last, my "portable" Serpent 52 was able to load http://chat.kongregate.com/gamez/0009/4075/live/myth_rider_cs3.swf That test was performed without "portable" Flash DLLs in Serpent! However, as I've written already, I prefer to have portable Flash installations, NOT system-wide ones, and, sadly, my testing today proved that the mms.cfg file is only being read/honoured by a Flash DLL/OCX when placed (the mms.cfg file) in its (proper) location of "%windir%\system32\macromed\Flash\" In my own setup, Serpent 52 portable loads the Flash DLL from G:\PortableApps\Basilisk52Portable\Data\plugins\NPSWF32_32_0_0_465.dll ... but for the @Ben Markson method to work in my case, I still have to place modified file mms.cfg inside "C:\Windows\system32\macromed\Flash\" I can live with that as long as the portable browser installation(s) stays in the same machine, but Flash "portability" will be broken when I load my portable Serpent installation on another host... So, for truly portable and working Flash 32.0.0.465, I have to resort to using the patched (@UCyborg method) Flash DLLs ... @Ben Markson , your dedication and assistance on getting this troubleshot here has been loudly applauded ; many thanks indeed

Well, and this is indeed a surprise to me , the redirection I posted about no longer takes place now, the Flash "version check" webpage loads normally: https://get.adobe.com/flashplayer/about/ Thank you @Ben Markson for your kind assistance , but tried as I might I couldn't get your method to work in my Vista SP2 32-bit laptop, neither for "portable" Flash DLLs nor properly installed ones in "%windir%\system32\macromed\flash" This is how above directory looks like after installing latest Flash NPAPI: File mms.cfg reads: SilentAutoUpdateEnable=0 AutoUpdateDisable=0 EOLUninstallDisable=1 EnableAllowList=1 AllowListUrlPattern=file:* AllowListUrlPattern=https://get.adobe.com/* about:plugins in latest Serpent v52.9.0 (2021-01-08) (32-bit) shows: ... but when I visit https://get.adobe.com/flashplayer/about/ I get: I'm out of things to try, since you specifically said: (and the kongregate test flash game doesn't work either, after adding AllowListUrlPattern=https://chat.kongregate.com/ inside mms.cfg ) Any additional insight on this, from anyone, would be welcome... The active_x version for Vista's IE9 proved a bit more tricky... The file to patch is Flash32_32_0_0_465.ocx ; but Adobe's installer has set that file to be READ only, so I wasn't able to patch it in situ (and any of my attempts to remove the READ-only attribute were met with failure, despite me being an admin...) There probably exist more elegant ways to tackle this, but I 1. Copied the file elsewhere, where I had FULL modify permissions. 2. After removing the READ-only attribute, I successfully hex-patched the file. 3. The original .ocx file was renamed with the aid of Unlocker (). 4. A copy of the patched file was put in its place. Result: However, I have 0 intention of using IE9 for Flash content, the experiment was performed simply as a proof of concept... Flash_AX has been now fully removed from the system...

Oops ; ... I had only focused on the 2040 number (and assumed to mean the start of the year), while I did not consider the "just" adverb in your quote, which - now is clear to me that - it meant Enforced EOL date: 2021-01-12 => Patched EOL date: 2040-01-12 Second oops Accounting for local timezone differences, I can now compute that Thu Jan 12 2040 00:00:00 UTC = 2209939200000 ms since epoch ! Thanks again, best regards

Apologies for being thick , but I visited https://currentmillis.com/ and on the right sidebar converter I input 2040 01 01 00 00 00 and that date is calculated to correspond to 2208981600000 (ms since epoch) If I input that figure in https://www.exploringbinary.com/floating-point-converter/ with only Raw Hexadecimal checked in output formats, it produces: 4280128c82380000 which would equate to 000038828C28128042 != 0000C02055148042 Where did I fail?

@Ben Markson I tried to implement "your" method on portable Flash installations, like the one in 360EEv12; adjacent to original file pepflashplayer32_32_0_0_465.dll I manually created file mms.cfg with contents as below: EOLUninstallDisable=1 EnableAllowList=1 AllowListUrlPattern=file:* AllowListUrlPattern=https://www.kongregate.com/games/* restarted the browser and upon visiting the test URL: https://www.kongregate.com/games/fairypoet/wings-of-genesis Adobe Flash wasn't working Am I missing something? Can you advise further? Only ActiveX is installed system-wide, the rest of my browsers are all portable installations, with "portable" Flash DLLs (be it NPAPI/PPAPI)...

https://www.kongregate.com/games/fairypoet/wings-of-genesis ... on the same 360EEv12 version, with PPAPI flash file pepflashplayer32_32_0_0_465.dll hex-patched according to instructions posted previously by @UCyborg :

Unsurprisingly, today (2021/01/12): This is on 360EEv12 (build 1592) and latest PPAPI (32.0.0.465):

16:20 GMT: And gone are the flags, again... And so is the "Country" account settings section:

I can only hypothesize, but there is a special account setting for that: <OT> Are you using some custom dark theme for MSFN? Or is it some extension? <OT/>

... Me too No need to, as you can achieve the same via account settings: BTW, do the IPS people not know how to spell English correctly? "wantt" ???

The "status quo ante" was to always display the designated flag under a member's avatar; as you say, not all members are being totally honest about their actual location (but admins can surely check members' IPs to verify a flag's validity), so my mention of "privacy concerns" was within the context of me trying to figure out a reasoning behind the new configuration of displaying flags only when signed in...

Is this "new" flags configuration due to privacy concerns?

As I have very recently re-posted, Be that as it may, for probably the last time: 1. Latest version of Mypal is 28.17.0 2. There have been no locale string changes since much previous version 28.13.0, so LP for that older version should be compatible with the latest version of Mypal. 3. This is general advice and I lost count of how many times I've posted about it, but in Mozilla-type browsers, for the language pack to take effect, you have to a) visit about:config and search for pref general.useragent.locale The default value would normally be en-US b) change the value to the one corresponding to your locale en-US => it c) restart browser Tada!

The latest release of @roytam1 's fork of FxESR 45 has been the one from last November: http://rtfreesoft.blogspot.com/2020/11/weekly-browser-binaries-20201128.html ... so you can at least update your one-year-old installation to the latest one... BUT (sadly, there always seems to be a "but" lately ), if you, like me, prefer your browser to be localised, then v45.9.29 (buildID=20201008212525), package file name: firefox-45.9.29-20201010-7391af2bb-win32-sse.7z is the last one that supports the original FxESR 45.9.0 language packs: https://ftp.mozilla.org/pub/firefox/releases/45.9.0esr/win32/xpi/

<semi-OT> Another IPS board I occasionally browse (but don't belong to as a registered member) is nsane.forums . That one has also undergone the forum software overhaul last autumn, but the IPS default theme has been kept as a custom choice; do note that what's currently available is an updated iteration of past IPS default, but if one enables the new version now, one can get a good glimpse of what the pre-update version looked like... @asdf2345 : Scroll down to the bottom banner, then choose via "Theme": @siria : I combined your "fixes" into the following Stylem userstyle: @-moz-document domain("msfn.org") { html body.ipsApp li#cUserLink:hover ul#elUserLink_menu { display: inline-block !important; } html body.ipsApp ul#elUserLink_menu { background-color: yellowgreen !important; } html body.ipsApp ul#elUserLink_menu li { line-height: 1 !important; } ul.ipsComment_tools ul.ipsHide:hover, a.ipsComment_ellipsis:hover + ul.ipsHide { display: inline-block !important; position: static !important; } } to be used in Tycho based browsers (NM27, Arctic Fox) ; still, the overall MSFN experience in these browsers is highly problematic ... (I don't mean to be disrespectful , but the site owner tested the new layout only in Google Chrome 87/Win10 and, of course, all things work there as "expected"; so, no sympathy is expected/felt for (us here) users of older browsers on older OSes, which, I believe, is a unique trait of MSFN itself as a broader community, i.e. not to look down on users because of their Windows OS/hardware choices... Anyhow, the dice is cast and Rubicon crossed... ) <semi-OT/>

Update on this: Colour Picker custom selections are now stored in HTML5 cookies: The extension used is CookieKeeper 1.9.3.1

<semiOT> The new forum layout caused real havoc to me... 1. The "primary" and "secondary" colour settings (in "Colour Picker") are no longer stored in cookies. My personal preference was Marble (not the forum default) for both, and then I would protect these cookies with a specialised cookie extension, so that everytime I logged-in, those custom colour settings of mine would stick... 2. The newly instituted "sibebar" unnecessarily takes up horizontal screen space and the new "Customizer" wizard only allows for displaying it on the right (default) or left side of the page ... I ended up removing it altogether via uBlock Origin: msfn.org##.ipsLayout_sidebarright 3. We no longer have "Theme" choices, my preferred "IPS default" theme has vanished, while the only one available theme currently is a poor relative of the former default, "Swift"... 4. In Chromium based browsers, basically 360EE, the Dark Reader Chrome extension no longer yields the excellent dark result it used to with the previous MSFN Forum iteration... 5. The new layout is largely unusable in older browser engines, e.g., as posted already, in Tycho-based browsers like NM27 (Goanna 3 based KM should also be affected, can people check?) . Not only the "reaction" button is just a huge grey circle there: but now the Edit (post) button has been hidden inside a post header ellipsis (...) button, that doesn't work at all in Tycho ! To add insult to injury, to sign-out in NM27 I have to delete MSFN cookies, because the <myusername> button does not respond to clicks! If it was up to me, I would revert the layout changes without second thoughts... But perhaps it's just my middle age revolting against any type of change... If I had to guess, the new IPS forum software is specifically "improved" for the teen-aged users on the latest model of their hyped, touch-screen, mobile device, whereas on desktop devices, basic compatibilty with recent Chromium is all the IPS devs cared for... EDIT: And I just freakin' hate the fact that e-mail notifications now only display a truncated version of the post they refer to, whereas in the previous forum software ALL the relevant post was included in the body of the e-mail; VERY convenient for when the forums go off-line for days (has happened in the past) or for archiving/recovering content when, God forbid, the forum's huge database gets corrupted and months' worth of users' posted content gets forever lost (has already happened once during the time I'm a member here... ) <semiOT/>

In latest 360EEv12 (12.0.1592.0), when one opts to hide the extension's toolbar button, e.g. to unhide it afterwards one has to load either chrome://extensions/ or chrome://myextensions/ and then locate said extension, where a "Show button" button () should be present: Isn't this the case with 360EEv13 ? If not, then I guess this is a regression/bug of v13, which is still in a BETA testing phase... I have NEVER used the official Chinese installer on any version of 360EE, only the portable repacks... I think the redistribution from lrepacks does offer the option to do a "proper" installation, but I've never attempted that... To be honest, it's not quite clear to me what you wish to achieve, but you can specify a path to a custom 360EE (user) "profile" via the option --user-data-dir= and set as value the custom path to a directory used as the profile (provided, of course, you have write permissions there...); you can then launch the browser via an accordingly modified shortcut... I don't have Windows XP to answer your query, but under this old (2008) Vista SP2 laptop, the blacklisted GPU can be force-enabled by the #ignore-gpu-blacklist flag (like you wrote): chrome://flash/ informs me that: GL_RENDERER: ANGLE (Mobile Intel(R) 965 Express Chipset Family Direct3D9Ex vs_3_0 ps_3_0) By default (with software rendering), this is how things look:

As my dear Italian friend mentioned, only the ActiveX version of Flash (e.g. for IE) will be removed via Windows Update in Win > 7; Microsoft Edge (Chromium based) will, no doubt, be updated to a Flash-free version at that same time... NPAPI and PPAPI Flash versions manually installed by the user will have to be also uninstalled manually, but, if your OS is compatible, future browser updates (Mozilla Firefox and the numerous Chromium variants) will come with Flash supporting code completely removed... Of note is the fact that MCP browsers (Pale Moon, Basilisk) and forks will not drop support, but this fact will become a moot point after Jan 12th (unless user downgrades to NPAPI Flash <=32.0.0.71, to satisfy whatever niche needs...).

Today, the official Adobe Flash Player "version check" page no longer shows up; it was still working yesterday, Jan 1st, 2021, successfully detecting the last release, v32.0.0.465 ... https://get.adobe.com/flashplayer/about/ => https://www.adobe.com/products/flashplayer/end-of-life.html ... And it's the very first time they're revealing details about the time-bomb (included in versions > 32.0.0.371) set to go off on 12/01/2021

The first "problem" and the one that needs to be addressed by UXP issue #1675 is the embedded web player on rutube.ru not loading/displaying in UXP browsers (New Moon 28, Serpent 52, IceApe-uxp, BNavigator, etc.), whereas the rest of the rutube.ru site is being loaded/displayed correctly. The second problem (probably unrelated to the first one) with the rutube.ru site is that in NM27 it appears to load at first, but then it vanishes into thin air, leaving an empty tab; in deprecated Mypal 27.9.4 and in Arctic Fox 27.11 (both Tycho forks, much like NM27), the site in question does load (no "second" problem present), but, of course, minus the embedded web player ("first" problem still present...). One begs the question what good it might be having a video portal working in a browser minus the ability to watch videos there (...), but to each their own...