Leaderboard

Introducing JA4+ "Optimise Network Visibility with JA4+ Fingerprinting!" https://netquestcorp.com/ja4-tracing-the-progress/

Don't you get relaxed, JA4+ is in the development already! They will take that into the account, "JA4+: The Next Leap in Network Fingerprinting" https://www.peakhour.io/blog/overview-of-ja4-network-fingerprinting/

I never did that before. How do you go back to an earlier point in a project?

FYI, I have tested this, and it doesn't work for me in Mypal 68. Neither the implementation for loading of scripts nor the one for loading of specially adapted bootstrapped extensions from xiaoxiaoflood's project userChromeJS works in Mypal 68.14.4b. The whole project seems to be related to more recent versions of Firefox. Here is a quotation from the GitHub page: The specially adapted bootstrapped extension Download Manager (S3), for example, targets Firefox 125.0a1 and higher.

@feodor2 I noticed this issue when creating a custom button for calling up the cookie manager. For reproducing this issue, call up chrome://browser/content/preferences/siteDataSettings.xul, delete a site cookie of your choice, close it, open the site whose cookie you deleted and call up chrome://browser/content/preferences/siteDataSettings.xul again. You will then notice its cookie is not listed although it is there. And when now restarting the browser, the call up of this internal chrome site leads to an empty, broken and non-functional interface. Here is a screenshot of this issue including the TypeError message Uncaught TypeError: this._getQuotaUsagePromise is null SiteDataManager.jsm:255:5 getSites resource:///modules/SiteDataManager.jsm:255 init chrome://browser/content/preferences/siteDataSettings.js:127 onload chrome://browser/content/preferences/siteDataSettings.xul:1 in the Browser Console: Only by calling up the about:preferences page will it work again. BTW, when doing so in an UXP browser as, for example, New Moon 28 or Serpent 52 by calling up chrome://browser/content/preferences/cookies.xul, there is no such problem.

Your observation skills are simply remarkable! I got the same crap when I reply to someone else's status (but not posts). Upgrade the browser, and the issue (at least with postings) will be gone. In my case, the minimum chrome without this issue is chrome 108.

According to the recent studies, from "The Jewish News of Northern California". "ADHD diagnoses are more common in nations with high rates of immigrants, such as the United States, Canada and Australia." Jews: "highest rate of ADHD diagnoses, according to the recent survey." Source: https://jweekly.com/2018/04/16/israel-become-adhd-capital-world/ Also interesting: "How did Israel become the ADHD capital of the world?" Source: https://chadd.org/adhd-in-the-news/how-did-israel-become-the-adhd-capital-of-the-world/ Prevalence of ADHD among 7-9-Year-Old Jewish Children. "assessment of ADHD in the Jewish population emphasises" Israeli studies. Source, PDF format: https://cdn.doctorsonly.co.il/2016/12/02_Prevalence-of-ADHD.pdf

And thank you for bringing up the good memories of safe and divided World. Surely helps anyone with a healthy mentality to stay on the course.

A group of XP users ran out of shampoo, fortunately they had a museum with a fully functional guillotina there, also compatible with their heads.

I already wrote, you tend to put lots of different/unrelated stuff in one post, and it's going downhill, when you start with good, maybe even interesting stuff and then ... caboom ... insert your favourite part with the KGB lieutenant software, literally in each and every post. I mean, I kinda want to like you ... alas.... Nevertheless, I still upvote your post, since it's a big huge progress, and thank you for the compliments! And sorry, if I was too harsh on you at times.

Personally, I would tend to agree to this: Mypal 68 ≈ Firefox (≥ 68). In many ways, Mypal 68 behaves like a normal Firefox browser, but not in all. The JavaScript engine, for example, is comparable to that of higher versions. Mypal 68 is a Quantum browser, which has made it quite difficult to enable the use of UC.JS scripts, for example. The download package MYPAL_68_CB_requirements.7z from my first post is not available anywhere. It is very specific, and stops working in Firefox 72+ due to some code changes. I put together the configuration files myself to make it really work. In higher Firefox versions, the script functionality seems to be much easier to activate. BTW, one file of my package spits out an error in the Browser Console, which I fixed in the meanwhile.

$removeparam filters don't work in uBO Legacy...

Yes, that works on Firefox. But Mypal 68 != Firefox or is some conglomeration of old Firefox versions. Maybe older scripts work, maybe not.

The modern YouTube interface is simply crap. uBlock Origin is usually not the causer for any problems with YouTube , rather the opposite is the case. To watch videos on YouTube in old browsers (and despite all the improvements, Mypal 68 is still an old browser), one has to use extensions and/or userscripts to make them work. This and some already discussed measures are the reason why YouTube runs well again for me in Mypal 68.14.4b, even on my ancient computer from 2000.

Of course, it is not related to the rebase of DLL files. I didn't claim that either. It is an old, well-known problem that, however, can be curbed, but only in multiprocess mode. In single-process mode, considerably more memory is not released after tabs are closed, at least on my system. Anyway! There is more to be done to free up memory. One measure I already recommended is the periodical memory minimisation which should be done automatically.

The file nssdbm3.dll is missing in your sequence compared with the ones in the previous posts. On purpose or by chance? And why do you think the sequence of the DLL file series is of importance? BTW, I wrote: What are your observations when comparing single-process mode with multiprocess mode in terms of rebasing the DLL file series?

In the case of Mypal 68, however, the effect of rebasing its DLL files is only sustainable in multiprocess mode as the main problem with most browsers is, among other things, the release of memory when tabs are closed. The browser is not inherently prepared to release the amount of memory that a tab requires to load when this tab is closed again. In the course of a browser session, more and more RAM is therefore used that is not actually required but is no longer available to the system and can usually only be released if the browser is closed or restarted by the user. Unfortunately, the effect of rebasing fizzles out very quickly in single-process mode. And even in multiprocess mode, it is necessary to do more than just change the base address of its DLL files to fully enjoy the effect of rebasing in the entire browser session. Especially on systems equipped with a small amount of RAM where every single megabyte counts. In any case, I have managed to configure my installation of Mypal 68 so that the memory occupied by tabs is almost completely released when they are closed again. Of course, without restarting the browser and being a tab hoarder.

Start Mypal 68, open Process Hacker, right-click on the mypal.exe file and left-click on its Properties! Select then the Memory tab and check the base address range from 0x60000000 to 0x6f000000! If, for example, no other DLL file has the base address 0x60000000 and behind it is enough free address space for the DLL files to be rebased, then of course you can also start with the base address 0x60000000 for rebasing the DLL file series. For testing purpose only, I have rebased the DLL file series to the base address 0x60000000. As I already assumed, it works in the same way as with the other addresses. Here is a screenshot: I should still mention that I checked the base address range before rebasing. The range from 0x60000000 to 0x66700000 was not occupied by any other DLL file.

Counter question. Why does the libase tool automatically select the base address 0x6af00000 for xul.dll, which is exactly in the range from 0x60000000 to 0x6f000000? In any case, this recommendation did not originally come from me, but from an article I found after a research via Google. Here is the decisive section as a quote: This section can be found here: https://www.codeproject.com/Articles/35829/Modify-the-Base-Addresses-for-a-DLL-Files-Series And as you see, @UCyborg also seems to prefer addresses inside this range for his DLL file series: And I have also had good experiences with this base address range for DLL files. Cheers, AstroSkipper

That is what I like and agree, I prefer when I'm not overcrowded, and always choose my partners in everything, be it one-night-stands or friendship. Unfortunately, it was not always the case in my military days, until I got an officer rank, at least. So I kinda learned how to find something in common to talk about, until the mission is over, maybe try it? The most important part, don't waste your energy on them.

Well, I got more than six air conditioners (8), in each and every room and even in my kitchen! Does that count? As for the vehicles, now I got only one (barely use it), two if you count my ancient German BMW motorcycle, that I'm in the process of purchasing back from the dude I sold it to by mistake.

PR submitted! https://github.com/mozilla/cubeb/pull/656

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

the change is caused by https://github.com/roytam1/UXP/commit/9e19d368129f7405c09fdddc75c06e1ba46ed10c to add dark-theme support. if you don't like this change and want previous look, you may manually editing <root folder>\omni.ja\chrome\toolkit\content\global\logopage.xhtml and change back the values using left side of commit above for the time being. maybe I can do something more for this. EDIT: a fix has been committed to custom tree. will become available in next build: https://github.com/roytam1/UXP/commit/d6a5a51430ca21c72debe8d7818c6da72969f56f

New NewMoon 27 Build! 32bit https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210731-45b8007f3-xpmod.7z 32bit SSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210731-45b8007f3-xpmod-sse.7z 32bit noSSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210731-45b8007f3-xpmod-ia32.7z 64bit https://o.rthost.win/palemoon/palemoon-27.10.0.win64-git-20210731-45b8007f3-xpmod.7z source repo: https://github.com/roytam1/palemoon27 repo changes since my last build: - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1190636 - Replace AutoStringVector with Rooted usage; r=njn (5d287ee81) - Bug 1190911 - Replace AutoIdValueVector with normal Rooted usage; r=jonco (b6c8ce668) (9ff3d301a) - ported cubeb_winmm.c overflow fix by mixit@MSFN, Thanks! This should fix the famous 23m18s freeze bug for audio/video playback. (2d96070f5) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1191529 - Remove JSIdArray and AutoIdArray and replace with Rooted<IdVector>; r=mccr8, r=jonco (9c0d645aa) - Bug 1083752 - Calling Map/Set/WeakMap (without new) should throw. r=Waldo (bd0b31a3d) - Bug 1142279 - DataView should require 'new'. - r=efaust (97ef8ba02) - Bug 1155838 - Fix a build warning on windows; r=till (f9af00bff) - Bug 1129313 - Part 2: self-host MapIteratorObject#next(). r=jandem (b30734a0b) (11b532c45) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1150717 - Test request with no params in the Network Monitor. r=brings (a60e9e8d9) - Bug 1168077 - Remove remaining spidermonkey js specific syntax from browser/devtools; r=miker (c98f20c30) - Bug 1168125 - Fix existing tests, r=jsantell (b1dfa101e) - Bug 1169439 - Pull out marker definitions into its own file, and move formatter and collapse functions into marker-utils. r=vp (17eb24ab3) - Bug 1173654 - Part 1: Add logging methods for SurfaceType and ImageFormat. r=Bas (22f2fa019) - Bug 1169125 - Part 1: Allow sending any DataSourceSurface-backed image over WebRTC and fix failure cases. r=bwc (1fb0def92) - Bug 1169125 - Part 2: Use UniquePtr for scoped delete of yuv data in MediaPipeline. r=bwc (cdb79e201) - Bug 1173654 - Part 2: Use namespaces in MediaPipeline.cpp. r=bwc (311696260) - Bug 1173654 - Part 3: Attempt to GetDataSurface() and convert if sending pure I420 fails. r=bwc, r=jesup (58520b820) - Bug 1173654 - Part 4: Add detailed logging and asserts to MediaPipeline::ProcessVideoChunk. r=bwc (ba08ae5bc) - Bug 1155089 - Part 1: Reset |TrackID| for MediaPipelineTransmit::PipelineListener on replaceTrack(). r=bwc (304fb8703) - adapted Bug 1142688 - Wait for actual audio data on remote side before checking audio sanity. r=jesup,padenot (479f6356c) - Bug 858927 - Move the mozilla::TimeStamp into mozglue. r=glandium (751938e09) - Bug 1166559 - Add documentation for ProfileTimelineMarkers from a dev tools perspective. r=fitzgen (ed1563dfb) - Bug 1141614 - Part 4: Expose cycle collection markers in the devtools frontend; r=jsantell (2eb830de7) (45b8007f3)

... This is Windows XP SPx you're still talking about , official Mozilla Firefox builds NEVER supported natively the h264 proprietary decoder in HTML5 video; the decoder is patented and its native inclusion in a browser requires the browser authors pay a "handsome" fee to the patent owners (the MPEG4 consortium). Google are rich enough to afford that fee, so Google Chrome comes bundled with that decoder (AVC=h264) and hence it's capable of native h264 playback under Windows XP... When Adobe Flash Player was around, it itself came with bundled h264/aac decoders (again, because Adobe are rich), so MP4 video streams could be played, via that plugin, even in browsers (like Firefox) without that decoder built-in (and XP users, like yourself, were "happy"...). When many video sites abandoned Flash and instead started using HTML5 embedded web players, the lack of h264 decoder in Firefox rose to the surface, again for Windows XP users ONLY... Your favourite OS is deficient in this sector because the vendor, Microsoft, did not equip it originally with that patented decoder, nor a provision was made to add it in a later stage via an update... You see, Mozilla, instead of paying the h264 patent fee, decided to shift the "issue" to the OS itself, so that Firefox could make use of the h264 decoder already present in the OS (as Microsoft had already paid that fee themselves); unfortunately for you, h264 dec is only present in Vista SP2+Platform-Update-Supplement and higher - the way for Firefox to use it is through Microsoft's WMF (Windows Media Foundation) framework, so you can't bring h264 support to Firefox under XP via installing Codec Packs (these are used for DirectX media players, like WMP). The Adobe Primetime CDM (content decryption module) came with a bundled h264 decoder (patent fee paid by Adobe) and as a side-effect (its primary purpose was DRM) it can be used as an HTML5 h264 decoder in versions of Firefox that supported the CDM (off the top of my head, I think it was v47.0-51.0 officially, but v52.0 also works) - again, this is solely for XP... Regarding Roytam1 browsers: New Moon 27 doesn't support h264 natively (on any OS), but you can "install" such support by downloading an additional "package" (lav), extracting it and placing some DLLs adjacent to "palemoon.exe". The UXP-based browsers, like New Moon 28 and Serpent 52, come with a special "kludge", i.e. h264 decoding support is included in the ffvpx third party library (for XP's sake only, the UXP-based browsers can still use WMF's native decoder, if on Vista SP2 and up...). Lastly, HTML5 video decoding in a browser under XP is S/W only, so the video watching performance you get depends, among other things, on the video codec selected to begin with and your CPU; some codecs are taxing your CPU more heavily than others; the higher the resolution/bitrate/framerate, the more your CPU suffers; performance of the youtube webpage alone (which is a literal beast of JS and CSS code currently) depends on the browser engine, CPU, GPU, available bandwidth, CDN you are served from, content blockers, etc. so, while I find these "stats-for-nerds" logs to be of some substance, they have little statistical weight when compared between different setups... The Adobe Primetime CDM requires SP3 for Windows XP... His "log" mentions the av01 video codec, aka av1/AOM, do note AOM != AVC, official Firefox ESR 52 never supported that codec; the codec is, however, supported in UXP browsers via a pref: media.av1.enabled;true but decoding taxes heavily your CPU... PS: @UCyborg 's post appeared in the middle of writing this , he's right, of course, but my post expands on what he kindly posted...

AFAIK, Firefox itself only ever used Windows Media Foundation (Vista+) for AVC, which is not available on XP, hence you need a plugin on that OS, but otherwise, Firefox 52.9 can do AVC without a plugin.

(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!

LGTM will commit it in short period. EDIT: committed in goanna3 and 4 repo, other repos will be followed later. https://github.com/roytam1/UXP/commit/85149582f1000cd801350ebaa73151872c521d4f https://github.com/roytam1/palemoon27/commit/2d96070f5334a82b3cb3133c822b8ae5a372c411 https://github.com/roytam1/mozilla45esr/commit/bf2771bde24a18e3ab13ead251befca1ac630d7b https://github.com/roytam1/basilisk55/commit/6fd60b08fe3f33fc0c7245427a25251dd6008690 https://github.com/roytam1/palemoon26/commit/a66d2e44121f0684044f86abed116dc1d686d17f

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

Hello , I've finished testing this one from your link , well ... no luck . First off , I had your old files from the video , with them nothing happens , just silence. Then a kind soul provided me with the newest ones and this chromium 72 started to show only one error "This application failed to initialize properly (0xc000007b).Click OK to terminate." I have bare SP2 , but I installed some updates , just in case . Platform update , DX11 , Framework 4.5.2 , the same error happens.

Hello all , I have a question regarding Nvidia drivers . To be brief : I have GTX780 which has 100% support in Vista, however I can't get DTS HD MA passthrough to my receiver , the reciever also supports DTS HD MA . No matter what I do (tried all drivers, etc) , only ordinary DTS and DD5.1 are available through Vista. If I install W7 (not changing any hardware) - the problem is gone ! Of course I'm not going to use W7 , obvioulsy . I've tried to install Vista SP2 on my friend's similar hardware - the result is the same. If it's not enough info , I will gladly explain in details. Perhaps someone had already been that road . Thank you .