XPerceniol Posted May 17, 2022 Share Posted May 17, 2022 Thus far .. no issues and the latest Serpent is working quite well, overall, considering. Hopefully will improve even more :) Link to comment Share on other sites More sharing options...
Elkern 4926 Posted May 17, 2022 Share Posted May 17, 2022 Athenian200 is doing an email app that will not be restricted by you know who. Will roy tam bring it to XP and vista? https://forum.palemoon.org/viewtopic.php?f=69&t=28280 Also, in the thread there is mention on o-auth codes and I am not sure I understand but was everyone just using thunderbird's before now? What impact does any of this have on roy tam's offerings? Link to comment Share on other sites More sharing options...
VistaLover Posted May 18, 2022 Share Posted May 18, 2022 (edited) 12 hours ago, XPerceniol said: Thus far .. no issues and the latest Serpent is working quite well, overall, considering ... I wish I could say the same here (Vista SP2 32-bit) , however I was bitten by a new regression that started with Serpent v52.9.0 (2022-05-06) (32-bit) ; if you're on WinXP, that one would not be of much impact to you (unless you're using Adobe Primetime CDM as a h264/aac decoder), but if you're using St52 on Vista SP2/Win7 SP1 (or higher...), do stay with me... (If you're not interested in the analysis below about EME/DRM and GMPs in Serpent 52, skip that and head to "The regression itself" section) First, a "record" of things, well, sort of... As you probably know already, upstream (MCP) harbour an ideological aversion for EME (Encrypted Media Extensions, used in the context of in-browser DRM), as such official Pale Moon never supported it! OTOH, when they created official Basilisk (among other things, to attract "legacy" FxESR52 refugees), they decided to let it stay there, in the state it was inherited from their "upstream", FxESR 52.6.0 . EME in the browser entails the installation of two third party DRM plugins, correctly called CDMs (Content Decryption Modules): 1. Adobe Primetime CDM 2. Google Widevine CDM The first was quickly obsoleted in favour of Google's one, in fact WV is the sole in-browser CDM used today in desktop browsers to decrypt DRM content... Unlike AP, which came with its own patented decoders, WV on a Firefox-type browser relies on OS decoders accessible via WMF (Windows Media Foundation), a Windows feature to be found in fully updated Vista SP2 and higher (i.e., not WinXP) ... Google issue frequent updates to their WV CDM, usually to combat discovered and exploited vulnerabilities, but also to remove support for OSes and devices they no longer consider kosher , in essence dictating the type of device and client (browser) you can view their DRM'd streams... The WV CDM is heavily intertwined into the browser's EME implementation, a said Fx version (especially the non-Quantum ones) can only accommodate a specific WV version; FxESR 52 originally came with support for WV v1.4.8.903; when that one was deprecated, MCP tried and managed to equip Basilisk with support for later WV versions, but their effort was forced to stop on (what would turn out to be) final support for WV v1.4.9.1088 ; UXP proved practically "incompatible" with later WV versions (4.9.*, 4.10.*); that very same support has been ported to Serpent 52.9.0 and was present until v52.9.0 (2022-04-29) . WV v1.4.9.1088 was deprecated on Aug 14th 2019, since then St52 can't decrypt DRM content when used in Vista SP2/Win7 SP1 ; FWIW, the latest WV version is v4.10.2449.0, the CDM's dll requires Win7 SP1 or higher, Chrome 69 or higher, FxESR 91 or higher... While St52's WV support is now "broken" for decrypting purposes, I still regard it as "working" for, at least, correctly identifying the browser is requested to play back a DRM'd stream; once so, I can then seek playback on another supported device in my household (Win7 and/or Win10 laptops); e.g. when loading the DRM test case by bitmovin in St52 (2022-04-29), I get this: i.e. the WV CDM is correctly picked up by the site, and the DRM indicator is displayed in the URL bar, to the left of the padlock; as said, content can't be decrypted, the old CDM has been deprecated and the WV lic servers have blacklisted it... Unable to progress further in this field, MCP let Basilisk's DRM support rot away, but the official stance from them is Google's refusal to grant "margin" browsers the rights to use their CDM (well, this is true, but you get my drift ) ... Thus, upstream no longer check/care for/cater to EME/DRM support in their UXP tree, more so after officially declaring Basilsk as EoL a few days ago... Another technology MCP feel opposed to is WebRTC (never supported by them in PM), but they also left it in in official Basilisk; in the context of WebRTC, Serpent 52 downloads and installs the "OpenH264 Video Codec provided by Cisco Systems, Inc" plugin, at version 1.7.1; as indicated by MCP, WebRTC support is also to vanish from within their UXP tree... The two EME CDMs and the Cisco plugin (not a CDM) are referred to collectively as GMPs (Gecko Media Plugins). Disclaimer: When I set out to write up posts like this one, I intend them to serve as sort of Knowledge Bases, "there" even for future reference (as long as MSFN is up) by any interested party, even outside of MSFN; I'm fully aware though, that the length of such posts of mine doesn't bode well with the attention lifespan of many co-members/forum readers, I apologise to them, but they are always free to skip content... The regression itself Starting with Serpent 52.9.0 (2022-05-06), support for ALL GMPs has been completely BROKEN - this includes both the two CDMs (Adobe Primetime, Google Widevine) and the Cisco Video Codec ; I was still on a (2022-04-29) profile myself, when I decided to jump directly on to latest St52 build, (2022-05-12); I did not become aware of the breakage right away, but only when I tried loading a certain DRM stream (the one I troubleshot in my recent MSFN post here) and witnessed the browser acting "odd": the DRM indicator never came up in the URL bar, while it did so in FxESR 52.9.1... Additional troubleshooting revealed in fact that the DRM "breakage" started with the previous St52 release, (2022-05-06) ... STR (OS to be used is Vista SP2 - fully updated to EoS - and higher, XP is NOT suitable!) 1. Launch a new fresh profile of St52 (2022-04-29) (32-bit), package name is "basilisk52-g4.8.win32-git-20220430-3219d2d-uxp-cf4e046f9-xpmod.7z" 2. Load "about:preferences#content"; you should see the "DRM content" section; tick the "Play DRM content" box: 3. Give it 2-5min (YMMV), then load "about:addons => plugins"; you should see entries there for ALL 3 GMPs; NB: The AP CDM won't be auto-installed "shortly", actually, as the old (internal) download link is no more valid; there's a way to manually install if you have an archived copy of the CDM, but the process is beyond the scope of this bug report... 4. Exit the browser 5. Update the browser to Serpent 52.9.0 (2022-05-06) (32-bit), package name is "basilisk52-g4.8.win32-git-20220507-3219d2d-uxp-e207b5a16-xpmod.7z" 6. Launch the browser, it will use by default the previously created profile (by v2022-04-29) 7. Navigate to "about:addons => plugins"; you'll witness that ALL previous entries of the 3 GMPs have vanished: 8. In a quasi-similar test, delete the existing St52 test profile (with browser closed) and relaunch Serpent 52.9.0 (2022-05-06) (32-bit); a new fresh profile will be created. 9. In that fresh profile, repeat step [2]; when, afterwards, you repeat step [3], no sign of the 3 GMPs inside the plugin manager... 10. The next (latest) St52 release, Serpent 52.9.0 (2022-05-12) (32-bit), package name basilisk52-g4.8.win32-git-20220514-3219d2d-uxp-774750839-xpmod.7z, exhibits the exact same behaviour, i.e. no GMPs are either picked up from an existing profile nor installed in a fresh one: Regression range between 2022-04-29 (last GOOD) and 2022-05-06 (first BAD): https://github.com/roytam1/UXP/compare/cf4e046...e207b5a (I do see a reference to "gmp" here , but that commit made it to the (2022-05-12) build, also broken... ) Dear @roytam1, no doubt this is all caused by an "upstream" cock-up , do you think you can restore GMP (and, specifically, WV) support back into Serpent 52? Partial/"broken" as it might be in the (2022-04-29) build, I do have use for it... Currently back to the St52 (2022-04-29) release, which, sadly, misses the (?.) upstream implementation... Many thanks in advance ... Edited May 18, 2022 by VistaLover 4 Link to comment Share on other sites More sharing options...
roytam1 Posted May 18, 2022 Author Share Posted May 18, 2022 12 hours ago, VistaLover said: ... I wish I could say the same here (Vista SP2 32-bit) , however I was bitten by a new regression that started with Serpent v52.9.0 (2022-05-06) (32-bit) ; if you're on WinXP, that one would not be of much impact to you (unless you're using Adobe Primetime CDM as a h264/aac decoder), but if you're using St52 on Vista SP2/Win7 SP1 (or higher...), do stay with me... (If you're not interested in the analysis below about EME/DRM and GMPs in Serpent 52, skip that and head to "The regression itself" section) First, a "record" of things, well, sort of... As you probably know already, upstream (MCP) harbour an ideological aversion for EME (Encrypted Media Extensions, used in the context of in-browser DRM), as such official Pale Moon never supported it! OTOH, when they created official Basilisk (among other things, to attract "legacy" FxESR52 refugees), they decided to let it stay there, in the state it was inherited from their "upstream", FxESR 52.6.0 . EME in the browser entails the installation of two third party DRM plugins, correctly called CDMs (Content Decryption Modules): 1. Adobe Primetime CDM 2. Google Widevine CDM The first was quickly obsoleted in favour of Google's one, in fact WV is the sole in-browser CDM used today in desktop browsers to decrypt DRM content... Unlike AP, which came with its own patented decoders, WV on a Firefox-type browser relies on OS decoders accessible via WMF (Windows Media Foundation), a Windows feature to be found in fully updated Vista SP2 and higher (i.e., not WinXP) ... Google issue frequent updates to their WV CDM, usually to combat discovered and exploited vulnerabilities, but also to remove support for OSes and devices they no longer consider kosher , in essence dictating the type of device and client (browser) you can view their DRM'd streams... The WV CDM is heavily intertwined into the browser's EME implementation, a said Fx version (especially the non-Quantum ones) can only accommodate a specific WV version; FxESR 52 originally came with support for WV v1.4.8.903; when that one was deprecated, MCP tried and managed to equip Basilisk with support for later WV versions, but their effort was forced to stop on (what would turn out to be) final support for WV v1.4.9.1088 ; UXP proved practically "incompatible" with later WV versions (4.9.*, 4.10.*); that very same support has been ported to Serpent 52.9.0 and was present until v52.9.0 (2022-04-29) . WV v1.4.9.1088 was deprecated on Aug 14th 2019, since then St52 can't decrypt DRM content when used in Vista SP2/Win7 SP1 ; FWIW, the latest WV version is v4.10.2449.0, the CDM's dll requires Win7 SP1 or higher, Chrome 69 or higher, FxESR 91 or higher... While St52's WV support is now "broken" for decrypting purposes, I still regard it as "working" for, at least, correctly identifying the browser is requested to play back a DRM'd stream; once so, I can then seek playback on another supported device in my household (Win7 and/or Win10 laptops); e.g. when loading the DRM test case by bitmovin in St52 (2022-04-29), I get this: i.e. the WV CDM is correctly picked up by the site, and the DRM indicator is displayed in the URL bar, to the left of the padlock; as said, content can't be decrypted, the old CDM has been deprecated and the WV lic servers have blacklisted it... Unable to progress further in this field, MCP let Basilisk's DRM support rot away, but the official stance from them is Google's refusal to grant "margin" browsers the rights to use their CDM (well, this is true, but you get my drift ) ... Thus, upstream no longer check/care for/cater to EME/DRM support in their UXP tree, more so after officially declaring Basilsk as EoL a few days ago... Another technology MCP feel opposed to is WebRTC (never supported by them in PM), but they also left it in in official Basilisk; in the context of WebRTC, Serpent 52 downloads and installs the "OpenH264 Video Codec provided by Cisco Systems, Inc" plugin, at version 1.7.1; as indicated by MCP, WebRTC support is also to vanish from within their UXP tree... The two EME CDMs and the Cisco plugin (not a CDM) are referred to collectively as GMPs (Gecko Media Plugins). Disclaimer: When I set out to write up posts like this one, I intend them to serve as sort of Knowledge Bases, "there" even for future reference (as long as MSFN is up) by any interested party, even outside of MSFN; I'm fully aware though, that the length of such posts of mine doesn't bode well with the attention lifespan of many co-members/forum readers, I apologise to them, but they are always free to skip content... The regression itself Starting with Serpent 52.9.0 (2022-05-06), support for ALL GMPs has been completely BROKEN - this includes both the two CDMs (Adobe Primetime, Google Widevine) and the Cisco Video Codec ; I was still on a (2022-04-29) profile myself, when I decided to jump directly on to latest St52 build, (2022-05-12); I did not become aware of the breakage right away, but only when I tried loading a certain DRM stream (the one I troubleshot in my recent MSFN post here) and witnessed the browser acting "odd": the DRM indicator never came up in the URL bar, while it did so in FxESR 52.9.1... Additional troubleshooting revealed in fact that the DRM "breakage" started with the previous St52 release, (2022-05-06) ... STR (OS to be used is Vista SP2 - fully updated to EoS - and higher, XP is NOT suitable!) 1. Launch a new fresh profile of St52 (2022-04-29) (32-bit), package name is "basilisk52-g4.8.win32-git-20220430-3219d2d-uxp-cf4e046f9-xpmod.7z" 2. Load "about:preferences#content"; you should see the "DRM content" section; tick the "Play DRM content" box: 3. Give it 2-5min (YMMV), then load "about:addons => plugins"; you should see entries there for ALL 3 GMPs; NB: The AP CDM won't be auto-installed "shortly", actually, as the old (internal) download link is no more valid; there's a way to manually install if you have an archived copy of the CDM, but the process is beyond the scope of this bug report... 4. Exit the browser 5. Update the browser to Serpent 52.9.0 (2022-05-06) (32-bit), package name is "basilisk52-g4.8.win32-git-20220507-3219d2d-uxp-e207b5a16-xpmod.7z" 6. Launch the browser, it will use by default the previously created profile (by v2022-04-29) 7. Navigate to "about:addons => plugins"; you'll witness that ALL previous entries of the 3 GMPs have vanished: 8. In a quasi-similar test, delete the existing St52 test profile (with browser closed) and relaunch Serpent 52.9.0 (2022-05-06) (32-bit); a new fresh profile will be created. 9. In that fresh profile, repeat step [2]; when, afterwards, you repeat step [3], no sign of the 3 GMPs inside the plugin manager... 10. The next (latest) St52 release, Serpent 52.9.0 (2022-05-12) (32-bit), package name basilisk52-g4.8.win32-git-20220514-3219d2d-uxp-774750839-xpmod.7z, exhibits the exact same behaviour, i.e. no GMPs are either picked up from an existing profile nor installed in a fresh one: Regression range between 2022-04-29 (last GOOD) and 2022-05-06 (first BAD): https://github.com/roytam1/UXP/compare/cf4e046...e207b5a (I do see a reference to "gmp" here , but that commit made it to the (2022-05-12) build, also broken... ) Dear @roytam1, no doubt this is all caused by an "upstream" cock-up , do you think you can restore GMP (and, specifically, WV) support back into Serpent 52? Partial/"broken" as it might be in the (2022-04-29) build, I do have use for it... Currently back to the St52 (2022-04-29) release, which, sadly, misses the (?.) upstream implementation... Many thanks in advance ... should be fixed by commit https://github.com/roytam1/UXP/commit/ed4e67920f81c1578a875925efb20188a2281a33 2 Link to comment Share on other sites More sharing options...
VistaLover Posted May 18, 2022 Share Posted May 18, 2022 8 hours ago, roytam1 said: should be fixed by commit https://github.com/roytam1/UXP/commit/ed4e67920f81c1578a875925efb20188a2281a33 Many thanks, indeed... ; that commit's title is: "GMP: revert GMPUtils.jsm back to state of rev 4a010b9"; looking more closely at the "History" of changes of involved source file GMPUtils.jsm, https://github.com/roytam1/UXP/commits/ed4e67920f81c1578a875925efb20188a2281a33/toolkit/mozapps/extensions/GMPUtils.jsm I can see that the recent breakage was due to "Issue #1829 - Revert "Issue #1751"", a huge squashed-commit by Mac dev @dbsoft (who was again invited back into the team of upstream devs, after M.A.T's exit...), that made it to Serpent 52.9.0 (2022-05-06) release; FWIW, I don't get why "we" are also reinstating Mac compatibility/build-ability in "our" (i.e roytam1's) UXP tree, but this is obviously NOT my call... I can also see that the last working ("good") iteration of file GMPUtils.jsm was/is https://github.com/roytam1/UXP/commit/d4582b821c97d11f016d7ab8dcc3a380dcabc6fa from back in May 7th 2021, commit d4582b8, but the "new fix" references commit 4a010b9 (Mar 19th 2021) that didn't modify that file ; perhaps I'm missing something here... In any case, I'll be sure to test coming Saturday's Serpent 52 new release, to verify all aspects of the regression I reported are mitigated... Many thanks again for your attention to users' reports, always keep a watchful eye on code imported from upstream ... Best regards and wishes! 1 Link to comment Share on other sites More sharing options...
VistaLover Posted May 19, 2022 Share Posted May 19, 2022 (edited) @roytam1 : Success indeed! : File "./basilisk/omni.ja" was de-optimised and unpacked (with 7-zip) to omni dir; compiled file "./omni/jsloader/resource/gre/modules/GMPUtils.jsm" was DELETED; source file "./omni/modules/GMPUtils.jsm" was edited according to the "fix"; contents of omni dir were compressed back to an omni.ja (zip) archive; modified omni.ja file was optimised and put in the place of the original (that came with the 2022-05-12 release). Edited May 19, 2022 by VistaLover 1 Link to comment Share on other sites More sharing options...
Mathwiz Posted May 19, 2022 Share Posted May 19, 2022 On 5/14/2022 at 10:31 PM, NotHereToPlayGames said: Did you alter any of the home PC fonts? ie, experiment with "emoji's" ? Well, no; at least, not that I know of. I'd know if I did that, right? Link to comment Share on other sites More sharing options...
NotHereToPlayGames Posted May 19, 2022 Share Posted May 19, 2022 You'd have to do it manually, so you'd know. Link to comment Share on other sites More sharing options...
Mathwiz Posted May 19, 2022 Share Posted May 19, 2022 (edited) OK, have not done that. From your query, I take it the button icons are actually a customized character font, much the same as many Web sites (including MSFN) use to add small icons to their sites. Let me fire up the 32-bit version of St 55, which still shows the bug on my home PC, and see if a similar bug affects the icons at the top of the MSFN page. Hmm.... MSFN's icons appear normal, even though St 55's icons are fouled up: Still, I think you're onto something. Just can't quite figure it out yet. Edited May 19, 2022 by Mathwiz 1 Link to comment Share on other sites More sharing options...
Mathwiz Posted May 19, 2022 Share Posted May 19, 2022 On 5/17/2022 at 2:40 PM, Elkern 4926 said: Athenian200 is doing an email app that will not be restricted by you know who. Will @roytam1 bring it to XP and Vista? I'm sure he'll consider it; in the meantime, have you tried IceDove? 2 Link to comment Share on other sites More sharing options...
dmiranda Posted May 19, 2022 Share Posted May 19, 2022 Hi there, Does anyone have whatsappweb working in SP52? It used to work with UA Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 but not anymore. 68, 91 also do not work. In vanilla profile, it stops as in the attached image: organizing messages. Link to comment Share on other sites More sharing options...
DanR20 Posted May 20, 2022 Share Posted May 20, 2022 @roytam1 Using today's UXP 52 and the performance seems to have greatly improved, even after long periods of usage. Don't know if this is coming from Moonchild's side or yours but thought I'd let you know. 1 Link to comment Share on other sites More sharing options...
XPerceniol Posted May 20, 2022 Share Posted May 20, 2022 On 5/19/2022 at 2:04 PM, dmiranda said: Hi there, Does anyone have whatsappweb working in SP52? It used to work with UA Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 but not anymore. 68, 91 also do not work. In vanilla profile, it stops as in the attached image: organizing messages. on my serpent I use: Mozilla/5.0 (Windows NT 10.0; Win32; x86; rv:78.0) Gecko/20100101 Firefox/78.0 Have you tried that one? Link to comment Share on other sites More sharing options...
dmiranda Posted May 20, 2022 Share Posted May 20, 2022 1 hour ago, XPerceniol said: Mozilla/5.0 (Windows NT 10.0; Win32; x86; rv:78.0) Gecko/20100101 Firefox/78.0 Same result. Still stuck at organizing files. Link to comment Share on other sites More sharing options...
XPerceniol Posted May 20, 2022 Share Posted May 20, 2022 2 hours ago, dmiranda said: Same result. Still stuck at organizing files. I'm sorry to hear that, I hope somebody will have a solution for you. Link to comment Share on other sites More sharing options...
Recommended Posts