VistaLover

@dmiranda : Try the link below, https://addons.palemoon.org/addon/getemall/ with the following SSUAO (that I successfully use): general.useragent.override.addons.palemoon.org;Mozilla/5.0 (Windows NT 6.3; rv:68.0) Gecko/20100101 Goanna/4.8 Firefox/68.0 PaleMoon/29.4.5

I second that, @roytam1 However, as I am heavily reliant on GitHub, I was sort of miffed that GH still doesn't work in latest St55 (32-bit) with the latest release (v1.2.17) of gh-wc-pf force-installed; in the not-so-distant-past, GH used to (mainly) work in St55, but, as said, M$ threw at it many recent JS "baddies" that eventually broke it completely ... I understand St55 is under a monthly release schedule, how far do you reckon we are from a working GH implementation (of course, with the aid of gh-wc-pf) ? Thanks for all you do for us, "greedy" users of your browsers!

What "3 codec DLLs" are you referring to? New Moon 28 doesn't require any additional "patented decoder DLLs" (aka LAV DLLs), only New Moon 27 does... This should be generally avoided, as "upstream" use a different modded version of the NSS Mozilla library (hence cert8.db+key3.db resultant profile files); at least that's my recollection of them, I stopped closely following their development when they turned "private-repo" last autumn (FWIW, GRE+PM are now public, again ).

(I thought it important to quote all these relevant parts, due to the intervention of a great number of completely irrelevant posts...) @roytam1 : This seems indeed a genuine bug affecting the most recent NM28 release, however it's particular to the 64-bit binary ; as others have already chimed in, the 32-bit binary behaves as expected, below is my own screenshot from it, running (pristine new profile) under physical Windows Vista SP2 32-bit (fully updated, with selected WS2008 updates manually installed): Of course, I couldn't test the 64-bit equivalent there , but I borrowed briefly my sister's Win7 SP1 64-bit laptop (fully updated to Win7 SP1 EoS), and the story is the same (as already reported by @nicolaasjan) : Taking a look at the provided changelog, and at a quick glance, I can only spot [NSS] ported mozilla upstream changes (a squash of several, NSS-related, Bugzilla bugs) as potentially the culprit for this breakage, manifesting exclusively on the 64-bit compile (but I could be wrong, I have been in the past ) ... Could someone also test, for that same bug, the 64-bit distribution of latest Serpent 52.9.0 ? I don't have a need myself for the 64-bit binaries, but, obviously, others do... Thanks in advance for any additional info...

Most sadly, no such hope could ever materialise, at least on the part of the Chinese... 360EEv13 is based on Chromium 86, its latest release currently being 13.0.2310.0 (issued a mere two days ago...); no planned core updates (to Chr>86) are scheduled for v13.0 ... The Chinese have already upgraded their 360EE browser to v21.0 (Chromium 95 based), which has dropped altogether WinXP+Vista support and, to add insult to injury , is being offered exclusively as a 64-bit binary... Sorry for sounding pessimistic, but that "ship" you're alluding to has already sunk ... [For XP/Vista 32-bit users, 360EEv13 is the most advanced version we can currently rely on... It will certainly buy us some additional time (for those of us that have the H/W to properly support it ,), perhaps well until the end of current year, but if "popular" sites insist (as is the trend now) on implementing latest (>=99.0) Chromium features, the end is near... Already several Chromium extensions I currently use (in my 360EEv11-13 copies) have migrated to MV3 (Manifest Version 3), which demands at least Chromium 88; it's fine when older extension versions do still work (but it'll get more difficult to retrieve those older/previous versions), it's not fine when an extension gets updated (alongside MV2->MV3) to mitigate a service/site change it targets... ]

Official Pale Moon v29.4.5 released ... Also, something that really made me ROFL: https://web.archive.org/web/20220322142423/https://forum.palemoon.org/viewtopic.php?f=65&t=28003&start=80#p225547 (above proposal was suggested to Moonchild, perhaps meant seriously, but... really? )

I get similar Javascript Console errors in 360EEv11 (chr69-based): Uncaught SyntaxError: Unexpected token . in https://www.rb.cz/scripts/main.9082edf4740251c6.js And this is by simply loading the page; clicking the blue button produces an additional (CSS?) error: problem calling custom script: ReferenceError: $ is not defined at HTMLDocument.<anonymous> ((index):14) Their "main" script uses no less than 110 (!) invocations of the optional chaining operator (?.), an ECMAScript2020 feature (first implemented in Chromium 80/Firefox 74)... The master villain is, again, a Bank URI; perhaps they "feel" using the latest and greatest JS "goodies" makes them look "more safe" in the eyes of their otherwise "clueless" clients ; I'm of the opinion the @NotHereToPlayGames route should be pursued here, too...

@roytam1 Moonchild has withdrawn the PM 30 branch (both releases v30.0.0 & 30.0.1) and now (only) offers, again, PM v29.4.4, while a "security-only" release v29.4.5 is in the works... The PM 30 milestone will be re-engineered, with a strong probability of the dual GUID system - as was in v29.1.1 - coming back, and a fresh v30.1.0 will (after v29.4.5) be released in "due course"... So, perhaps, it'd be prudent not to hasten merging "current" GRE into "our" UXP tree (as suggested by https://github.com/roytam1/UXP/commits/custom ) ; what are your plans? Many thanks!

Sadly , that "format" of yours no longer produces the "calendar for a specific year" in Tycho-based New Moon 27, so users of that (e.g soggi) and even-older-engine browsers can't profit from it... Works OK, though, for UXP-based browsers ...

Firefox Quantum 63.0, to be exact (less finished implementations were behind a disabled pref in immediately previous Fx versions) ... I, personally, don't give that test the credence/importance others do... Have often found it to misrepresent browser features (especially when it comes to the non-mainstream browser engines), so my advice is to take its reported results "cum grano salis"... According to this UXP open issue, https://repo.palemoon.org/mcp-graveyard/UXP/issues/1361 Shadow DOM v1 is still marked as unfinished (further below in the issue, they cite Element.attachShadow() Element.shadowRoot() DocumentOrShadowRoot.activeElement as having been implemented...) Relevant GRE issue https://repo.palemoon.org/MoonchildProductions/GRE/issues/3009 signals Shadow DOM support is still not "FULL" and, of course, WebComponents support (of which both ShadowDOM+CustomElements are integral parts) is still marked as unimplemented... https://repo.palemoon.org/MoonchildProductions/GRE/issues/3011

... But you did quote in your previous answer @Ben Markson's post about the "mozlz4_edit" add-on (which he installed in FirefoxESR 52.9.0) and that was the bit that got me sort of confused ... Anyhow, there's no point in flogging a dead horse, by now I think the both of us made really clear what we intended to state... Have a nice night, spring already came here in the Northern Hemisphere (but it's awfully cold right now, despite... ) Later addition: soggi commented: This wouldn't have worked in any case , because the "mozlz4_edit" (Fx) extension is of the "Web Extension" format, not compatible with New Moon 28 (and it still wouldn't serve any purpose had it been compatible, because NM28 doesn't use the mozlz4 compression for any of its profile files ...).

This is ONLY applicable as-is for New Moon 27/28 (and possibly some other browsers like BNav & K-Meleon, which I don't use myself); FxESR 52.9.x, St52 & St55 by default DON'T store search engines inside a profile "searchplugins" directory, but inside a profile search.json.mozlz4 file - I thought I was clear on that... If you want to import a manually crafted XML-format search plugin in, e.g., St52 without an extension, you'd first have to manually create a "searchplugins" directory inside the browser's profile (it isn't there by default), place within the XML file and RESTART the browser; then the XML file is internally converted to the JSON format and stored inside the compressed search.json.mozlz4 file (this procedure mimics a profile "upgrade"), after which time you can safely delete the "searchplugins" folder, it served its purpose... What is "cumbersome" for one person might not be for another, I respect that , but let's not dispute the real facts, please... Anyhow, whatever tickles your fancy... Best regards

"Add-to-Search-Bar" is indeed an invaluable extension , nothing cumbersome about it, really... It enables adding search engine(s) even for pages for which no standalone XML plugin files exist/are available, just by placing the cursor inside a page's search input field (e.g. here in MSFN) and adding (via context menu) that search facility as a new browser search engine: No need to analyze page's code and/or craft manually a new XML search plugin... OTOH, even if you make one yourself, you'd need the second extension I mentioned for "search.json.mozlz4" enabled browsers, because these don't have a human-readable searchplugins directory inside their profiles ...

For "search.json.mozlz4" enabled browsers (mostly Serpent 52.9.0/UXP + Serpent 55.0.0/Moebius), I'd recommend the following "legacy" Fx extension: XML Search Engines Exporter/Importer v0.4 (should be also available from within CAA). Instead of having to deal with modifying .mozlz4 databases (a Mozilla-proprietary compression format), you can export standalone XML-format search plugins from within the search.json.mozlz4 file, edit them to your heart's content and then import back the edited plugin ; of course, you can also import already archived, standard, XML search plugins extracted from other browser profiles (e.g. from New Moon 27/28) or downloaded from specialised search-plugin repos...

In UXP-based latest St52 (2022-02-25) (32-bit), the left/right arrows on the top header, that are used to move between previous/later captures of the selected URI, are no longer functional : Error Console Log: Timestamp: 21/03/2022 02:29:58 Error: TypeError: t.getRootNode is not a function Source File: https://web.archive.org/_static/js/bundle-playback.js?v=poeZ53Bz Line: 2 Timestamp: 21/03/2022 02:30:02 Error: TypeError: e is null Source File: https://web.archive.org/_static/js/bundle-playback.js?v=poeZ53Bz Line: 2 ... which suggests UXP-incompatible code (ShadowRoot, first implemented in Fx63) is used now...

That extension started originally as a github-wc-polyfill fork , i.e. ONLY supporting initially GitHub/GitLab; unlike the upstream maintainer (JustOff) not wanting to support other sites beyond those two, the German maintainer (martok) of this fork will accept support requests for other sites broken in current UXP and will explore the possibility/feasibility of applying the necessary polyfills (where available) to address the breakage on those requested sites... At this very moment, the only additional (to GH/GL) site supported is "godbolt.org", while a request for "*.notion.*" URIs is still pending (but supposedly very difficult to materialise) ... https://github.com/martok/palefill/issues?q=is%3Aissue+sort%3Aupdated-desc+is%3Aopen ( ... of this "open issues" group, #3 and #6 aim to add user-side configuration options ) https://github.com/martok/palefill/issues?q=is%3Aissue+sort%3Aupdated-desc+is%3Aclosed

aus.palemoon.org forum.palemoon.org rm-eu.palemoon.org are at this time BACK ; related: https://forum.palemoon.org/viewtopic.php?f=1&p=225096

https://msfn.org/board/topic/182647-my-browser-builds-part-3/?do=findComment&comment=1214463 ... But let me save you the trouble and point out that ONLY official Pale Moon (currently < 30.0.0), official Basilisk (currently EoS'ed with v2022.01.27) and SeaMonkey are being supported; in the recent past, requests for FxESR 52.9.0, New Moon 28 and Serpent 52.9.0 support had all been rejected by JustOff, so I think you get the drift ... M$ employees brought in much breaking code, starting with autumn/fall of 2021 and continuing well into 2022, that "Moebius" simply can't cope with... Also, as you say, Moebius is lacking many recent Web APIs required by the gh-wc-pf extension, it'b be a nightmare, implementation-wise, for that extension to support it... ... probably because MCP had less time to move things around and worsen the performance levels attained originally by Mozilla ... What you can still do is use St55 for everything besides GitHub/GitLab and for these two "villains" use a minimal fresh St52 profile with just uBO+gh-wc-pf extensions...

1,885 changed files with 168,699 additions and 191,064 deletions. Was that just to make things extremely painful for fork-maintainers or did it serve some other agenda? Both of them are Basilisk/Serpent52 exclusive features (GMP/EME - as in functional DRM - broken for ages, but still useful to detect media sites that implement WidevineCDM; also useful for those few that prefer Adobe Primetime CDM's patented decoders over the ffvpx ones, on WinXP; WebRTC, despite claimed to be specs-compliant, fails to work on most WebRTC-enabled sites currently ); what are your thoughts about them in "our" UXP? ... Your thoughts on this, too, please? Let me reassure you, for the Nth time, that your constant efforts to "untangle" what MCP (currently a one-person-team) produce don't go unnoticed ; thanks once more...

Saw the following posted elsewhere a while ago, it concerns "upstream", so relevant to these forks, too: https://old.reddit.com/r/palemoon/comments/ti1okk/ntpmat_hes_done_finally/ https://web.archive.org/web/20220322141859/https://forum.palemoon.org/viewtopic.php?f=65&t=28003 Later EDIT: PM forums are back on-line: https://forum.palemoon.org/viewtopic.php?f=65&t=28003 23/03/2022 EDIT: Above PM forum thread hidden from non-members ; see: https://forum.palemoon.org/viewtopic.php?f=65&t=28058 Currently, the following hostnames are inaccessible: aus.palemoon.org (checks for/delivers updates to official PM browser) forum.palemoon.org (official PM/Bk user support forum, with tons of invaluable info accummulated over the years - much of it also applicable to the forks...) addons-legacy.palemoon.org (extension repo for PM<=29.4.4) addons.palemoon.org (extension repo for PM>=30.0.0) rm-eu.palemoon.org (European CDN that delivers binary releases[installers, 7z packages, portables]) addons.basilisk-browser.org (extension repo for Basilisk)

@roytam1 : I've left NM28 behind me several months ago, now exclusively (from the browsers you are compiling) using Serpent 52.9.0 (32-bit) in this Vista SP2 x86 laptop; what is the future for Serpent 52 with the advent of GRE ? Could platform enhancements implemented in GRE be still backported to St52's UXP? And I don't know whether NM28 users are aware, but GRE fully removes the Pale Moon GUID (also used in NM27/NM28) and a restructure of MCP's add-ons site is currently in progress, will you also adopt this change for future NM28 versions? https://www.palemoon.org/releasenotes.shtml

Here's my copy of file "polyfills.js" inside my local fork of your extension: var actualCode = ` // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis // implemented in Chrome 71 // https://mathiasbynens.be/notes/globalthis (function() { if (typeof globalThis === 'object') return; Object.defineProperty(Object.prototype, '__magic__', { get: function() { return this; }, configurable: true }); __magic__.globalThis = __magic__; delete Object.prototype.__magic__; }()); // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/fromEntries // implemented in Chrome 73 // https://stackoverflow.com/a/68655198 // https://gitlab.com/moongoal/js-polyfill-object.fromentries/-/blob/master/index.js // -> https://vanillajstoolkit.com/polyfills/objectfromentries/ if (!Object.fromEntries) { Object.fromEntries = function (entries) { if (!entries || !entries[Symbol.iterator]) { throw new Error('Object.fromEntries() requires a single iterable argument'); } let obj = {}; for (let [key, value] of entries) { obj[key] = value; } return obj; }; } // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/any // implemented in Chrome 85 // https://github.com/ungap/promise-any // copied from github-wc-polyfill if (!('any' in Promise && typeof Promise.any == 'function')) Promise.any = function($) { return new Promise(function(D, E, A, L) { A = []; L = $.map(function($, i) { return Promise.resolve($).then(D, function(O) { return ((A[i] = O), --L) || E({ errors: A }); }); }).length; }); }; // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled // implemented in Chrome 76 // https://95yashsharma.medium.com/polyfill-for-promise-allsettled-965f9f2a003 if (!('allSettled' in Promise && typeof Promise.allSettled == 'function')) Promise.allSettled = function (promises) { let mappedPromises = promises.map((p) => { return p .then((value) => { return { status: 'fulfilled', value, }; }) .catch((reason) => { return { status: 'rejected', reason, }; }); }); return Promise.all(mappedPromises); }; // https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask // implemented in Chrome 71 // https://stackoverflow.com/a/61569775 (function() { 'use strict'; // lazy get globalThis, there might be better ways const globalObj = typeof globalThis === "object" ? globalThis : typeof global === "object" ? global : typeof window === "object" ? window : typeof self === 'object' ? self : Function('return this')(); if (typeof queueMicrotask !== "function") { const checkIsCallable = (callback) => { if (typeof callback !== "function") { throw new TypeError("Failed to execute 'queueMicrotask': the callback provided as parameter 1 is not a function"); } }; if (typeof Promise === "function" && typeof Promise.resolve === "function") { globalObj.queueMicrotask = (callback) => { checkIsCallable(callback); Promise.resolve() .then(() => callback()) // call with no arguments // if any error occurs during callback execution, // throw it back to globalObj (using setTimeout to get out of Promise chain) .catch((err) => setTimeout(() => {throw err;})); }; } else if (typeof MutationObserver === "function") { globalObj.queueMicrotask = (callback) => { checkIsCallable(callback); const observer = new MutationObserver(function() { callback(); observer.disconnect(); }); const target = document.createElement('div'); observer.observe(target, {attributes: true}); target.setAttribute('data-foo', ''); }; } else if (typeof process === "object" && typeof process.nextTick === "function") { globalObj.queueMicrotask = (callback) => { checkIsCallable(callback); process.nextTick(callback); }; } else { globalObj.queueMicrotask = (callback) => { checkIsCallable(callback); setTimeout(callback, 0); } } } })(); queueMicrotask(() => console.log('microtask')); console.log('sync'); // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll // implemented in Chrome 85 // https://vanillajstoolkit.com/polyfills/stringreplaceall/ if (!String.prototype.replaceAll) { String.prototype.replaceAll = function(str, newStr) { // If a regex pattern if (Object.prototype.toString.call(str).toLowerCase() === '[object regexp]') { return this.replace(str, newStr); } // If a string return this.replace(new RegExp(str, 'g'), newStr); }; }; // https://developer.mozilla.org/en-US/docs/Web/API/ParentNode/replaceChildren // implemented in Chrome 86 // https://github.com/XboxYan/dom-polyfill // copied from github-wc-polyfill (function() { if (Element.prototype.replaceChildren === undefined) { Element.prototype.replaceChildren = function(...nodesOrDOMStrings) { while (this.lastChild) { this.removeChild(this.lastChild) } if (nodesOrDOMStrings.length) { this.append(...nodesOrDOMStrings) } } } }()); `; var script = document.createElement('script'); script.textContent = actualCode; (document.head||document.documentElement).appendChild(script); script.remove(); As you can see, it's a patchwork of code "borrowed" from you, various polyfill authors and portions from github-wc-polyfill extension, by JustOff; I couldn't be arsed to make a proper fork and publish on GH... FWIW, I use a different (smaller) version of that file for my 360EEv12 (Chromium-78-based) copy (only the polyfills for JS code implemented in Chromium > 78.0). But I fear I'm derailing this thread...

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...