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