VistaLover

In my 360EEv11 (Chromium-69-based) copy, to get GitHub (that I use a lot...) fully functional, I had to polyfill: globalThis (implemented in Chrome 71) Object.fromEntries (implemented in Chrome 73) Promise.any (implemented in Chrome 85) Promise.allSettled (implemented in Chrome 76) queueMicrotask (implemented in Chrome 71) String.replaceAll (implemented in Chrome 85) replaceChildren (implemented in Chrome 86) I'm using a local fork of your original extension, BTW, so many thanks! However, even those 7 polyfills won't be enough, it seems , because, over the last couple of months, those M$ employees have been trialing ECMAScript2020/2022 syntax with unsupported (by both UXP+Chromium<85) operators (Nullish coalescing, "??", and optional chaining, "?.") which can't be polyfilled; thus, GitHub becomes severely broken (to the point of unusable); at the time of this writing, they have reverted that breaking code, but it's dead certain it'll come back (since it's supported by M$'s sweet child, ChrEdge) ... NM28 is UXP-based, to get GH functional, use any of https://github.com/JustOff/github-wc-polyfill https://github.com/SeaHOH/github-wc-polyfill https://github.com/martok/palefill Those only support officially Pale Moon (but NOT v30.0), so to install in NM28 you have to modify maxVersion inside install.rdf; GH+GL break the extension constantly, so make sure you're always on the latest stable/beta build...

Much obliged ; for transparency purposes, though, perhaps you'd be kind enough to let us know of the reason(s) the original binary broke and what measures you actually took to restore intended functionality... Just sayin', thanks all the same!

360EEv12 (Chromium 78) on VistaSP2 x86: Problems Detected for Hardware GPU Hardware video decode is only supported in win7+: 159458 Disabled Features: accelerated_video_decode All Intel drivers before 8.15.10.2021 are buggy with Stage3D baseline mode: 172771 Disabled Features: flash_stage3d_baseline Accelerated video decode interferes with GPU sandbox on older Intel drivers: 180695, 298968, 436968 Disabled Features: accelerated_video_decode Disable GPU on all Windows versions prior to and including Vista: 315199 Disabled Features: flash_stage3d, gpu_compositing, gpu_rasterization, flash3d, metal, accelerated_webgl2, accelerated_2d_canvas, protected_video_decode, oop_rasterization, accelerated_video_decode, android_surface_control, accelerated_webgl, flash_stage3d_baseline GPU rasterization should only be enabled on NVIDIA and Intel and AMD RX-R2 GPUs with DX11+ or any GPU using ANGLE's GL backend.: 643850 Disabled Features: gpu_rasterization Disable use of D3D11/WebGL2 on Windows Vista and lower Disabled Features: accelerated_webgl2 Old Intel drivers cannot reliably support D3D11/WebGL2: 363721 Disabled Features: accelerated_webgl2 Protected video decoding with swap chain is for Windows and Intel only Disabled Features: protected_video_decode Intel drivers older than 2010 on Windows are possibly unreliable: 72979, 89802, 315205, 977432 Disabled Features: flash3d, flash_stage3d, accelerated_webgl, accelerated_2d_canvas Some drivers are unable to reset the D3D device in the GPU process sandbox Applied Workarounds: exit_on_context_lost Disable use of Direct3D 11 on Windows Vista and lower Applied Workarounds: disable_d3d11 Clear uniforms before first program use on all platforms: 124764, 349137 Applied Workarounds: clear_uniforms_before_first_program_use Always rewrite vec/mat constructors to be consistent: 398694 Applied Workarounds: scalarize_vec_and_mat_constructor_args Old Intel drivers cannot reliably support D3D11: 363721 Applied Workarounds: disable_d3d11 On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565 Applied Workarounds: msaa_is_slow Framebuffer discarding can hurt performance on non-tilers: 570897 Applied Workarounds: disable_discard_framebuffer Direct composition flashes black initially on Win <10: 588588 Applied Workarounds: disable_direct_composition Zero copy DXGI video hangs on shutdown on Win < 8.1: 621190 Applied Workarounds: disable_dxgi_zero_copy_video Disable KHR_blend_equation_advanced until cc shaders are updated: 661715 Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent) Decode and Encode before generateMipmap for srgb format textures on Windows: 634519 Applied Workarounds: decode_encode_srgb_for_generatemipmap VPx decoding isn't supported well before Windows 10 creators update.: 616318, 667532 Applied Workarounds: disable_accelerated_vpx_decode Accelerated VPx decoding is hanging on some videos.: 654111 Applied Workarounds: disable_accelerated_vpx_decode Overlay sizes bigger than screen aren't accelerated on some Intel drivers: 720059 Applied Workarounds: disable_larger_than_screen_overlays Delayed copy NV12 crashes on Intel on Windows <= 8.1.: 727216 Applied Workarounds: disable_delayed_copy_nv12 Dynamic texture map crashes on Intel drivers less than version 24: 890227 Applied Workarounds: disable_nv12_dynamic_textures Raster is using a single thread. Disabled Features: multiple_raster_threads With chrome://flags/#ignore-gpu-blacklist set to Enabled (and browser restarted): and Problems Detected Some drivers are unable to reset the D3D device in the GPU process sandbox Applied Workarounds: exit_on_context_lost Disable use of Direct3D 11 on Windows Vista and lower Applied Workarounds: disable_d3d11 Clear uniforms before first program use on all platforms: 124764, 349137 Applied Workarounds: clear_uniforms_before_first_program_use Always rewrite vec/mat constructors to be consistent: 398694 Applied Workarounds: scalarize_vec_and_mat_constructor_args Old Intel drivers cannot reliably support D3D11: 363721 Applied Workarounds: disable_d3d11 ANGLE crash on glReadPixels from incomplete cube map texture: 518889 Applied Workarounds: force_cube_complete On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565 Applied Workarounds: msaa_is_slow Framebuffer discarding can hurt performance on non-tilers: 570897 Applied Workarounds: disable_discard_framebuffer Direct composition flashes black initially on Win <10: 588588 Applied Workarounds: disable_direct_composition Zero copy DXGI video hangs on shutdown on Win < 8.1: 621190 Applied Workarounds: disable_dxgi_zero_copy_video Disable KHR_blend_equation_advanced until cc shaders are updated: 661715 Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent) Decode and Encode before generateMipmap for srgb format textures on Windows: 634519 Applied Workarounds: decode_encode_srgb_for_generatemipmap VPx decoding isn't supported well before Windows 10 creators update.: 616318, 667532 Applied Workarounds: disable_accelerated_vpx_decode Accelerated VPx decoding is hanging on some videos.: 654111 Applied Workarounds: disable_accelerated_vpx_decode Overlay sizes bigger than screen aren't accelerated on some Intel drivers: 720059 Applied Workarounds: disable_larger_than_screen_overlays Delayed copy NV12 crashes on Intel on Windows <= 8.1.: 727216 Applied Workarounds: disable_delayed_copy_nv12 Dynamic texture map crashes on Intel drivers less than version 24: 890227 Applied Workarounds: disable_nv12_dynamic_textures Raster is using a single thread. Disabled Features: multiple_raster_threads ANGLE Features disable_program_caching_for_transform_feedback (Frontend workarounds): Disabled On Qualcomm GPUs, program binaries don't contain transform feedback varyings lose_context_on_out_of_memory (Frontend workarounds): Enabled Some users rely on a lost context notification if a GL_OUT_OF_MEMORY error occurs scalarize_vec_and_mat_constructor_args (Frontend workarounds) 398694: Enabled Always rewrite vec/mat constructors to be consistent sync_framebuffer_bindings_on_tex_image (Frontend workarounds): Disabled On Windows Intel OpenGL drivers TexImage sometimes seems to interact with the Framebuffer add_dummy_texture_no_render_target (D3D workarounds) anglebug:2152: Disabled On D3D ntel drivers <4815 when rendering with no render target, two bugs lead to incorrect behavior allow_clear_for_robust_resource_init (D3D workarounds) 941620: Disabled Some drivers corrupt texture data when clearing for robust resource initialization. call_clear_twice (D3D workarounds) 655534: Disabled On some Intel drivers, using clear() may not take effect depth_stencil_blit_extra_copy (D3D workarounds) anglebug:1452: Disabled Bug in NVIDIA D3D11 Driver version <=347.88 and >368.81 triggers a TDR when using CopySubresourceRegion from a staging texture to a depth/stencil disable_b5g6r5_support (D3D workarounds): Disabled On Intel and AMD drivers, textures with the format DXGI_FORMAT_B5G6R5_UNORM have incorrect data emulate_isnan_float (D3D workarounds) 650547: Disabled On some Intel drivers, using isnan() on highp float will get wrong answer emulate_tiny_stencil_textures (D3D workarounds): Disabled On some AMD drivers, 1x1 and 2x2 mips of depth/stencil textures aren't sampled correctly expand_integer_pow_expressions (D3D workarounds): Enabled The HLSL optimizer has a bug with optimizing 'pow' in certain integer-valued expressions flush_after_ending_transform_feedback (D3D workarounds): Disabled NVIDIA drivers sometimes write out-of-order results to StreamOut buffers when transform feedback is used to repeatedly write to the same buffer positions force_atomic_value_resolution (D3D workarounds) anglebug:3246: Disabled On an NVIDIA D3D driver, the return value from RWByteAddressBuffer.InterlockedAdd does not resolve when used in the .yzw components of a RWByteAddressBuffer.Store operation get_dimensions_ignores_base_level (D3D workarounds): Disabled Some NVIDIA drivers do not take into account the base level of the texture in the results of the HLSL GetDimensions builtin mrt_perf_workaround (D3D workarounds): Enabled Some NVIDIA D3D11 drivers have a bug where they ignore null render targets pre_add_texel_fetch_offsets (D3D workarounds): Disabled On some Intel drivers, HLSL's function texture.Load returns 0 when the parameter Location is negative, even if the sum of Offset and Location is in range rewrite_unary_minus_operator (D3D workarounds): Disabled On some Intel drivers, evaluating unary minus operator on integer may get wrong answer in vertex shaders select_view_in_geometry_shader (D3D workarounds): Disabled The viewport or render target slice will be selected in the geometry shader stage for the ANGLE_multiview extension set_data_faster_than_image_upload (D3D workarounds): Disabled Set data faster than image upload skip_vs_constant_register_zero (D3D workarounds): Disabled On NVIDIA D3D driver v388.59 in specific cases the driver doesn't handle constant register zero correctly use_instanced_point_sprite_emulation (D3D workarounds): Disabled Some D3D11 renderers do not support geometry shaders for pointsprite emulation use_system_memory_for_constant_buffers (D3D workarounds) 593024: Disabled On some Intel drivers, copying from staging storage to constant buffer storage does not work zero_max_lod (D3D workarounds): Disabled D3D11 is missing an option to disable mipmaps on a mipmapped texture ... But my GPU isn't really up to the task , as I have artifacts (black rectangles) in page rendering: So, back to S/W I am...

One very important aspect of "v1.5_Rev3e" is that it contains internally "openssl-1.1.1d" (requires at least VistaSP2, ported to WinXP SP3 by @Mathwiz , IIANM, and then compiled with (XP_EoS) Py3.4 by @heinoganda), which bestows this "HTTPS Proxy" TLSv1.3 (final) capabilities (not present in openssl 1.0.2x/1.1.0x); while properly configured web servers do still offer fallback to TLSv1.2, some secure URLs are currently TLSv1.3 exclusive; so, if access to these must be realised via the IE web engine (e.g. an application dependent on system crypto libs/schannel), "Rev3e" is the way to go! ... Thanks @Dave-H for sharing

... Not quite ; JustOff is a Ukrainian national and he's now (most probably) fighting against his country's invaders (not gonna say more, as being OT to these forums)... Soon after the invasion took place, he shared maintainership of the github-wc-polyfill extension with a Chinese developer, whose GH username is SeaHOH (I don't know if I'm right but, based on my Chemistry background, I amicably refer to him as "seawater" ...) SeaHOH is a very competent master of Javascript (with a slightly worse command of the English language compared to JustOff, but, OTOH, my Mandarin is non-existent ); I've reported several bugs myself over in the GitHub issue tracker and he's been very helpful/successful at addressing them ; TL;DR: All beta and stable releases after 1.2.14b2 are the product of SeaHOH's efforts! The latest stable release, 1.2.16 , works wonders with latest Serpent v52.9.0 (2022-02-25) (32-bit); to install, visit the linked GH page, left click on the XPI link and accept the installation prompt from GitHub; else, if you want to first fetch the XPI to disk and then install, you'd have to modify manually the install.rdf file within the XPI (the maxVersion value); this has been explained repetitively inside these threads... NB: The extension requires very recent UXP browsers (New Moon/Serpent), it does nothing in Firefox ESR 52.9.x and close to nothing in recent Serpent 55.0.0 (if force-installed there). Loads and functions fine here: (latest St52+gh-wc-pf-1.2.16)

https://msfn.org/board/ What I don't know is how long that sum will keep things going for...

The following was posted today by the site's owner: After the on-going war in Ukraine, this is the second most distressing development for me, should it actually be implemented! With energy (electricity+natural gas+petrol) prices hitting all-time highs, I can understand server costs are also up, yet the very same reasons leave very little room for donations for the average MSFN member that struggles considerably as it is to cope with RL's current demands... Hard times, indeed...

Many thanks!

I think it's safe to say the PM feature is currently broken for all (it is for me, too, on latest St52); I can't even access my previously stored exchanges... @Dave-H , as an admin, could you please ask/troubleshoot this?

"Sky Broadband;" => Why/how would your ISP modify your IE UA? "BTRS111060;" => origin of this? "chromeframe/32.0.1700.107;" => as others advised, uninstall completely and restart the OS! "BRI/2" => origin of this? The rest look benign, related to Microsoft Office and installed versions of .NET Framework (1.1, 2.0, 3.0, 3.5, 4.0)

... Not to mention he's got ChromeFrame installed (reporting Chromium 32 in the UA) ...

OT: ...This isn't probably the right place to post this, but since I am/was most active in these threads, here comes my bad news: My cherished Toshiba laptop from 2009, that came with Vista OEM 32-bit originally, has died on me a little more than two hours ago... No previous signs of an impending doom, I was merely browsing (in 360EEv11) when the screen just started flickering on a frozen frame, just out of the blue, and I had to disconnect power to forcibly shut it down... After I put the power back in, the laptop simply won't start anymore, the screen remains permanently black, I can feel some disk activity by touching the laptop, but just that... Sadly, I'm completely clueless when it comes to H/W, can be anything from a dead integrated GPU, a dead CPU or something else (the HDD was in good condition, AFAIAA, replaced last in 2017... Of importance to me is 12 year-worth e-mails contained in Windows Mail, and a ton of other valuable things contained in the internal HDD (I don't have recent back-ups of...) This is me posting from sister's Win7 x64 laptop, via a portable Serpent 52 profile I carry on an external HDD... To add insult to injury, I painfully discovered that "portable" 360EE profiles do not carry with them saved cookies/account credentials for sites, unlike Mozilla browsers... Needless to say I feel very distressed now, this is still the Holidays period during an omicron exponential surge, PC repair shops are mostly closed/half-working... I'll probably have the laptop evaluated by a technician during the coming days, I don't hold high hopes for it to be brought back to life (and at what cost?), all I can hope for is that the HDD is OK and salvageable... This was just a "to let you know" post, 2022 apparently only brought havoc to me thus far... Yes, cr*p like this happens, but now that it has, I'm a total wreck inside... I wish all the best to you, despite...

... The breakage is due to JS scripts that are not palatable to the web engines that can be used on Windows XP/Vista... If, like me, you have uBlock Origin installed in your browser, just blanket-forbid all javascript on "web.archive.org" via the pop-up: and then reload the culprit WA page: Of course, WA will nag that JS is disabled, but you'll be able to load the bulk of that M$ KB content, in an easy and reproducible manner... I feel very lazy now , especially after a "full" dinner (in my timezone), but the masochist among you can determine which one (or more) of the 26 scripts uBO blocks is responsible for the breakage under "legacy" browsers... FWIW, my screengrab is from 360EEv11 (Chromium 69 based...). Best regards y'all

... This has happened to me as well, several times... The reason is the local .XPI file is being locked by the browser process after the initial, failed, installation attempt, and thus modifying it with 7-zip fails, too... Don't ask me for details , but if you first exit the browser, the local XPI file will be "released" and should be again modifiable with 7-zip, as expected... Cases for using MTT are basically two: 1. Install Jetpack SDK add-ons in Tycho-derived browsers, e.g. NM27 (these type of extensions were intentionally disabled in Tycho) 2. Install "legacy" Firefox-only extensions in official Pale Moon versions >= 29.2.0 (for which the dual-ID system was revoked); BTW, MTT doesn't install out-of-the-box in official PM (it's inside MCP's extension blocklist). AFAIK, NM28 has retained dual-ID and thus is able to still accept "legacy" Firefox-only extensions (red-dot inside the AOM). The "issue", if you will, with NM28 is that it's an "alpha" dev-channel app, as reflected in its appVersion (e.g. 28.10.4a1), so when an official-PM add-on has a <em:minVersion>28.0.0</em:minVersion> in its install.rdf file, it will still NOT install in NM28, because 28.10.4a1 < 28.0.0 ...

Right click on the install button->Save Link As... Old trick. You actually beat me to it by some minutes... Yes, this has been a long-standing practice in order to archive XPIs off of the "official" extension repo(s), but I bet some still remember a time (possibly a year ago?) when even that "trick" was intentionally disabled (by you-know-whom) via javascript; extension users had to first properly install the extension in their browser, then hunt it down (via Extension ID) in the Extensions directory of the browser profile, to be able to get their "hands" on an XPI (provided the add-on did not unpack upon installation); of course, no good a process if you're not even able to install the add-on in the first place... As you'd imagine, that change in an established behaviour caused un uproar in the official forums, nevertheless the person who implemented it remained adamant (as you'd expect )... It was when good ol' JustOff came to the rescue with WebInstall Ninja that the draconian measures imposed were able to be circumvented and users were, once again, able to store add-on XPIs without first installing them (and that was one more chapter in the "Bad History book" between JustOff and MAT...). ... At a later date, possibly after another "Add-ons Repo" overhaul, the "old" behaviour/trick was silently reinstated... The "Only in Pale Moon/Basilisk", UA-based, block was implemented a short while before the devs switched to Private code repositories...

... You do know who the admin of those two repos is, don't you? ... FWIW, for years all the dev members behind MPC/BinOC protested, in a most vocal fashion, about how many, popular, websites treated their browsers unfairly (i.e. shutting the door to them), solely based on UA-sniffing rather than feature-sniffing; and now, they're practising themselves exactly the same thing they used to criticise... They're even blocking access to parts of their "legitimate" user base (PM+Bk) if, for some reason, they happen to be on some previous version... Yes, they currently only support the very latest "official" browser versions (29.4.2.1/52.9.2021.11.14 at this time) and, on occasion, one or two versions prior to latest; say, e.g., that you are troubleshooting a PM 28.10.0 installation (regression of an extension/browser feature/etc...) and you start with a fresh profile; well, NO, you can't install extensions on it via the official repo, because the "Install Now" button would show up as "Update Pale Moon"; this, in practice, negates the availability on the repo(s) of extension versions compatible with older browser versions ["Add-on Releases (Version History)" on the right sidebar...] . My point really is that the quoted SSUAOs should better include the latest app versions, just to be on the safe side , and will also have to be manually updated accordingly, when newer official releases are announced ...

For new members/readers: That one isn't based on UXP (at least initially...); it is based on Moebius (itself a fork of a Mozilla 53.0a1 Nightly snapshot), a predecessor to UXP; some parts of the UXP platform code did find their way into post-Moebius Serpent 55, though... Don't let an appVersion of "55" fool you; as far as Web Compatibility is concerned, St55 is quite behind compared to recent builds of St52: if a site misbehaves in St52, very few chances (if any) exist it'll behave as expected in St55... I don't use St55 myself very often (only for testing), frequent users (e.g. @Mathwiz) can share more with regards to WebCompat-issues and the "recent" (Chromium-centric) web... Not a surprise, is it? I suspect the web devs of British Gas kludged up something that would only be palatable to recent(-ish) Chromium (I doubt they even tested their web page on latest Firefox - but that one, as we all know, is "sniffin' the rear end" of Chromium for the last few years or more...); UXP (MozillaESR52 based) would simply be something truly alien to them...

@Rod Steel If you insist on installing MTube: 1. Load (in NM28) its main installation page: https://realityripple.com/Software/Mozilla-Extensions/muTube/ 2. Place your cersor on the blue "Install MTube v1.2" button 3. Right-click, select "Save Link as"... 4. You should now have on disk file "{35FF1267-2C7D-5FA8-876D-4EDFC0CB89FB}.xpi"; the string is the extension's ID; for brevity, rename file to "MTube-v1.2-pm.xpi" 5. Extract; delete directory "META-INF" 6. In a proper text editor, open file "install.rdf" and browse to the "Pale Moon" block: <!-- Pale Moon --> <em:targetApplication> <Description> <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id> <em:minVersion>28.*</em:minVersion> 7. Change the value of minVersion from 28.* to 28.10.4a1, then save your changes 8. Rezip (e.g. with WinRAR) the contents of your working directory [MTube-v1.2-pm] to file "MTube-v1.2-nm28.xpi" 9. Open about:addons in NM28, drag and drop file "MTube-v1.2-nm28.xpi" 10. You should now get a prompt (pop-up window) to install... Disclaimer: Haven't tested whether the extension itself works as planned post install, especially considering you're running a NM28 version from last August; YMMV...

What error(s) do you get? Have you tried first downloading the XPI to disk and then installing from file? Upon reading the description of this extension, you actually don't need it per se... All it does is redirect to mobile youtube , the same can be accomplished by a SSUAO in your NM28 copy: general.useragent.override.youtube.com;Mozilla/5.0 (Linux; Android 5.0.2; SAMSUNG SM-A500FU Build/LRX22G) AppleWebKit/537.36 (KHTML, like Gecko) Gecko/20111216 Firefox/9.0 Fennec/9.0

The last version of @roytam1's FxESR 45.9.x fork that would accept the official Mozilla Fx 45.9.0 language packs, https://ftp.mozilla.org/pub/firefox/releases/45.9.0esr/win32/xpi/ is package "firefox-45.9.29-20201010-7391af2bb-win32-sse.7z"; later versions have become incompatible with the original language packs (LPs hereafter...). In said compatible build, browse to the LP you want to install (e.g. Greek = el.xpi) and click on the link; allow the site to install extensions, then click Install; after the installation has been completed, open about:config and locate pref general.useragent.locale Change its value from the default (en-US) to the one matching the freshly installed LP (e.g. el); restart the browser and voila: OTOH, if you wish to move to a more recent Fx45esr version, you'd have to use English exclusively, or adapt yourself the existing LPs to accommodate the locale changes introduced by the "upstream" Roy follows to produce his fork...

Confirmed here, using Serpent 52.9.0; it would appear their web player has been optimised for recent browser engines only, because player-related scripts they serve make UXP choke , due to unsupported regexp: FWIW, I had no issues logging-in to either google.com/youtube.com with Serpent 52.9.0 (so, not with NM28 ); St52 has a built-in SSUAO for google, general.useragent.override.google.com;Mozilla/5.0 (%OS_SLICE% rv:71.0) Gecko/20100101 Firefox/71.0 Basilisk/52.9.0 which, I firmly believe, is the reason I didn't get the "not secure browser" message/error...

... I am a bit perplexed myself, now... I initially recommended v1.7.8.2019.10.27 (pre-release/preview) for Serpent 52 users, then, after the discovery of v1.7.8, I recommended the latter... BUT, release date of the former is 22 Jan 2019, while of the latter is 24 Oct 2018; it appears that "2019" contain changes not documented in the repo's code, because https://github.com/Aris-t2/ClassicThemeRestorer/compare/1.7.8.2019...1.7.8 => There isn’t anything to compare. 1.7.8.2019 and 1.7.8 are identical But I have verified the "2019" versions do contain the change below option which is still left in v1.7.8 (but switching it ON/OFF doesn't affect latest Serpent 52); in any case, if you're on v1.7.8.2019.10.27, you probably can safely stay there... Apologies for unnecessary alarm...

You're welcome ; but, there's more... Unbeknownst to me, Aris-t2 has uploaded and archived the FINAL version of CTR, v1.7.8: https://github.com/Aris-t2/ClassicThemeRestorer/releases/tag/1.7.8 v1.7.8.2019.10.27 was a "preview" and has been installed here (St52) since it was first made available ; it simply still works as expected; no prompt to update it to v1.7.8 was ever shown to me, but I just manually did that, and all went OK; so should you ! TL;DR: All Serpent 52.9.0 users who wish to modify the default Australis GUI must install (or upgrade to) the last/final version of CTR, v1.7.8 Later edit : Please read below While we're at it, your AOM screenshot "smells" of a previous Firefox profile transplant, which is something I have always strongly discouraged Firefox52-migrants to do when switching over to Serpent 52/55... ADB Helper ? Valence ? Do you have any need for these two? (Firefox) Greasemonkey 3.11 should be better substituted with https://addons.basilisk-browser.org/search/?terms=greasemonkey (which should direct you to greasemonkey-3.31.4-pm_forkBranch.xpi) Old YouTube: No longer works In general, if Basilisk-specific updated/forked versions of old Firefox extensions exist, I would advise St52 users to switch to them; my 2c, of course...

@Tomcat76: Have you tried to update CTR v1.6.9.1 to the Basilisk-specific version 1.7.8.2019.10.27 ? https://github.com/Aris-t2/ClassicThemeRestorer/releases/tag/1.7.8.2019 I'm not seeing the AOM breakage you report (still on St52 2021-10-08 here); it probably has to do with an extension/setting of yours that affects the AOM; does it happen on a fresh St52 profile, after installing a test extension? if not, the culprit exists within your current, dirty, profile... Sadly, I have to leave now for a few hours, thus not able to offer anything more substantial as help...

... Nah, not surprised myself... ; the Pale Moon unstable channel was terminated last September (in fairness, not many were using it ) and official Basilisk is in a perpetual BETA status; so, the end recipient is expected to be the guinea pig... Plus, I think MCP's judgement has been impacted lately, namely with their semi-psychotic perception of enemies everywhere, and dealing with this "threat" is what consumes most of their energy currently (e.g. alienating former co-devs, moving to private repos, DMCA-ing fork repos, etc.) ... I recollect saying in these threads that MCP were "good" at removing existing (inherited) code - like WinXP/WinVista/Android/MacOS/EME/WebRTC/WebExtension/Container/Firefox legacy extension/FUEL/marqee support (and probably other things I forget about), but not that good at writing original new code to tackle the demands of the Chromium-dominated web... This latest blunder negates the first part of my assessment... But, I guess, I shouldn't be that harsh; everyones's entitled to a "bad day"/"happens in the best of families"/etc.