15:59:59 <morganava> #startmeeting Applications Team Meeting 2025-03-31 15:59:59 <MeetBot> Meeting started Mon Mar 31 15:59:59 2025 UTC. The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:59 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:10 <morganava> damn too early 16:00:19 <morganava> hello everyone, it's that time of the week once more 16:00:27 <morganava> the pad as usual -> https://pad.riseup.net/p/tor-tbb-keep 16:01:00 <dan_b> o/ 16:01:01 <morganava> last week we had a surprise windows-only chemspill release for Tor and Mullvad browsers 16:01:19 <morganava> which is always fun 16:01:57 <morganava> thx to pierov+ma1 for the assist on getting that out and boklm for following up some issues with our generated download.json 16:02:24 <boklm> (and update-responses xml files) 16:02:40 <morganava> this was the first time in a long time we'd tried a single OS/arch release that wasn't Android so we found a couple of gotchas 16:03:39 <morganava> also if you haven't already, please have a look at the pad that bella shared last week about potential future meeting topics/activities 16:04:00 <brizental[mds]> o/ 16:04:18 <morganava> hi o/ 16:04:43 <Jeremy_Rand_Lab19[mds]> morganava: IIRC I was away last week because NLnet whisked me away to a meeting at that time, which pad is this? 16:05:01 <morganava> jeremy: an internal one, no worries 16:05:16 <Jeremy_Rand_Lab19[mds]> alright cool, less for me to worry about 16:05:43 <morganava> and finally you've probably noticed a flurry of gitlab activity/labeling over the past weeks 16:06:59 <morganava> I'm happy to say the the bulk of the changes/labeling has been completed for the tor-browser repo 16:07:30 <morganava> and generally speaking, don't take a label as gospel/ground truth just because i labeled it 16:08:22 <morganava> i.e. if something is labeled high impact and is actually no impact or if something is the wrong priority don't hesitate to fix it 16:08:54 <morganava> or if we've determined there's no work to be done, the issue is stale or the work has already happend also feel free to close it :) 16:09:55 <morganava> the next immediate steps for me at least will be adding/updating existing issue templates (like the new mozilla audit issue template henry-x added) so hopefully going forward we can keep thigns organised 16:10:15 <morganava> (and follow through on one of the tasks i promised i'd do from lisbon last year) 16:11:03 <morganava> dan_b, clairehurst: i saw some chatter in tor-browser-dev earlier, can you give us an update on the weird Android connect-assist issue and next steps there? 16:11:15 <dan_b> we're going with clairehurst's fix 16:11:29 <dan_b> something in some engine isn't initialized till a tab/url is loaded 16:11:40 <dan_b> I had sure hoped there was a way to just directly invoke that initialization 16:12:18 <dan_b> but after two days of digging I can't find what needs to be initialized, and digging down through geckoview, paths I saw all quickly needed tabIds and etc, so just, loading an "about:" tab really does seem the best approach 16:12:23 <dan_b> and that does seem to fix it 100% 16:12:33 <dan_b> so I'm just tweaking the comments on the MR now and gonna merga 16:13:08 <clairehurst> I wonder if it's something with 'lazy' initilizations 16:13:23 <clairehurst> Something I want to look into at some point 16:14:10 <clairehurst> But yeah I think it's a decent solution 16:14:13 <dan_b> https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-128.8.0esr-14.5-1/toolkit/modules/DomainFrontedRequests.sys.mjs?ref_type=heads#L520 16:14:52 <clairehurst> also, any extra work its doing (loading the browser) is just work that would be done when the bootstrap finishes 16:14:58 <dan_b> domain fronting gets Services.io protocol handlers, and then returns it and passes it to hte ResponseListener on line 392 16:15:39 <henry-x[mds]> does the current solution rely on a race condition? 16:15:47 <dan_b> when things arent initialized the httpHandler immediatly calls onStopRequest with an error code 16:16:17 <dan_b> when the engine is initialized it works, calling onDataAvailable 16:16:24 <Jeremy_Rand_Lab19[mds]> dan_b / clairehurst : would the "load about:" approach also potentially be less susceptible to upstream code churn in whatever is initializing things? 16:17:02 <dan_b> henry-x[mds]: I don't believe so? it just tells the engine to open a tab. and we do that as soon as CA loads, should be well ready before we get close to doing a domain fronting call 16:17:15 <clairehurst> Yeah ^^ 16:18:02 <dan_b> Jeremy_Rand_Lab19[mds]: kinda yeah, but in an overkill way. I'd still love to find out the root cause and see if there's a directer way to invoke it, but I gave myself 2 days of research in this late stage of the relese cycle and couldn't. 16:18:03 <henry-x[mds]> so it is a race condition that we always beat? I guess it is the same thing as no race condition 16:18:32 <Jeremy_Rand_Lab19[mds]> dan_b: makes sense 16:19:01 <dan_b> henry-x: i'm not 100% it is a race condition. we fire off the call to load the tab. not sure how much direct on thread init there is and how much is handed off to another thread possibly creating a race condition 16:19:14 <dan_b> i simple still dont have enough of a view of what geckoview engine is doing 16:19:50 <henry-x[mds]> ok, it is probably fine. Just kind of curious 16:19:50 <morganava> dan_b, clairehurst: so the high-level problem is basically moat's web requests depend on *something* to be initialised which loading a tab also initialises, so rather than initialising w/e it is that is requried, we're initialising *everything* (which we would need to do anyway to open a new tab after bootstrap) 16:20:06 <dan_b> yes 16:20:09 <clairehurst> yeah 16:20:52 <morganava> sounds like a mystery for another day, just make sure there's lots of healthy comments around the tricksy init and/or the commit message so we don't forget about it for years 16:20:57 <dan_b> did gitlab just get sad? 16:20:59 <clairehurst> I basically found that opening tabs fixed the problem, so I made it automatically open a tab 16:21:06 <morganava> its' been up and down all morning :p 16:22:09 <dan_b> morganava: my conclusion too. don't have more time for that now. and from what i did discover, it mostly made me like clairehurst's approach more and more cus the tba/geckoview side of initializing things is... a mess... and also the browser side is also... windy 16:22:56 <morganava> PieroV: has the legacy tor-browser branch been rebased+merged? 16:23:00 <dan_b> henry-x[mds]: if you're curious, here's my patch adding logging from both the TorConnect.sys.mjs side and the geckoview side to try and find my way to the heart of the issue 16:23:01 <dan_b> https://gitlab.torproject.org/dan/tor-browser/-/commit/046b1acd86c6e63d76b0f6b3b9c618550b35ce70 16:23:20 <PieroV> morganava: it has. I think we need to tag Mullvad Browser yet 16:23:37 <morganava> hmm yes i merged stable earlier but didn't tag 16:23:43 <PieroV> Okay, will do 16:24:19 <morganava> do we have any volunteers for legacy tb, stable tb and stable mb release-prep today? 16:24:26 <morganava> and separately, signing tomorrow ^^; 16:24:48 <PieroV> I can do any of these 16:24:50 <PieroV> Let me know 16:25:04 <morganava> i'm also remarkably free tomorrow so can take on some signing this week 16:25:18 <PieroV> Also build if needed (I don't mind using my local builds if I do the signing ^_^) 16:25:30 <morganava> oh actually 16:25:54 <dan_b> but yeah if someone knows where `Services.io.getProtocolHandler` and all the functionality with that lives, that's the next place to look for what's not initialized and why it's callin the responselistener's onStopRequest 16:26:19 <morganava> PieroV: can you release-prep stable? I ran into some issues last week with the scripts at least partially due to the label renaming so they could probably use a patch 16:26:31 <ma1> I still need to finish backports, hopefully they'll by 20 UTC. It seems too late for PieroV, so I can take on relpreps if someone on the other side of the pond can build locally 16:27:03 <morganava> and i'm happy to take legacy 16:27:15 <PieroV> ma1: I'll be on a meeting up until 1:30 from now 16:27:24 <PieroV> Which is... 18UTC I believe? 16:27:32 <morganava> yep 16:27:35 <PieroV> My TZ math needs to be updated with Europe i nDST 16:28:15 <dan_b> haha 16:28:27 <dan_b> welcome to dst 16:28:33 <morganava> heh 16:29:10 <morganava> alright ma1: you can take release prep+tagging after backports 16:29:24 <ma1> ack 16:29:27 <morganava> and i can come back after dinner and build 16:31:12 <morganava> dan_b: is there some way to test the UX survey changes in stable? 16:31:36 <morganava> (that doesn't require code-changes or a debugger) 16:31:42 <dan_b> del del del 16:31:43 <dan_b> um 16:31:53 <dan_b> maybe set your phone date into the range? 16:32:27 <dan_b> i only tested the way we usually have, disabeling the hiding code 16:32:29 <morganava> heh ok 16:33:05 <morganava> in that case, can you verify later today locally that the UX works properly on Android once we have 14.0.9 build tags in a few hours? 16:33:28 <morganava> not that I expect it to have broken over the past week, but just don't want to disappoint UX :) 16:34:09 <dan_b> sure 16:34:24 <dan_b> so do a local build, and do the remove hiding test? or the time change test test? 16:34:49 <morganava> whichever makes you most confident that it'll turn on correctly in a few weeks :) 16:35:01 <dan_b> haha ok i'll try a time change test 16:35:19 * dan_b recals android acting funny sometimes when you set it a lot into the future 16:35:24 <morganava> (you will probably need to bootstrap *first* in that case since tor is picky about having the right time) 16:35:31 <dan_b> ... 16:35:33 <dan_b> esh 16:35:39 <dan_b> right 16:36:01 <dan_b> yeah time travel tests... are... not great. will try and see if it's viable anyways 16:36:56 <morganava> ok 16:37:05 <morganava> i have nothing else on my list 16:37:18 <morganava> does anyone else have topics/announcements? 16:37:35 <Jeremy_Rand_Lab19[mds]> nothing notable here 16:38:53 <morganava> ok, and if anyone is wondering what priorities are, have a look at our two 14.5 milestones 16:39:30 <morganava> and if nothing there looks appropriate, we have a big backlog of buzilla triage 16:39:49 <morganava> have a good week everyone o/ 16:39:57 <ma1> grazie, ciao! 16:40:00 <morganava> #endmeeting