Jump to content

mixit

Member
  • Posts

    161
  • Joined

  • Days Won

    9
  • Donations

    $0.00 

Everything posted by mixit

  1. 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.)
  2. (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...
  3. 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!
  4. 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".
  5. 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!
  6. 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.
  7. @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.
  8. @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. )
  9. @-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.
  10. 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.
  11. 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.)
  12. 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...
  13. 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.
  14. 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.
  15. Turns out you don't have to patch anything in the browser, just change the page styling:
  16. You guys give up too easily, is this the infamous XP lair of fanatics or not!? Fortunately there is (for time being, anyway) a pretty simple fix for this "video problem". (I use quotes because it has nothing to do with video as such.) You don't need to switch or recompile browsers either - at least not right now over this particular issue. Apparently ESR 52.9 handles CSS flex layout a bit differently, so with the current Instagram code the video and its surroundding elements kindly get the height of 0 pixels... This can be fixed by modifying a surrounding <div> container to use block display instead of flex. If you use uBlock Origin, you can add the following rule to your My filters: instagram.com##div.ZyFrc[role=dialog]:style(display: block !important) (Just make sure Filterlists > Parse and enforce cosmetic filters is checked and that Settings > Default behavior > Disable cosmetic filtering is not checked or is overridden per-site for instagram.com.) The same can presumably be done with other styling/tweaking extensions, only the syntax may be a little different. I don't use anything else, so can't give you the specifics. If you don't use any such extensions and don't want to install them, you can just add the following CSS snippet to your userContent.css file (it's located in the chrome subdirectory under your Firefox profile folder. Edit: as @Dave-H pointed out, the file may not exist yet, in which case just create a new text file, put this stuff in it, and rename the file to userContent.css.) @-moz-document domain(instagram.com) { div.ZyFrc[role="dialog"] { display: block !important; } } (In this case you'll have to restart the browser for this to take effect, only refreshing the page won't make a difference.) BTW, aside from div.ZyFrc[role="dialog"] , simply using div.ZyFrc or div[role="dialog"] also works. I'm just using the more specific condition to hopefully avoid accidentally breaking something else on Instagram (I'm not a frequent visitor there, so I wouldn't know). The mangled class name ZyFrc is pretty likely to change when they rebuild they code, and using the role-based version without a class name may survive that. Or it may not - as we know web devs need to constantly tweak their stuff, even when it's not broken... So this may need to be revisited. Edit: Forgot to give kudos to @Mathwiz for narrowing down the problem and linking to this change list with hints to flex layout being the problem. Edit 2: I tested this style fix on ESR 52.9.0, but I'd be surprised if 52.9.1 would be any different in this regard. ----------------------- In other news, if you're spoofing a more current version of Firefox on all sites with ESR 52.9, apparently you'll have to drop your spoofed version below 57 on instagram starting today, because they seem to have switched over to Quantum-specific code for newer versions and basically nothing works anymore. (If you're using the default 52.9 user agent, you shouldn't need to make any changes because of this - at least it seems to work for me.) It could mean, though, that they'll be dropping support for anything pre-Quantum sooner rather than later, which may also affect the various Pale Moon derivatives, depending on how up-to-date their CSS and JS support is.
  17. Unless people are seeing issues, in this case the delay-load linkage to brcypt.dll.as such shouldn't be a problem, even in the original Office 2007 Compatibility Pack SP3 (KB2526297) MSO.DLL (12.0.6607.1000) has it. I thought the same thing you did at first, but going back and checking earlier versions seems reassuring.
  18. https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1148337 Just look in the Brazilian folder instead of Portuguese. (Incidentally, this post was the very next one after the one you quoted )
  19. You shouldn't need to restart the stream, just hitting the left arrow key and then the right arrow key should do it - this jumps you 5 seconds back and then 5 seconds forward to where you were before (in case some other page element has focus, you may need to click on the video first). It's still an annoyance, but much less disruptive this way. I pretty much do it on autopilot at this point, after years of practice courtesy of Mozilla. This works at most other video sites as well. since most players bind these keys similarly.
  20. @Dave-H I'm still getting the 2017 version here. MS caches seem to be a crapshoot in terms of getting the latest certificate updates (for example I'm also still not getting the latest update @heinoganda notified us about). Not the first time this has happened, either. I wouldn't even be surprised if the version you downloaded manually just now was different than the one WU gets when it tries. I don't know about "exactly", but functionally, yes, for our purposes they should be the same. The automatic updater wouldn't know about your manual updates as the mechanism it uses is different (.sst vs .stl), and thus also its versioning. I don't think there's any checking being done against individual certificates being present or not.
  21. I guess I'm not sure why you think you still need this active if you're doing your updates separately anyway? You're already "working around" this functionality as is. I think it was you who pointed out earlier in the thread that the current authroot.stl dates from 2017/9/22. Viewing its signature shows that the Microsoft Certificate Trust List Publisher certificate it's signed by was valid from 2017/1/25 to 2018/4/13. I'd venture a guess that this is when your errors started (can't tell by this thread as MSFN forum issues seem to have wiped out some of the posts). Until Microsoft updates this list, I believe you're always going to have the problem with the Event 11 certificate validity errors against your system clock:
  22. @Dave-H Since you seem to be getting Event 11 errors for crypt32, maybe you have the automatic Update Root Certificates component still active in your XP installation? It would seem quite odd for you to be getting lots of errors about not being able to extract certificates from a WU cab unless something was trying to update them. Given that you're updating manually (or via @heinoganda 's tool) anyway, you should probably turn it off even if that won't resolve the errors issue. In Control Panel, run Add or Remove Programs. Click Add/Remove Windows Components in the left-hand column. Scroll all the way down to Update Root Certificates, clear the check box, click Next, and then complete the Windows Components Wizard. Pardon me if this is old news to you. I tried checking back in this thread to see if this component was mentioned in connection with your problem and didn't find anything.
  23. In theory, yes - although you could potentially end up missing fixes for permissions not related to the file system (the registry, services, whatever else - can't say I'm an expert). @Destro will tell you in no uncertain terms that you're not affected if you have an FSB processor (those ex-KGB guys know how to protect their stuff; j/k, it means "front-side bus") - and indeed, Intel hasn't confirmed these CPUs are affected; then again, some proof-of-concept tests floating around appear to work on C2D (assuming the tests are implemented correctly). So, confusion continues... That microcode list, though, doesn't mean C2D is getting any updates at this point - it's cumulative and includes historical updates as well.
  24. Well, It's certainly possible that the big guns don't always cover everything, I just figure they'd generally get more input because of how many users they have. I think you'd get the same result if you added the Mining Blocker rules to ABP. It's slow enough as is even without using another blocker on top of it (had to move to uBO myself for better speed, even though I prefer ABP's interface).
  25. @wyxchari You are correct, domains and especially script file names can always be changed. And since Mining Blocker simply blocks the following sites: '*://coinhive.com/lib*','*://coin-hive.com/lib*','*://cnhv.co/lib*','*://coinhive.com/captcha*','*://coin-hive.com/captcha*','*://cnhv.co/captcha*','*://*/miner.pr0gramm.com/*','*://miner.pr0gramm.com/*','*://*/coin-have.com/*','*://coin-have.com/*','*://*/hashforcash.us/*','*://hashforcash.us/*','*://*/hashforcash.com/*','*://hashforcash.com/*','*://*/coinerra.com/*','*://coinerra.com/*','*://*/pr0gramm.com/*','*://pr0gramm.com/*','*://minecrunch.co/web/*','*://mine-crunch.co/web/*','*://jsecoin.com/server*','*://*.jsecoin.com/server*','*://*.35.190.24.124.com/server*','*://load.jsecoin.com/*','*://*.load.jsecoin.com/*','*://server.jsecoin.com/*','*://*.server.jsecoin.com/*','*://static.reasedoper.pw/*','*://mataharirama.xyz/*','*://listat.biz/*','*://crypto-loot.com/lib*','*://cryptoloot.com/lib*','*://gus.host/*','*://*/gus.host/*','*://xbasfbno.info/*','*://*/xbasfbno.info/*','*://azvjudwr.info/*','*://*/azvjudwr.info/*','*://jyhfuqoh.info/*','*://*/jyhfuqoh.info/*','*://jroqvbvw.info/*','*://*/jroqvbvw.info/*','*://projectpoi.com/*','*://*/projectpoi.com/*','*://kdowqlpt.info/*','*://*/kdowqlpt.info/*','*://ppoi.org/*','*://*/ppoi.org/*','*://inwemo.com/*','*://*/inwemo.com/*','*://lmodr.biz/*','*://mine-my-traffic.com/*','*://minemytraffic.com/*','*://coinblind.com/lib/*','*://coinnebula.com/lib/*','*://coinlab.biz/*','*://deepc.cc/*','*://*/coinlab.biz/*','*://gridcash.net/*','*://*/gridcash.net/*','*://socketminer.com/*','*://*/socketminer.com/*','*://ad-miner.com/*','*://*/ad-miner.com/*','*://cloudcoins.co/*','*://*/cloudcoins.co/*','*://webmine.cz/*','*://*/webmine.cz/*','*://hashunited.com/*','*://*/hashunited.com/*','*://mineralt.io/*','*://*/mineralt.io/*','*://authedmine.com/*','*://*/authedmine.com/*','*://easyhash.io/*','*://*/easyhash.io/*','*://webminepool.com/*','*://*/webminepool.com/*','*://monerise.com/*','*://*/monerise.com/*','*://coinpirate.cf/*','*://*/coinpirate.cf/*','*://crypto-webminer.com/*','*://*/crypto-webminer.com/*','*://webmine.pro/*','*://*/webmine.pro/*','*://*/monad.network/*','*://monerominer.rocks/scripts/*','*://cdn.cloudcoins.co/javascript/*','*://minero.pw/miner.min.js*' and any script URLs containing any of the following strings: 'CoinHive','Coin-Hive','jsecoin','mataharirama','minecrunch','coin-have','hashforcash','coinerra','reasedoper','minemytraffic','lmodr','cryptoloot','crypto-loot','listat','monero.worker','scrypt.worker','scrypt.asm','neoscrypt.asm','gus.host','xbasfbno','azvjudwr','jyhfuqoh','miner.pr0gramm','jroqvbvw','projectpoi','kdowqlpt','ppoi','minemytraffic','inwemo','minero','coinblind','coinnebula','coinlab','cloudcoins','deepc','monerominer','gridcash','monad','ad-miner','socketminer','cloudcoins','webmine','mineralt','authedmine','hashunited','webminepool','monerise','coinpirate','crypto-webminer','c-hive','cryptonight' and any scripts containing: 'miner','CoinHive','Coin-Hive','Coin-Have','hashforcash','coinerra','jsecoin','mataharirama','minecrunch','reasedoper','minemytraffic','cryptoloot','crypto-loot','inwemo','minero','CoinBlind','coinnebula','minemytraffic','cryptonight','coinlab','cloudcoins','monerominer','deepMiner','gridcash','monad','ad-miner','socketminer','cloudcoins','webmine','mineralt','authedmine','webminepool','monerise','coinpirate','crypto-webminer','c-hive','CRLT.Anonymous','hashunited' It would seem pretty easy to bypass it by renaming (also easy to get something useful blocked because of false positives). Since Mining Blocker has only 7,898 installs versus 13,424,117 for Adblock Plus and 5,111,703 for uBlock Origin, I'd rather rely on blocker extensions with massive user base, because their blocklists are likely to be up to date more quickly. Also, with Mining Blocker you currently have to update the extension itself just to get an updated blocklist. The only "feature" Mining Blocker has is that upon installation it attempts to stop any mining scripts already running - useful if for some reason you don't like to restart the browser. (I looked at Mining Blocker because I was curious what interesting tricks they might use to detect mining scripts, not to be contrary with you. Based on these results, I'm afraid most of the "specialized" anti-mining extensions would similarly turn out to be not terribly useful subsets of full-blown adblocker functionality.)


×
×
  • Create New...