14:58:57 #startmeeting Tor Browser Weekly Meeting 2022-11-07 14:58:57 Meeting started Mon Nov 7 14:58:57 2022 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:58:57 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:15 hello everyone, meeting pad as usual here: https://pad.riseup.net/p/tor-tbb-keep 14:59:21 * Jeremy_Rand_36C3[m] checks clock, is pretty sure I'm here at the right time 14:59:39 yes it is 15:00:44 i made it, woo 15:02:05 * ma1 offers dan_b a steaming coffee cup 15:02:29 hahaha thanks 15:04:52 ok let's get started 15:05:41 I have no announcements this week! 15:06:13 is this an announcement? :) 15:06:21 perhaps 15:06:44 regarding tickets, things living in ~Sponsor 131 and ~Next are highest priority, so if you are wondering what to do next, please grab from there 15:06:53 so maybe that is an announcement 15:08:16 if nothing there looks like a good fit for you, then move on over to ~Backlog instead of ~Next and generally prefer things wih the ~FF102-ESR and ~Sponsor 131 labels 15:08:17 anyway 15:08:50 discussion point: I think i recall last week seeing a thread in gitlab somewhere that the stick lang pref didn't get applied for en-US 15:08:51 I think I'd like to promote one thing from Icebox lol 15:09:05 yes I'll take a look at that today 15:09:08 PieroV: now that is a bold claim :D 15:09:31 re sticky pref: I had even though of adding a secondary pref as a safe measure :( 15:09:32 seems there was a second line in tbb I needed to apply sticky to 🙂 15:09:47 (sorry for noticing that second line, too) 15:09:55 * for not noticing 15:10:08 no worries 15:10:15 richard: the icebox thing is tor-browser#32411 15:10:33 And basically its dupe tor-browser#31064, which is future 15:10:34 i'm surprised that one is in icebox 15:11:02 The thing is that we are adding a bar to tell users to change their language, and it triggers letterbox for about:torconnect 15:11:11 (I've added "and others" to the title earlier) 15:11:33 Your patch works, but I'm not that confident in setting a series of pages on par with about:blank 15:11:45 yeah that *seems* reasonable to me 15:12:20 ok, moving it to ~Doing or ~Next then 15:12:37 I feel like that bar needs a redesign to work well with our letterboxing. I get it all the time when normally browsing with tor browser. Usually the missing media codec notification 15:12:55 PieroV: relatedly I've been running into very annoying UX caused by letterboxing on the NoScript popups 15:13:00 ok, if we need some more patches for the localization migration, then we need another stable build 15:13:20 Similar with the "find in page feature". That's just my pet peeve though 15:13:32 richard: should we wait a week and include sec backports? 15:13:36 Letterboxing causes the height of the NoScript popup to shrink to the point that I need to scroll in order to reach the allow/reject buttons 15:13:54 * richard quickly checks calendar 15:14:10 Jeremy_Rand_36C3[m]: that's a "known" issue, too: tor-browser#31064 15:14:18 Jeremy_Rand_36C3[m], so we should checks whether webextensions are treated as "privileged content" for letter boxing purpose in the new patch 15:14:58 yeah makes sense. Maybe we do want to prevent fingerprinting by malicious WebExtensions though? 15:15:01 PieroV: yeah we may as well 15:15:11 henry-x: relatable for find, but codecs should not appear in TBB, imho 15:15:14 Or is the WebExtensions API flexible enough that it's pointless? 15:15:54 Yes, it's pointless 15:16:13 (we already relax RFP stuff for webextensions) 15:16:23 Yeah, not surprised I guess 15:16:46 Anyway, bug nextized, doingized and taken :) 15:16:54 :p 15:17:06 ma1: we should see if they are the same bug 15:17:15 I didn't dupe them already, but I was tempted to do that 15:17:35 PieroV, I'll check as soon as we're out of this meeting 15:19:06 boklm: what's the currrent state of universal bundles? 15:19:16 macOS universal bundles* 15:19:55 richard: I had an error while doing a testbuild after rebasing, I still need to look at it 15:20:09 but I think it's almost ready 15:21:01 is it reasonable to plan for an alpha next week to go along with a rebase? 15:21:34 yes 15:21:43 PieroV: The notification is "To play video, you may need to install the required video codecs." and it'll show up for me every now and then. If you go to "twitter.com" and scroll down and wait a bit it pops up. It uses the same popup as the language notification you are working on, so has the same letterboxing problem. 15:22:37 But in that case the content is not privileged, right? Not much to do be done about it? 15:23:54 (but it seems strange that the notification box changes the content geometry in a way that trigger letterboxing. Maybe something to be changed in the algorithm?) 15:24:04 yeah. I'm just saying it would be nice if that notification didn't change the browser content size since it gets used every now and then. The popup panels work better 15:24:38 ok i've updated my toto list for next week 15:25:14 henry-x: sounds like something we should plan for 12.5 15:25:26 agree, and possibly uplift 15:26:26 I wouldn't be surprised if `gNotificationBox` is due an upgrade within mozilla-central 15:28:39 ok does anyone have anything else? I'm not seeing any bolded items 15:28:52 nothing from me 15:28:52 except for the cictui UI bugs 15:28:54 I've bolded an item in ma1's section 15:28:58 i'm just bold-blind apparently 15:29:09 ok what's going on in the circuit UI 15:29:10 I suppose I'm curious what is happening with weblate and fluent 15:29:28 Should we really investigate circuit UI bugs for 12.0? 15:29:33 just that if PieroV has more ideas for the locale saving bug to add some thoughts to it before I just fix the one line in tbb 15:30:17 ok 3 more items then 15:30:27 richard: okay, I think I can answer to all 3 of them 15:30:28 PieroV, you mean it's not worth? 15:30:41 alright then :) 15:30:53 ma1: yes, we have many circuit UI bugs 15:31:09 And tbh, that part should be completely dismantled in 12.5 15:31:30 richard, it seems the UI tends to disappear and/or become messy in weird circumstances. But it it's doomed anyway, I'll drop the ball :) 15:31:55 For a number of reason, and one is that it's all JS loaded by browser.xhtml in its onload 15:32:07 ma1: yeah tbh I think the implementation should probably be revisited 15:32:35 Which is fine for the visualization, but I think that we should move the part that collects circuits, especially if we hope to get the data directly when we switch to Arti 15:32:51 Rather than having to collect them in the way we do (we listen for circuit creation events, IIRC) 15:33:12 Even though a working implementation would be nice also with little-t-tor 15:34:13 that makes sense to me 15:34:55 is that the fundamental issue there w/ the circuit display (the UI listening for tor events rather than referencing some global component that absracts that all away from it?) 15:35:44 richard: I'm not sure of what's happening, but getting everything more sorted could help, I think 15:36:09 I can start investigating low priority and manage upset user while we approach the refactoring. 15:36:34 well regardless, i don't think patching things up on the edges is a high priority right now 15:37:09 (and we won't have circuits in S131, so...) 15:37:57 to what extent is the naming system integration in the circuit display affected by this? (Both the FPF and Namecoin variants) 15:38:41 i'm those patches will need to be updated when we come back to circuit display 15:38:48 i'm sure those* 15:38:50 Jeremy_Rand_36C3[m]: I think it's safe to assume that the patches will need to be completely recreated 15:39:11 It might be sensed to merge parts of them before the process 15:39:14 PieroV: OK. And that will not be for a while, since the rewrite is not super soon? 15:39:15 It's on the list I guess? 15:39:35 not until 2023 I should think 15:39:50 Jeremy_Rand_36C3[m]: I wanted to start earlier, but then decided to push to 12.5 because it was too long and not doable for the target period for 12.0 15:39:50 Early 2023? Or mid? 15:39:57 probably around the time we begin arti integration work 15:39:57 12.5 15:40:29 Honestly, I think we could start with a copy&paste for torbutton 15:40:42 And then start splitting it into separate commits, since it has many components 15:40:58 OK. When that gets near, I guess give me and Arthur a heads up and we can try to help. I'd really like to have the FPF and Namecoin circuit display codebases converge, it's unfortunate that there's duplication of functionality there. 15:41:00 sounds smart to me 15:41:05 For example, the drag&drop protection doesn't need to be with the other tor-related stuff 15:41:43 henry-x: re weblate and Fluent, what do you want to know exactly? I've checked again tor-browser!374, and the linked GitHub issues are still open 15:41:54 These issues are about attributes 15:42:27 The other issue is their handling of newline and indenting 15:42:32 FYI I've been super busy the last few months with funded work (mostly TLS related) but that funded work will be over at the end of the year, so if the circuit display stuff is happening in 2023 then I should be more available than I have been lately 15:42:44 So, recently I've named Fluent because I'd like to create the strings for the language notification with Fluent 15:42:59 Jeremy_Rand_36C3[m]: ack 15:43:21 They are simple strings, with a pair of variables and the brand name 15:43:52 So, if Weblate can handle them already, I think it's sensed to manage them with Fluent/Weblate 15:44:07 I assume that patch will be in base-browser, too, since base-browser is also multi-lingual 15:44:29 I don't have a newline in these strings. But I don't have the issue number for that handy 15:46:49 Do you know how well weblate handles group comments, or variables? 15:47:21 henry-x: nope, I had tested Fluent before we switched to Weblate 15:47:33 And then your file was the first one to be tested after the switch 15:47:46 (well, also brand.ftl, but that didn't have issues, afaik) 15:48:58 My new files have some variables 15:49:04 *new file has 15:49:26 https://gitlab.torproject.org/tpo/translation/-/merge_requests/5 15:50:39 dan_b: for the language pref, I think we could add our own preference that tells the original language a user downloaded in case something doesn't work with 12.0 15:51:02 ah ok, so add lines in tbb to inject those, and lines in tb to persist them? 15:51:09 just paralel to what we have now? 15:51:36 Sorta. I was thinking a tor-browser change only 15:51:38 ok. How come you filled in English for the other locales? Don't we want them to be missing by default so that fluent knows to check the next locale? 15:51:51 henry-x: emmapeel asked me to 15:52:19 PieroV: what would an extra pref provide over the existing sticky pref? 15:52:36 richard: it would have saved us from doing a 11.5.8 :D 15:52:56 But nothing, that's why I didn't add the idea to the comments 15:53:14 But fluent works on the basis that if a fluent entry is missing it will look up the entry in the next locale, if we default to always filling in the variables with english then we'll essentially be defaulting to english always 15:53:39 Anyway, I'd implement it with tor-browser.git only, if possible, so we are sure we don't miss lines in tor-browser-build 15:53:50 ah ok 15:54:00 henry-x: I've noticed that. I think we should discuss that with emmapeel then 15:54:09 Because it's something we do differently for all the other formats 15:55:20 Not related, but I think that we could start the migration from transifex to weblate for 12.5a1 15:55:48 (well, just after we release 12.0) 15:55:56 mmmhm 15:56:53 ok cool. I suppose we aren't using fluent yet, so it makes some sense to default to en-US like we do with properties and dtd and TorStrings. But it would be nice to have all the multi-lingual fluent features in the future 15:57:13 *we aren't using just fluent yet 15:57:36 ok 15:57:49 that's almost the hour 15:58:05 have a good week everyone! 15:58:11 thanks! 15:58:12 Thanks! o/ 15:58:16 #endmeeting