00:16:10 <njsg> nsITobin: pirate bay has retractable batons? I know they've had europarl candidates, but batons?
00:17:07 <njsg> 0307|23:03:30 <+tomman> Turnstile can be used as a standalone captcha-esque tool too <-- turnstile *is* a CAPTCHA tool, I guess what has been happening is that cloudflare has added it to their browser check, but the thing is indeed a CAPTCHA of the inlining kind
00:17:40 <njsg> 0307|23:04:33 <+tomman> maybe I should just ditch everything and become a cat herder [...] <-- I'm not going to demove such noble endeavours, regards to your feline-overlords-to-be!
00:17:57 <njsg> that said, it'd be much better if we could get Cloudflare to fix their crap.
00:18:17 <nsITobin> prove I'm human? fuck sakes, I am still trying to prove I am not Dalek.
00:18:38 <njsg> tomman: if this is easy for you to test: does the Turnstile behaviour change in any way if you use a UA override?
00:19:27 <njsg> 0307|23:06:37 <+nsITobin> could be as simple as detecting access to the console api somehow <-- could it be a DoS or temporary hang caused by downloading an excessively large source file?
00:19:43 <njsg> and to be clear, this is SeaMonkey hang or something else?
00:19:46 <nsITobin> parsing gobs of minified js
00:19:50 <nsITobin> absolutely could be a dos
00:20:02 <nsITobin> just enough that works but too much for devtools reflection or debugging
00:21:21 <nsITobin> i would assume its seamonkey else he'd indicate otherwise
00:21:47 <nsITobin> I wonder if Pale Moon hangs when you open its devtools on a turnstile
00:22:37 <tomman> njsg: not really, Turnstile is more like a facade
00:22:44 <tomman> for a very elaborate browser fingerprinting tool
00:22:53 <tomman> disguised as a simple captcha
00:23:40 <tomman> now, why it brings the entire browser down / hung into endless recursion when poked? That's what we have to lookup
00:23:54 <tomman> we must assume that every script served by Clownflare now is straight malware
00:37:03 <nsITobin> so the web is 80% malware
00:37:07 <nsITobin> sounds about right
00:38:03 <nsITobin> but yeah even if it wasn't a primary goal once it was found out.. they kept double and triple and quadrupling down until this seige
00:38:25 <nsITobin> how many times now has CF caused crashes and dos-style hangs
00:38:30 <nsITobin> now
00:38:39 <njsg> sounds about right, isn't it what they say, you'll only use 20% of it 80% of the time and the other 80%...
00:38:42 <njsg> :-P
00:39:04 <nsITobin> works 60% of the time, every time
00:39:09 <nsITobin> njsg:
00:39:48 <nsITobin> njsg: time to fork the web
00:39:59 <nsITobin> sorry for the double highlight.. habit
00:42:22 <njsg> you could have said you were just forking your IRC message! :-P
04:46:00 <Guest2896> Good morning/afternoon/evening to everyone! Is there any extensions or a native way to mute a tab? Right clicking a tab like in every other browser doesn't show any "mute" feature for me.
14:00:13 <nsITobin> Guest2896, should you be checking the channel logs, Per-tab muting as been possible in the mozilla backend for a while now. However, adding the plumbing into SeaMonkey's tabbrowser binding will be custom work because of the differences between SeaMonkey's binding and Firefox's since Firefox 4. However, custom to SM the impl may be it should be absolutely doable. It is a bit low priority vs webcompat things but I will make a point to poke it this year
14:00:14 <nsITobin> sometime if not sooner. Even Pale Moon has the functionality.
14:04:38 <nsITobin> how I would do it if not matching Firefox's and Pale Moon's vanishing UI stuff is add a context menu item and use the favicon to act as an UNMUTE button but not have a mute button on the tab.. Either that or the whole thing be under a pref.. the last thing I and I suspect some seamonkey users don't want is to go to click on a tab or middle click close it and it hit the mute button instead
14:08:10 <nsITobin> ... knew I should have added it to borealis.. then I could simply port it over.. laziness years ago bites me in the ass today..
14:08:38 <nsITobin> so .. later this year.
14:08:51 <nsITobin> TODAY however. Good morning actually here peoples!
14:09:53 <frg_Away> nsITobin hi added the patches in review to the central repo
14:10:54 <nsITobin> oh good that saves me some time.. i mangled the queue locally for my own mental processes but needed to put it back.. luckily none of the changes should have impacted much touched by the queue
14:12:03 <nsITobin> also I think i left a paerent line in part 1 of the 3 part bug.. do i need to fix that or is it.. ok-ish :P
14:12:09 <nsITobin> parent*
14:14:38 <frg_Away> For checkins I usually check the subject again.
17:07:02 <frg_Away> gitlab central updated
17:26:32 <nsITobin> entropy no longer required in nss?
17:26:40 <nsITobin> nor the source override?
17:29:14 <nsITobin> frg_Away: do you happen to know off hand if the current cc patches are in landing order or just fixed order?
17:29:46 <nsITobin> landing order as in order they would be landed in if sm was following cc normally
17:31:38 <nsITobin> according to their progression*
17:36:58 <frg_Away> nsITobin don't think so. Was for Bill to add additional build source options and entropy for avoiding later symbols. I think the nss patch was not needed in central. Not sure if it even does something in 2.53.
17:38:30 <frg_Away> Just some fixed order. Only the first 4 now are in a possible landing order. Might move my 9999 to position 4 then.
17:42:49 <frg_Away> The top patches would probably land in this order.
17:45:29 <nsITobin> my about redirector patch needs some love and a fresh lookover make sure I did it right the first time
17:46:53 <frg_Away> And on  a totally unrelated note I am now amd gfx free thanks to a cheap used RTX 2080 Super.
17:47:09 <nsITobin> congrats
17:47:43 <nsITobin> tho is the older amd hardware also giving you issues or is it just the drivers keep getting worse and worse that once working hardware is not so great regardless?
17:48:09 <nsITobin> cause that unified driver is a total bitch
17:49:07 <nsITobin> frg_Away: I can tell you re the entry patch it didn't seem to be deteramental for what little i was able to get operational last year
17:49:31 <frg_Away> RX 580 was fine but blocking of the drivers on Windows server was the last straw after already doing it on 8.1
17:50:02 <frg_Away> ^straw
17:51:37 <frg_Away> The 20xx card have support for 7 to 2025 and are now supported by the open source Linux drivers. How open source is still quesntionable but they work.
17:53:25 <frg_Away> nsITobin just did a c-c build with the current queue. Succeeded.
18:03:11 <nsITobin> yay
18:08:42 <nsITobin> frg_Away: here is a command you can run successfully if you are in for the thrill.. ./mach run -chrome about:buildconfig -devtools
18:21:04 <nsITobin> let's see what is new in the pull
18:24:37 <nsITobin> cd /c/seamonkey/src && hg qpop --all && hg pull && hg update && cd comm && hg qpop --all && hg pull && hg update && cd ../../queue & git reset --hard && git clean -fd && git pull && cd ../src
18:25:41 <nsITobin> sorry.. my mouse needed to be 10 pixels to the right so the vm captures input...
18:43:06 <nsITobin> the top wip patch for 1783623 is missing registration for feedsniffer and thunderbird migrator and directory provider for which nsSuiteModule was also responsible for registring.
18:44:23 <nsITobin> feedsniffer is likely irrelevant because feeds are gone except as provided by mailnews core.. thunderbird migrator is hopelessly out of date and can be ignored for .. potentally ever.. but the dir provider is kinda needed so gonna fix that next.
18:46:08 <nsITobin> on central
18:47:00 <frg_Away> nsITobin yeah the work in progress is just minimum for get it buiulding or as a starting point.
21:02:38 <nsITobin> I am doing a test right now to add xul as just another xhtml extension in exthandler so the bulk rename patch isn't always required of course that won't cover automatic resolution for anything assuming default filename as the chrome provider will still default to whatever they have it set to so chrome://navigator/content/ would resolve to chrome://navigator/content/navigator.xhtml but chrome://navigator/content/navigator.xul would work along current
21:02:38 <nsITobin> xhtml codepaths explicitly.. Seems to be a oneliner as well.
21:03:58 <nsITobin> nor calls for not-suite xul files thos will still need changed
21:09:33 <nsITobin> on second well seventh thought this has limited usefulness.. scrapping
21:34:54 <nsITobin> yeah hooking directory provider back up and then follow bugs on thunderfox.. this is familar
22:11:00 <nsITobin> oh this is just unfair.. any change to a static regsitration virtually rebuilds anything xpcom
22:11:07 <nsITobin> so basically most of the codebase
22:11:12 <nsITobin> ... every.. time
22:13:48 <nsITobin> feels like.. manipulation.. we need to get rid of these xpcom components cause it takes too long to build.. and knowing it was any different was forbidden at least it was last year
22:56:52 <frg_Away> gitlab 2.53 updated
22:57:01 <nsITobin> anything fun?
22:57:49 <frg_Away> nsITobin 2.53 can now be compiled with the 2019 toolset in VS2022. Will change this back when we fnd the time to actually fix the VS2022 toolset.
22:58:15 <frg_Away> will update wip next but not today. sleep first.
22:58:28 <nsITobin> rest well
22:58:36 <nsITobin> when you do
22:58:40 <frg_Away> nn
23:19:58 <nsITobin> should have asked frg if that would impact my use of 2019 buildtools from 2019
23:20:01 <nsITobin> damn
23:20:02 <nsITobin> oh well
23:25:20 <nsITobin> with tests takes 43 minutes to regenerate central on xref
23:25:50 <nsITobin> makes sense.. newer perl newer centos than 7 and also newer server infra vs 2016..
23:26:05 <nsITobin> so hour down to 43 minutes with tests
23:26:43 <nsITobin> so.. mister IanN_Away, tests can stay indexed on xref