axios/axios #5038 meanwhile in the land of moving sands...

Brave men test in production

Hipster kids don't even bother

Remember kids: if your webapp does not break in production at your next pageload, You Are Not Scale™

there much more complete

tomman: I have done the in-place code change and had it error out

i prefer test domains

tho there will always be that ONE tidbit i missed and will have to patch quickly

t-mobile.com/unsupported_firefox_incognito oh wow, if you're in USA and that's your telco, DROP IT ASAP

well, SteamDB went all in with Google WebComponents® and named capture groups

also an annoying and offensive "Update your browser" button to Browsehappy

czech?

speak czech?

Spanish here~

but this is an English-speaking channel by convention

ja: as far as I know, nobody speaks czech here, but it's always possible there *is* somebody

if possible try to say in english

:D vole nejsou jeste slabsi pecky ted sechodi fakt tezce spat

esperando :D

HAVE ANYWHERE IN CHAT WHO WORKING AT PROBLEM E MAIL DEFFENCE AGAINT SPANISH MONKEYS?

hey frg_Away so yeah as far as eventually syncing as many pseudo-isolated components and modules.. indeed I beleieve that if we do share swaths but NOT the exact same platform my stuff may poke the same code slightly differently revealing stuff that would potentally go unnoticed for years so I think it is of tramendous benefit to all conserned

i believe there can never be just one upstream ;)

I know the problem is system ip adres delete and contruct new system if this real ?

or we have choice only creating new game cat with rat?

I also want to try and finally after over 10 years to complete mailnews incomplete linkage aka xpcom component not libxul

if i get those into components then i COULD revive the xulrunner and xulapp package concept.. with an xpinstall inspired twist of course

that was the post-netscape mozilla dream after all

line 3 working for?

frg_Away: code.binaryoutcast.com/projects/aur…-central/src/TRUNK/components/weave

prep for when I offered to port over pure weave

IanN_Away: you may know the answer to this.. do js components take priority over cpp components if they are intersecting the same job.. like the about redirector.. if we have the regular about redirector and a js about redirector if the js one defines an about page already defined in the cpp one which gets priority.. i would think js componments always take priority between cpp and js xpcom because the contracts are registered well after it

already knows about the cpp component ones.. now i guess between multiples in the same type all cpp or all js it would depend on i guess the luck of the draw registration wise

as evidnced when my restructruing physically changed the order of compilation causing issues earlier this year

frg_Away: are your devtools still jetpack based?

NewTobinParadigm Still at work. Will play catch up soon

understood

sorry dude

np. Just wanted to let you know taht the conversation is not one sided :)

frg_Away: that alone levels you up several places this year above others

a lot of people even before the fall had just started ignoring others wholesale

where i can read and write .dll and . lib

ja: maybe you should ask questions with the proper context

that way others can know whatcha talkin about

i am sorry i must go sleeep new information dont have zitra and was big kokot :D

thx very much and the plane is learning and learning

NewTobinParadigm Never tried to register duplicate components. Lots if changes in this and the second registration might even fail. This is basically all gone in the central code with only doing static registrations but we don't plan to backport this code. But if it works then my bet would be on the last registration too. I just wouldn't bet much :)

I am not sure of the benefit to static registration or what static registration even means other than i guess because extensions are out of the picture they only ever need to load shit from gre or app never from profile so why scan everything for all the chrome.manifests

that and whatever they are using to encode it.. json or yaml or w/e is more broadly readable by current day tools than chrome.manifest or jar.mn entries

UNLESS you are talking about how for cpp xpcom components they are now codegenning most of the simpler factories

is that what you mean frg_Away

I mean I kinda like the idea of the whole codegen of repeditive simple shit but if i were to pull something like that I don't think I'd use Mozilla's codegen or i would heavily modify it to not be ridiculous

I didn't follow the latest mozilla code drama and dumbification here but yes I think this is it. Components need to be all knows at compile time. Someone more familiar with central code might correct me.

something I can invoke manually as well and use the codegen as a template generator to create a more complex component

i like the concept but i am almost sure i hate the impl

no surprise there then lol

Well after this sec release i will sit down and run some tests to find out the ACTUAL behavior of competeing components

cause that SHOULD be documented

For weave wonder if it is possible to build a second independent set of services api so that suite or any other single application the source tree can use this instead of the standard weave.

Is there anything sec releated to be backported? Latest bugs seem to be 99% sec "regressions" for later code. I have identified one so far which might apply.

the issue I ran into with gre restructring involved an embedding component which is supposed to be there for embedders but normal xulapps get a places interface.. when I moved shit around it changed the build order and thus the order the factories were compiled in and so suddenly shit was busted and i couldn't figure out why but i eventually found that component.. which btw didn't function and hasn't since nsGlobalHistory was killed a long long

time ago.. it is only happenstance that Mozilla devs never had an issue with the colliding interfaces

I dunno

if there are any likely canidates for fifty-two based platforms they will be showing up in the UXP and subsiquently my repo in the next few days

but i figured .. why release a sec update when there could be more sec updates in a few days

get em all

with just a mail client and low usership i can play more fast and loose with releases and even sec updates .. that won't be the case once Borealis is launched

then it is monthly release with the only out being no sec updates and no feature updates

again

wrt static registration Bug 1770237

more than likely my strat would be simpler factory codegen and move js component registration to the same file that but in the end it would be outputting the same chrome.manifest files and essentually the same xpcom bincomp factory

hey if i ever accomplish it you can take it ;)

manifests are gone and you have a components.conf. comm-central/142345e84687

i'd also likely match the manifest format mozilla choose but the impl would be to match what would be without

why .conf

So I don't think you could do anything in add-ons any longer with it.

see i would use such a file as a build file.. i don't want to replace chrome.manfiest with anything except json perhaps.. or just go back to contents.rdf

i am so tempted to re-rdf as much as i can just so i can say fuck you to everyone who ruined everything for the past decade lol

Well IanN and me are ripping it out mostly. So we are the enemy :)

Frankly this mostly ancient. It works but a lost art. Later stuff does not apply well here.

as for mailnews. Ours is at a mix of 56 to about 65 with some de-rdf work and bits taken here and there plus later stuff when we like it. We mostly picked the functional changes and not the ui ones. IanN and me are still keeping TB there building to do a-b tests. Still mork and the old address db format. I think we might switch over to maildir from mbox one day and even to the new address db...

...but the js protocoal implementations would need to mature a few release more. Say 20 to 50 :D

there is a recent thread in the news.eternal-september.org support group where it seems Tb might be not always authenticating

I wonder if that's the new js implementation?

(or has the same been observed with SM M&N?)

i would accept mailnews not using rdf if it meant we could share a common impl

probably but might happen with the old implementation too if "weird" server.

besides, i could always hack in my own whateverstorageformat to rdf datasource if i really needed to

or just ifdef it

llol

i mean i don't LIKE the idea of dropping the historical formats but i have to balance that shit with the reality

What I dislike about js here is that you add another layer of abstraction and loose any coding warning during complie time. For frontend go for it but for a critical backend lets just say I am not a happy camper.

news://news.eternal-september.org:119/m2lepbw2g5.fsf⊙rn hm, Ray says "known for years", so maybe it's not the new implementation

besides, a specific component even as big as mailnews not doing rdf is fine because it has no impact on some of the stuff i might do rdf with

frg_Away: I completely agree with you

i have the feeling if you stick to purely mozilla bits in xpcom components and support code.. i think it is learnable.. but the stuff rewritten after say 2014 that is harder to redo in pure xpcom

I think my approch will be that while js components are great for simple small things or as an interum solution (kinda like self hosted js) but a cpp impl should eventually replace it

on the other hand i think most components on the application side should be js registered

and implimented if possible

but that simply follows my agenda of wanting to ease the recreation of the xulrunner dream

Naturally all should be done in Rust so that I have an excuse to leave IT.

LOL

SAME

Rust: when oil is not enough™