mixit

Yes, absolutely! I should have emphasized this in my post as well. Don't let them intimidate you into leaving, @feodor2!

Tobin must think himself very clever to have found a supposedly actionable fault in you not specifying to his satisfaction the exact steps to get the source code (which is in fact available, let's not forget that). Well, since apparently he's now wanting you to remove all his contributions from your code, you could play his game and ask him to provide an exact list of his personal contributions so that you could remove them. If he can't be expected to determine which Github code corresponds to which release version, then surely you can't be expected to hunt down his contributions either. In fact it may not even be possible for you to do so, because the fact that Tobin has commited certain code doesn't necessarily mean that he's the author of that code (as opposed to just copying something over from Mozilla, for example); and some of the code he's authored has very likely been commited by other people, like Moonchild. So, let him provide the list and prove his original authorship if that's the path he wants to take. IANAL (I am not a lawyer), of course, and I don't think his claims have merit, but why not have him(/them all) work for it instead of just trying to intimidate people. In any case it's very unfortunate that Pale Moon people choose to spend their energy on hounding people for pointless reasons instead of improving the (sadly) increasingly obsolete browser. Mypal and Centaury pose no threat to their IP, they're just hounding you to earn some sort of a "victory" and feel better about themselves in the face of losing the game in the big picture. (As a sidenote, I feel I should give some small credit to athenian200 for at least not behaving like a petulant child - which can't be said about the other two, especially Tobin. ) All that said, and regardless of this MCP attack, @feodor2, it actually wouldn't hurt you to properly tag your Centaury releases (in the Mypal repo) and provide a source archive for each release. It is indeed pretty inconvenient to have to go by just the commit dates. You absolutely don't deserve their attack, but in a way you gave them the means to try it by being a bit lazy.

I could have sworn I saw something on Bugzilla around the time I was still "in charge" of the Primetime thread, but I couldn't find it now. IIRC the description was pretty vague, so it's possible I mistook the bug for something it wasn't, and that vagueness would also make it difficult to find it again. It's true though, people were complaining on forums, but not where it would have counted the most... Were you looking for a Bugzilla entry to mention the fix there?

Microsoft's CVE 2020-0601 description says it has to do with ECC certificate spoofing (as do many other articles, some specifically stating that RSA is not affected). Since XP (even with POSReady patches) has never supported any ECC on the OS level (crypt32.dll), how exactly would it be spoofed on XP? I'm not sure how SSL Labs is testing this, but something seems amiss here. Assuming the test works correctly, my logic says it'd have to be a browser problem.

Excellent, thanks for taking care of this! Re: his acceptance comment, the bug is actually in wdmaud.drv; wdmaud.sys you could say is ahead of its time, therefore getting nerfed by the 32-bit API limitation. But let's not nitpick, I probably should have made that more clear in my source comments. Since we're not concerned with Windows 7 (WinMM is never used there by UXP browsers), I didn't delve into it too much, but WinMM did appear to be substantially rewritten there. IIRC at some point official Firefox added an option to pick an audio subsystem, so at least in theory WinMM could be selected even with Win7 (however unlikely that is). I'm pretty sure that in that case my fix would simply be superfluous and not cause any problems, but I think it's really up to them to make sure of that as library providers.

Good to hear, although I can't give any guarantees re: Win2K, not having investigated it at all.

You can try the "traditional" one :

Fingers crossed. Honestly, unless they're hell-bent on flushing all memory of XP, I can't think of a good reason for why they wouldn't accept this fix. Let's hope Tobin won't have a heart attack if his so-called "MSFN hackers" manage to get official recognition. (Less name-calling, cussing, and paranoid lashing out at people who have been helping their project, and maybe they wouldn't need appeals like UXP development: it doesn't magically happen...) EDIT: If Tobin or someone else from PM reads this: sarcasm aside, I'm actually not saying this to fan the flames of conflict, the point is that it's painful to watch the upstream I believe most of us would ideally like to support and root for make that as hard as possible, and not just for MSFN members, but also a number of those in their own community.

Thanks, man! Ran a quick test on both with MP4, seems to "work for me". Hopefully the same will be the case for everyone!

Most of the complaints I've seen have been on their support site though, not at Bugzilla where the devs would see them first hand. And there never seemed to be that many people joining in and confirming the bug. The point @grey_rat kindly reminded us about would also definitely play a role in this. In any case, far be it from me to absolve Mozilla from its responsibility, I've mostly just been meaning to point out that there have been interfering factors along the way that don't (in this case) necessarily involve full-on Google agents within Mozilla's ranks. Thanks! After I found that it didn't matter if I used an online stream or a local file, I just downloaded a a random longish file VP8 WEBM video from search results, which happened to be this one. As you said, you won't be able to stream it because FF 15.0 can't handle the current HTTPS ciphers, but you can play it locally. (I've got to say, by the time I was finally done with the fix, I was totally haunted by the faces of those debate participants! ) Sure thing, go for it , but maybe wait until people have had a chance to play with your builds? I'd thought of this too, but I didn't want to bring it up before it's been confirmed that the fix works well for everyone. But there'd definitely be some nice irony in getting this XP-specific fix into the current Firefox code via their stand-alone cubeb lib, after they took great care to remove all traces of XP from their main tree! That's an excellent point! It's been a long time since I switched from Flash to the Primetime codec for H.264, so Mozilla's messing around with H.264 and especially its support on XP has faded from memory a bit. Yeah, those watching MP4/H.264 stuff using the Flash player wouldn't see this 2x:xx issue (I think - never tested for it specifically) and wouldn't have anything to report until maybe the last few XP-compatible Firefox versions, by which time Mozilla barely cared about XP any more. And VP8/9, which Firefox supported natively, were mostly available on Youtube, hence the strong association with the site for a long time.

I don't disagree, more important things to do can always be found, but in this case it wasn't really about polishing anything. If only their tests had included playing a 40-45 min video (the net length of a typical episode of a 1-hour TV show - a frequent use case), they'd have caught this problem immediately, as soon as they started using cubeb. The issue wasn't intermittent, it would happen whenever you watched a video straight through long enough. I can't believe a sane tester or developer would knowingly let an issue like this fester. Around the time of Firefox 15.0, XP was still big. But since they didn't catch this in their own tests, the whole thing became dependent on enough people noticing the exact pattern and reporting it. And people don't normally pay precise enough attention to this type of stuff. Speaking of myself: I'd like to think I'm pretty observant , but I didn't really notice this pattern even when I was already intellectually aware of it after having read about it - because I routinely skip over opening titles and often jump back or forward to rewatch some scene or skip a boring one, so even though I did see the freezes, they almost never happened at the same time mark for me. So, a great many people would miss the pattern because of this type of scattering, others simply wouldn't pay enough attention or would attribute it to something else, and only a select few would report it to Mozilla. And since many of them saw this happening on Youtube becuse that's where they watched most of their videos, it would become known as "an intermittent YT video issue" (a complete and utter misnomer, as we now know!), one of great many Firefox was having with the site. And since there weren't enough reports, no one really bothered to look into it properly. If they had, I'm sure their media guys like Pearce or Avenard would have pinpointed the problem location in a fraction of the time it took me. In retrospect, I regret that I never took the time back then to at least find out where the freeze problem started and give Mozilla a detailed report on it. But it was too minor an annoyance for me personally, and easy to work around; and at the time the buck stopped with Mozilla and you could always hope that maybe eventually they'd get this fixed. Nowadays, though, the buck basically stopped with me, so... As for WebGL, of course that sucks, but I think optimizing functionality is a very different kind of issue compared to fixing something that clearly shouldn't be happening at all. Hey, wait with the party until @roytam1 actually does a build with this! But I appreciate the kind words. Thanks , but to be honest it wasn't really that hard a problem to solve in terms of complexity. The main obstacle was that it was tediously time consuming and you always had to wait another half and hour before you knew what the next step would be. I actually took a break for a couple of months between when I found out cubeb was the problem and when I started looking into what exactly the problem was, because running these long test sessions on the background all the time was getting in the way of focusing on other things... As for the pref: yes, but only for a short while. I don't remember exactly when, but sydneyaudio was removed pretty soon afterwards. (And, technically, it still had this problem, but it'd only manifest after every 3 hrs or so, thus hardly anyone would notice.)

(Sorry, didn't have time to respond to this before.) I agree with your general point, but I'm not sure how much Google is to blame in this particular case. The thing is, programmers often tend to be pretty lazy when having to do maintenance tasks, because these aren't seen as "cool" and "innovative"... And this bug is a bit of a special case, because it takes almost 30 min to run a single test case, whether you're trying to track down where the regression originated, or trying to fix it. Let me give you a rough rundown of the process I went through with this (let's skip this long story for them normal people ; and this isn't about me looking for extra credit, honest! ) OK, so now consider that during virtually every step of this, you have to run a whole lot of 30 min (or longer) tests to make sure of your guesses or fixes. I am, of course, a great guy and all , but even with my highly vested hobbyist interest in solving this issue it took me several months to get through this all. Obviously not months of straight work on this alone, and obviously I didn't just sit around gaping at the screen every time I ran a test, but started the test and then did something else while it ran, but the whole thing still took time. Now, imagine I was an elite coder working at Mozilla , and generally supposed to work on some other stuff besides this. And, let's say you were my manager. Are you sure you'd let me spend all this time on this one, apparently (but really not) intermittent issue that seems to be affecting only a few people (really affecting all, but 99.99% of those people wouldn't put 2 and 2 together and notice the very specific interval and would instead write these freezes off as internet issues or whatever else) on a "legacy" OS that doesn't have that long to live anyway (or so you think, not knowing about POSReady, and MSFN )? And would I, an elite Mozilla engineer , want you to make me spend my precious time on something like this? I mean, even without the whole Windows driver dive and leak hunting thing they obviously wouldn't get into (the leak hadn't happened yet, either), it's a lot of work that isn't "cool", nor "innovative"! This is not to say that I excuse the fact that they don't even run tests for longer playback, etc., etc. We all know Mozilla has lots of problems with their attitude and policies, and there are many things they aren't doing that they should be doing (and vice versa). I definitely do blame them for letting this fall through the cracks and not doing more to fix this. But as far as Google goes, since they probably weren't using cubeb, maybe they themselves never ran into this bug (at least its more obvious, 2x:xx version), and since this isn't an issue specific to Youtube, I think I wouldn't blame them too much for this one. But there is Microsoft, who introduced this bug in the first place with that pretty dumb coding error...

Cool, thanks! And you even gave (ample!) proper credit and everything, quite unlike the "thieving hacker" image certain folks at MCP like to project of you, lol!

Let's see here... Looks like my latest Centaury build uses roughly 6.2 GB altogether, 1.4 GB for the source and 4.8 GB for the "object directory" with build results. This is a release build, debug would be somewhat larger - so let's say 7-8 GB in total. MozillaBuild is roughly 0.8 GB. The full DirectX SDK is 1.2 GB installed (although you really only need a few MB from it). For Windows 10 EWDK based builds (like @feodor2 does them) the EWDK .iso (that you can mount as-is) is 6-9 GB depending on version (getting bigger), but you don't have to install VS and the Windows SDK, so you can still save quite a bit that way. It was pretty funny to see Moonchild arrogantly lecture feodor2 that he didn't "understand how software in general works" because feodor2 didn't want to install all the extra bloat that comes with VS, whereas Mozilla have been using stripped down tools packages since well before Firefox 52.0 that UXP is based on (see the history of their toolchain packaging script). (OK, so they do the install once, but then package the components they actually need and use that package for subsequent builds.) If you did that (installed, repackaged, uninstalled) with the current official MCP requirements for Pale Moon/Basilisk, you'd end up with only 1.3 GB for all the required VS and SDK stuff, huge space savings! You're very welcome Since I don't plan on distributing my own builds publicly, I guess you'll have to wait until @roytam1 and/or @feodor2 merge this into their builds, so quite possibly only until this week-end for Serpent (although they'll likely want to spend a bit more time testing this on their own). You'd need to rebuild the whole application, replacing media/libcubeb/src/cubeb_winmm.c in the source code. Unfortunately this is not something that can be applied "on-the-fly".

I guess this is my cue to stop procrastinating and finally post the fix I made for this I've had a few people test it for 4 months now on all kinds of sites on both XP x86 and x64, and the jury says this indeed fixes the 2x:xx video stoppage issue and doesn't seem to introduce any new problems. I honestly didn't intend for the testing period to be quite this long, but summer heat can have a detrimental effect on one's brain and thus plans. Since my own browser builds are based on Centaury, but I still consider myself a (lurking) MSFN patriot and this is the home of @roytam1's Serpent, I'm just going to post the fixed media/libcubeb/src/cubeb_winmm.c on Pastebin to avoid playing favorites (and signing up on Github ) I'm not sure how often @feodor2 visits here these days, so maybe someone on Github could mention this in https://github.com/Feodor2/Mypal/issues/1 if he doesn't pick this up soon enough. What has been tested: MP4/VP9/VP8 (and plain audio MP3/etc) streaming/local chunked/single-file sped-up/slowed-down 27+ hrs long playback (see the technical details for why) Youtube/Twitter/Facebook/Instagram/TV station streams/etc/etc (nor did we forget p0rn/pirate sites, which of course are no different from a technical POV... ). Among other things, a 75-year old lady watched the entirety of Prince Philip's funeral with this fix in effect and had no complaints. What has NOT been tested: Pale Moon-based builds (as opposed to Basilisk), because I don't use NM or Mypal. Since this is a UXP platform level fix, the front-end should have no effect. I obviously don't have access to every sound card out there, but since the MS driver causing these problems should be common in all configurations, I'd expect the fix to work with pretty much every card. new-fangled formats like AV1 (I'd expect them work, though). DRM-ed streams, since no Widevine on XP (but again, this should work with those as well if DRM itself worked). @roytam1, @feodor2 I didn't create a preference for turning this fix off, because it turned out the normal pref system is no longer compatible with C code, and once it became evident enough that the fix was pretty solid, I didn't feel like hacking something together to make preffing work for a library-level change like this. You're welcome to pref it, of course, but based on the length of testing with no issues discovered, I dare claim it's safe to include without a pref. Here's a general overview of why this problem was happening (you may be surprised ): And, some more technical specifics, incl. about where the 2x:xx times come from (this is also included as a comment in the source code): EDIT: Writing this up amply reminded me how much I LOVE making long posts using this board's post editor... BBCode FTW!

Indeed, and only the ESR versions of FF 52 have out-of-the-box support for all other NPAPI plugins. @siria 's tweak from above is needed to enable them in the "regular" 52. As for @Sfor's original question about UA spoofing, I used Custom User Agent String for a while, but ultimately got fed up with its IMHO inconvenient and error-prone UI for managing the UA strings. Since then I've been using UAControl in conjunction with User-Agent JS Fixer. which also spoofs the UA JavaSript sees. UAControl, being a XUL extension, should work well with FF 51 as well, should you need to continue using that version.

@Mathwiz Saw your Github discussion from a while back because you credited me in an edit to an earlier post, thanks. Since I didn't notice you mentioning if you're already doing this or not, let me say just in case that you should probably use the same UA you have for github.com on githubassets.com and githubusercontent.com. The second one may be less important, but I experienced an issue not too long ago with spoofing FF 60.0 only on github.com and some UI script coming from githubassets.com not being in sync with that because of a different version in my non-site-specific UA.

@Aram & @Dave-H @-moz-document domain(instagram.com) { div._97aPb > div { display: block !important; } div.bsGjF > div { display: block !important; } div.bsGjF > div > div { display: block !important; } } seems to work with both single videos and carousels, or instagram.com##div._97aPb > div:style(display: block !important) instagram.com##div.bsGjF > div:style(display: block !important) instagram.com##div.bsGjF > div > div:style(display: block !important) added to uBlock's cosmetic filters. (And not to be a grouch, but when you want help with special cases, do provide an example or two, so others don't have to spend extra time trying to figure out and track down what exactly they're supposed to help out with. Not everyone is a heavy enough Instagram user to have these cases handy, for example I don't think I've ever seen a video carousel on the channels I visit more or less regularly. )

@-moz-document domain(instagram.com) { div._97aPb > div { display: block !important; } } is what it should be in userContent.css. I don't use userContent.css myself and I guess I figured people would just plug the (entire) changed part into userContent.css based on the previous example. Not that \i blame you, I've made plenty of similar mistakes copying code from one kind of syntax to another. (Edit: And even in my last 2 posts here, I've somehow managed to write !'d instead of I'd and \i instead of I That's actually kind of mysterious, though I guess an irregular sleep schedule can do that to you...) The full UA I'm using on Instagram is Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 but only the 56.0 part I gave above should matter.

Thanks! You totally imitated my style, too, so if !'d missed your note, I might have wondered a while about when on earth did I add that line . FWIW, there could be more stuff like that for branched browsers, my focus was always on mainline Firefox.

instagram.com##div._97aPb > div:style(display: block !important) seems to work for me on ESR 52 right now (in conjunction with having 56.0 in the UA). (I'm not crazy about using the non-specific child thing in there, but that other div has no class of its own, and _97aPb doesn't seem to be used elsewhere, so hopefully this won't break anything else.)

Based on my testing these fools are doing this solely based on the OS version part of the user agent string, e.g. "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0" works, but "Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0" doesn't. Good old FF ESR 52.0 seems to work fine otherwise (I don't have an account, so can't check for logged-in features). It never ceases to amaze me how lazy web developers can be with their a**-umptions, even though there are ways to check if the actually needed functionality is present or not. It's not as if a major site like NicoNico doesn't have the funds to pay their developers for this small bit of extra work...

I am indeed a genius, because I already had this solution two days ago, but thought there was something missing from it, because I could only get it to work when loading a video page URL directly, and not when clicking on a video on a user's list. You know, when it pops up with apparently the same URL, but it looks like the video is put into an overlay over the list page with an X in the corner. So I spent quite some time trying to debug this, and in the end it turned out that for some weird reason Instagram was using different URLs to fetch my test videos in these two cases. The direct-to-video URLs were getting theirs from fbcdn.net, but the "overlaid" versions were loading them from cdninstagram.com, which for some reason wasn't on my uMatrix whitelist for instagram.com and uMatrix was on. So, yeah, a real genius here. Turn off them content blockers when investigating browser issues, kids! Why, that sounds almost like the MSFN forum post editor has taken over your uBO installation! The very same version works fine for me. If it's just a matter of typing not working, you could put the line into a text file and "Import and append" it from there.

Apparently they've changed something, at least on the @qvcuk page you gave as an example, the latest video https://twitter.com/qvcuk/status/1108737574363754497 doesn't work. It's probably not really a video problem, but they've changed something in the surrounding JS/CSS. At least their earlier GIF https://twitter.com/qvcuk/status/1108698147474341890 and video https://twitter.com/qvcuk/status/1108654509352378369 work fine for me.

Turns out you don't have to patch anything in the browser, just change the page styling: