Jump to content

My Browser Builds (Part 2)


Recommended Posts

1 hour ago, VistaLover said:

So, pray tell, which was "every other version of firefox" ?

 

Ok should have specified every other version of firefox from 60+, since those are versions I'm on in Win 7 when not UXP.

The function isn't used much in Win 7 by me since beginning in that OS the mouse API lacking in XP lets you scroll left or right solely with the middle mouse wheel by tilting it left or right. Much more convenient.

In XP "mousewheel.with_*.action" - 4 is the best alternative available. I am aware it was added in Pale Moon and then removed for some reason and is probably reflected in moebius.  

Link to comment
Share on other sites


I might be the only one, but I tried Disney Plus today on Pale Moon 27 and Basilisk 52 running on Windows Vista (with the enabled VP9, DLL's) and it doesn't work. After clicking on Play, I get Error 83. Someone who maybe knows how to solve it, if it can be solved?

Edited by Stefan43
Link to comment
Share on other sites

52 minutes ago, Stefan43 said:

but I tried Disney Plus today on Pale Moon 27 and Basilisk 52 running on Windows Vista

If they're using DRM (with no Silverlight NPAPI fallback), then

1. Any version of Pale Moon (official 27.9.4 runs on Vista, official 28.x.x doesn't) or New Moon don't have any support for EME, DRM and the WidevineCDM needed to decrypt the DRM'ed streams.
2. If you're actually using the Serpent 52.9.0 fork, able to run on Vista, then I have seriously bad news to tell you: while St52 does support EME/DRM, the version of WidevineCDM it is compatible with is 1.4.9.1088; that version was revoked by Widevine licence servers (owned by Google) on Aug 13th, 2019.

There is a task underway by a Moonchild Productions developer to port support to latest official Basilisk for currently supported WidevineCDM v4.10.1440.19; this task is currently stalling due to real life issues affecting that developer; even if/when that attempt reaches fruition, it is a moot point for the Serpent fork on Vista; new WidevineCDM dlls contain functions (actually, only one: TryAcquireSRWLockExclusive, Win7+) not compatible with Vista's kernel32.dll system file; as WidevineCDM is proprietary closed source code and Google don't support the CDM on Vista, there's practically 0 chance DRM services requiring WV will ever work again on Vista :realmad:

If Disney+ use DRM with WV, then, if you can, try Firefox Quantum 60.9.0/68.2.0 (with WV v4.10.1440.19) on a supported OS (Win7+); or the latest Chrome there; as I can't try D+ myself, I speculate your predicament is DRM related; if they don't employ DRM - highly unlikely - then some other member here (in the US, CA or NL) might throw some light...

PS: If you don't grasp some terminology in this post, Google is your friend (actually, in the above WV context, your foe... :angry: ).

Regards

Edited by VistaLover
Link to comment
Share on other sites

10 hours ago, Stefan43 said:

I might be the only one, but I tried Disney Plus today on Pale Moon 27 and Basilisk 52 running on Windows Vista (with the enabled VP9, DLL's) and it doesn't work. After clicking on Play, I get Error 83. Someone who maybe knows how to solve it, if it can be solved?

LAV Filters installed? Directx 9.29 redist? All Visual C ++? Enable MP4 (H.264 + AAC) HTML5?

Server Disney + now works correctly in mypal, newmoon, basilisk.

Link to comment
Share on other sites

4 hours ago, kitaro1 said:

Server Disney + now works correctly in mypal, newmoon, basilisk.

... I was under the impression Disney+ launched initially only in the US, Canada and The Netherlands...

https://www.cnet.com/news/disney-plus-streaming-service-launch-dares-prices-shows-movies-marvel-star-wars-pixar/

Quote

When's the release date? 

Disney Plus launched Tuesday (Nov 12th 2019) in the US, Canada and the Netherlands. The initial launch of Disney Plus comes less than two weeks after Apple TV Plus rolled out. 

After the American, Canadian and Dutch launch, Disney Plus will arrive a week later, on Nov. 19, in Australia and New Zealand. 

On March 31, it will launch across Western Europe, including the UK, France, Germany, Italy, Spain and a number of other countries in the region.

In advance of the official launch, Disney has been offering Disney Plus free in the Netherlands for anyone to try. It'll switch to requiring a subscription on Tuesday.

Aren't you currently in Poland? :whistle:

Edited by VistaLover
Link to comment
Share on other sites

On 11/12/2019 at 9:07 AM, VistaLover said:

CTR is still available outside of the CAA extension (which is where you obviously obtained that direct link from ;) ) in the author's GitHub repository:

https://github.com/Aris-t2/ClassicThemeRestorer/releases

If you're using the official Basilisk application on Win7+, then the latest CTR_v1.7.8.2019.10.27 is recommended; if, OTOH, you're using Serpent 52.9.0/55.0.0, then CTR_v1.7.8 is the last (EoS'ed) version for Serpent; the add-ons manager (AOM) is now different between Bk and St (Bk now uses PM's AOM with no support for WEs, while St retains FxESR52's AOM), Aris is currently maintaining CTR for official Bk (and classic Waterfox), only... :(

Mozilla's decision to remove support for all pre-WE APIs, of course, broke CTR for FF 57+. Then their decision to remove all pre-WE add-ons from AMO meant that only "legacy" / classic add-on repositories would have a link to CTR. I checked legacycollector and addons.basilisk-browser.org first with no luck, then found it in the CAA database and thought my search was done, unaware that development is continuing for Basilisk / Waterfox at GitHub.

So now, I've updated Serpent 55 to v1.7.8, and Serpent 52 (which should be on par with "official" Basilisk) to v1.7.8.2019.10.7! I'll update my old FF 52.9 (and XomPie-patched FF 53) next. CTR has so many options, though, I can't readily tell what was added between 1.7.7.2 and 1.7.8 et seq.

One weird thing I did discover, though was that v1.7.8.2019.01.21 removed the option to display the version number in the Add-On Manager screen :huh: so by updating Serpent 52 to the "latest" version, I lost that bit of info.

The author explained, "Basilisk 2019 and Waterfox don't need this option, because version number is active by default." If so, that would be a question for @roytam1: What is the difference between Serpent 52 and "official" Basilisk that accounts for this slight UI change? Inquiring minds want to know....

Maybe I'll roll it back to 1.7.8 so I can tick that option back on; I like having my add-on version numbers visible at a glance.

Serpent 55 still searches AMO for updates. Serpent 52 searches, um - what should we call it? ABBO, I guess. But I haven't found ABBO particularly useful (as mentioned it doesn't even include CTR), so I switched the prefs in about:config back to AMO (you have to change %APP% to firefox). That way, at least my WE add-ons stay updated. Surprisingly, quite a few are still compatible with FF 52/53 and Serpent 52/55.

Edited by Mathwiz
Link to comment
Share on other sites

2 hours ago, Mathwiz said:

One weird thing I did discover, though was that v1.7.8.2019.01.21 removed the option to display the version number in the Add-On Manager screen :huh: so by updating Serpent 52 to the "latest" version, I lost that bit of info. Maybe I'll roll it back to 1.7.8 so I can tick that option back on; I like having my add-on version numbers visible at a glance

... You are developing a habit lately of not closely reading my posts (just kidding, of course! :D) :

On 11/12/2019 at 5:07 PM, VistaLover said:

If you're using the official Basilisk application on Win7+, then the latest CTR_v1.7.8.2019.10.27 is recommended; if, OTOH, you're using Serpent 52.9.0/55.0.0, then CTR_v1.7.8 is the last (EoS'ed) version for Serpent; the add-ons manager (AOM) is now different between Bk and St (Bk now uses PM's AOM with no support for WEs, while St retains FxESR52's AOM),

So, for both Serpent 52/55, CTR_v1.7.8 IT IS; CTR_v1.7.8.2019.10.27 applies to official Basilisk (on Win7+) and Classic Waterfox... ;)

2 hours ago, Mathwiz said:

I can't readily tell what was added between 1.7.7.2 and 1.7.8 et seq.

Should be possible to read posted fixes/changes in

https://github.com/Aris-t2/ClassicThemeRestorer/releases

after Classic Theme Restorer 1.7.7.2 and including Classic Theme Restorer 1.7.8 :)

Edited by VistaLover
Link to comment
Share on other sites

2 hours ago, Mathwiz said:

The author explained, "Basilisk 2019 and Waterfox don't need this option, because version number is active by default." If so, that would be a question for @roytam1: What is the difference between Serpent 52 and "official" Basilisk that accounts for this slight UI change? Inquiring minds want to know....

... But don't actually pay attention to what other people made the effort to post :(
... I did mention the reason in the part you chose to ignore:

On 11/12/2019 at 5:07 PM, VistaLover said:

the add-ons manager (AOM) is now different between Bk and St (Bk now uses PM's AOM with no support for WEs, while St retains FxESR52's AOM),

When MCP chose to remove WEs support from UXP and official Basilisk, it was a perfect chance for them to switch Basilisk's AOM (WebExAM) to the one present in Pale Moon (TychoAM) - PM's AOM dates from a pre-Australis era, has no support whatsoever for WEs and, as stated by Aris, displays addon version number by default.

But it was decided (by popular demand here) to keep WEs support in Serpent 52.9.0, that meant staying with the original AOM shipped with UXP, pretty much the same as the one in FxESR 52, which supports WEs but doesn't display addon version number by default (an additional legacy extension is needed for that, e.g. CTR).

In CTRv1.7.8.2019.xx.xx, Aris removed the .css code that enables the WebExAM to display addon version number (by selecting that option in CTR), since it's now a native feature of the TychoAM present in official Basilisk.

Please read for more info:

https://github.com/MoonchildProductions/UXP/commit/2cbbc5d
https://github.com/Aris-t2/ClassicThemeRestorer/issues/402
https://github.com/Aris-t2/ClassicThemeRestorer/issues/408

Regards

Addendum: Mozilla had intentionally removed the default display of AVN (addon version number) in the Australis[later WebExAM] AOM back in Firefox v40, when Bugzilla bug1161183 landed:

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

This was again an unnecessary move, a type of "chop head to get rid of headache" approach, since the bug originally wasn't about AVN per se...

https://bugzilla.mozilla.org/show_bug.cgi?id=1161183#c10

Quote

can we just completely drop the version number from the list view? I don't think it's of much use there. For those few users who need it, it would remain in the details view.

Remember, that was back in 2015 and already Mozilla devs had an opinion on what is of use in the browser GUI to most users, the rest were deemed to be few... :realmad:

I guess @roytam1 would have to revert that bug in both Serpent 52+55 (which use WebExAM) for CTRv1.7.8.2019 to be used as wished by @Mathwiz; but I don't think it's needed (now me sounding like a Mozilla dev...): if one is adamant on installing CTRv1.7.8.2019 in Serpent (which, I emphasise, is maintained with only official Basilisk in mind!), may co-install the following legacy extension:

Version Number in Add-ons Manager 1.10 (by magicp), recoverable via CAA (caa:addon/addonvernumber)

(Hope this time post is NOT ignored... ;) )

Edited by VistaLover
Link to comment
Share on other sites

1 hour ago, VistaLover said:

When MCP chose to remove WEs support from UXP and official Basilisk, it was a perfect chance for them to switch Basilisk's AOM (WebExAM) to the one present in Pale Moon (TychoAM) - PM's AOM dates from a pre-Australis era, has no support whatsoever for WEs and, as stated by Aris, displays addon version number by default.

But it was decided (by popular demand here) to keep WEs support in Serpent 52.9.0, that meant staying with the original AOM shipped with UXP, pretty much the same as the one in FxESR 52, which supports WEs but doesn't display addon version number by default (an additional legacy extension is needed for that, e.g. CTR).

In CTRv1.7.8.2019.xx.xx, Aris removed the .css code that enables the WebExAM to display addon version number (by selecting that option in CTR), since it's now a native feature of the TychoAM present in official Basilisk.

Detailed explanations are always my preference; thanks!

Of course I also understand why you might not have wanted to go into such detail the first time around. (It's too bad MSFN doesn't support a "spoiler" tag - that would have been a perfect use for it.)

(Note: henceforth I will use "AM" as my abbreviation for "Add-on Manager," so I can reserve "AOM" for "Alliance for Open Media" and its AV codec.)

So from the above, one can infer that NM 27, NM 28, as well as "official" PM and Basilisk, none of which support WebEx add-ons, all use the Tycho AM, which displays add-on version numbers without the assistance of an add-on like CTR.

OTOH, any browser supporting WebEx add-ons (Serpent 52/55, Firefox 52/53) by necessity must use the WebEx AM, which does not display add-on version numbers unless "coerced" to do so via an add-on such as CTR.

However, that little wrinkle aside, nothing seems to stop anyone from running the newer CTR versions on Serpent 52. At present I'm not aware of any "killer" features that would make this worth doing, but at least we can experiment!

Waterfox (Win 7 and 64-bit CPU required) would seem to be the oddball here, as it does support WebEx add-ons (as well as classic ones), so one would think it too would use the WebEx AM, and therefore wouldn't display add-on version numbers without CTR's "help." I must therefore conclude that the Waterfox folks developed their own fix for this issue. (Since it appears to be merely a .css issue, I suspect it was a rather simple fix.)

Link to comment
Share on other sites

53 minutes ago, Mathwiz said:

(It's too bad MSFN doesn't support a "spoiler" tag - that would have been a perfect use for it.)

It's undocumented, but you can try this:

 

]spoiler[

]/spoiler[

and invert the parentheses.

Edited by win32
Link to comment
Share on other sites

On 11/13/2019 at 5:11 PM, Mathwiz said:

Waterfox (Win 7 and 64-bit CPU required) would seem to be the oddball here, as it does support WebEx add-ons (as well as classic ones), so one would think it too would use the WebEx AM, and therefore wouldn't display add-on version numbers without CTR's "help." I must therefore conclude that the Waterfox folks developed their own fix for this issue. (Since it appears to be merely a .css issue, I suspect it was a rather simple fix.)

Of course, I can't deploy Waterfox in my Vista SP2 x86 laptop, but a targeted GitHub search reveals plenty :P :

https://github.com/MrAlex94/Waterfox/pull/566

 

On 11/13/2019 at 6:03 PM, win32 said:

It's undocumented, but you can try this:

Thanks, but it's useless when it goes live (i.e. in your original post, I can only switch between "Hide contents" & "Reveal hidden contents" state, while the actual "content" is void); you need to document (pun intended!) this function by stating plainly the code to be used inside MSFN's post editor... ;)

EDIT: So it should look like this

[spoiler]
contents
[/spoiler]

which, when submitted, turns into 

 

contents

Thanks :thumbup

Edited by VistaLover
Link to comment
Share on other sites

On 11/13/2019 at 11:13 PM, win32 said:

since you can't add code when editing a post

Sure you can:

BxXqHaf.jpg

Do you, by any chance, have the sidebar displayed? (Because for me, when the sidebar is ON and the tab content width shrinks, the "</>" button disappears from the MSFN post editor's header... :()

Edited by VistaLover
Link to comment
Share on other sites

21 hours ago, VistaLover said:

If they're using DRM (with no Silverlight NPAPI fallback), then

1. Any version of Pale Moon (official 27.9.4 runs on Vista, official 28.x.x doesn't) or New Moon don't have any support for EME, DRM and the WidevineCDM needed to decrypt the DRM'ed streams.
2. If you're actually using the Serpent 52.9.0 fork, able to run on Vista, then I have seriously bad news to tell you: while St52 does support EME/DRM, the version of WidevineCDM it is compatible with is 1.4.9.1088; that version was revoked by Widevine licence servers (owned by Google) on Aug 13th, 2019.

There is a task underway by a Moonchild Productions developer to port support to latest official Basilisk for currently supported WidevineCDM v4.10.1440.19; this task is currently stalling due to real life issues affecting that developer; even if/when that attempt reaches fruition, it is a moot point for the Serpent fo

rk on Vista; new WidevineCDM dlls contain functions (actually, only one: TryAcquireSRWLockExclusive, Win7+) not compatible with Vista's kernel32.dll system file; as WidevineCDM is proprietary closed source code and Google don't support the CDM on Vista, there's practically 0 chance DRM services requiring WV will ever work again on Vista :realmad:

If Disney+ use DRM with WV, then, if you can, try Firefox Quantum 60.9.0/68.2.0 (with WV v4.10.1440.19) on a supported OS (Win7+); or the latest Chrome there; as I can't try D+ myself, I speculate your predicament is DRM related; if they don't employ DRM - highly unlikely - then some other member here (in the US, CA or NL) might throw some light...

PS: If you don't grasp some terminology in this post, Google is your friend (actually, in the above WV context, your foe... :angry: ).

Regards

Thanks for the reply. I will try on Windows 7, as I just could not get it working on Vista with any of the browsers found in this topic. 

11 hours ago, kitaro1 said:

LAV Filters installed? Directx 9.29 redist? All Visual C ++? Enable MP4 (H.264 + AAC) HTML5?

Server Disney + now works correctly in mypal, newmoon, basilisk.

Thank you, I did all of this and could not get it working.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

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