17:58:59 #startmeeting tor browser 17:58:59 Meeting started Mon May 21 17:58:59 2018 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:58:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:04 boom, meeting time! 17:59:12 hello everyone 17:59:14 hi! 17:59:16 hi everyone! 17:59:17 hello! 17:59:18 buenas 17:59:23 ! 17:59:26 the pad as usual is on: https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N 17:59:48 hi 18:00:29 please mrke the items you want to talk about bold 18:00:33 *mark 18:01:25 hello 18:02:28 ok i am keeping it simple with one item :) 18:02:36 heh 18:02:42 let's get started 18:03:30 esr60-based nightly builds are the item i have 18:03:47 we should get that going before the weekend 18:04:30 the blockers for that are #25543, #25750, 26073 and #26100 18:04:49 #26073 18:05:05 at least that's the 4 bugs i have on the radar 18:05:25 yes, I think those are the 4 18:05:50 if we are good we can include the adapted patches for #24309 and #23247 18:06:01 because antonela is out somewhere doing user testing 18:06:06 * antonela is around, between aiports 18:06:17 :) 18:06:17 yep, this should happen this week actually 18:06:23 and having those features right in the nightly tested can't hurt 18:06:25 yes 18:06:36 I think the end of this week is doable -- is that soon enough for you antonela? 18:06:55 well, we have our first meeting with people tomorrow 18:07:10 antonela: ! 18:07:12 Aha! 18:07:20 if i have it for thursday/friday we can do it 18:07:36 yeah, it's getting tight 18:07:45 if not, i'll go with my static mockups 18:08:02 arthuredelstein: you seem to be involved with most of those patches 18:08:10 if it helps reroute things in my direcion 18:08:14 sorry, hola :) 18:08:17 *direction 18:08:22 One option could be to build a TBB/ESR52 with the new UX patches 18:08:34 e.g. i certainly can look at #24309 18:08:47 well, it depends what's more useful 18:09:32 antonela: ^ 18:09:52 we will test .onion indicators and new circuit display 18:10:12 esr60 seems to be better, but if we dont arrive, esr52 can make the job 18:10:45 let me know what is better for you, geko, arthur 18:11:01 how about this, i review what we have tomorrow and commit it 18:11:07 (assumng we are good) 18:11:19 then we could probably trigger a nightly out of band 18:11:24 or wait for another day 18:11:36 yes, I can trigger the nightly build after you push the commit 18:11:37 and meanwhile we try to get everything done for esr 60 18:11:50 sounds good for me 18:11:52 thanks a lot! 18:11:58 so if we are lucky you might be able to test esr60 with all the stuff 18:12:03 okay, good 18:12:04 great 18:12:05 GeKo: Sorry, a nightly out of band for ESR60? 18:12:31 no, based on esr52 just with the patches for stuff antonella wants to test 18:13:00 Ah, OK. I think that makes sense. Then we can send on the ESR60 stuff when it is ready, if we get it done by Wednesday or so. 18:13:09 and out-of-band means here only that we trigger one without waiting for the next regular build 18:13:19 arthuredelstein: exactly 18:13:24 sounds good 18:13:41 pospeselr: could you post your esr52 patch for the .onion thing, too? 18:14:02 so that i can look at it tomorrow? 18:14:10 yeah for sure 18:14:30 great. 18:15:03 then we get the nightly for antonela tomorrow and try to get esr60 linux nightlies going later this week 18:15:09 cool thanksss 🙏 18:15:14 that's all i have for this item 18:15:46 igt0: wanna tell more about the orfox crash? is that still blocking the release? 18:17:17 sysrqb: or maybe you know? 18:17:25 GeKo, yes, sysrqb and found a crash in the latest Orfox build. It happens in the js engine. Sadly we are not able to reproduce constantly. We need to stress out a website scrolling up and down for some time. 18:17:52 so, this is a firefox bug i assume? 18:18:09 does this happen with a vanilla fennec, too? 18:18:31 yes, I asked tjr to make sure it was not reported and fixed. And a similar bug was fixed in early 2016. 18:18:50 GeKo, i was not able to reproduce with fennec. 18:18:59 huh 18:19:10 it seems like this crash is caused by one of the backport patches, but we're not sure which one 18:19:10 and the previous orfox version? 18:19:22 we can't reproduce with the current Orfox release 18:20:31 so, some patch that got fixed between 52.7.4 and 52.8.0 is causing this to be triggered? 18:20:45 because our patches did not change between those versions afaict 18:20:50 not many patches touched js code logic, so it is surprising orfox is crashing 18:21:21 right, and i did not see a creash with tor browser on the same site where orfox crashed 18:22:32 hrm. 18:23:13 but i did cherry-pick some backports from alpha branch for this new release 18:23:47 The problem is also because the Orfox crashes in a sanity check (MOZ_CRASH). So we don't have a stack trace. 18:24:07 so if igt0 can create a list of sites that consistently crash orfox, then we can bisect and find which commit 18:24:22 You ought to be able to attach a debugger and get a stracktrace from a MOZ_CRASH.... 18:24:53 hrm, igt0, we can try jimdb 18:25:02 good though tjr 18:25:10 thought 18:26:07 I mean, we know where it crashes, because of the MOZ_CRASH, however if it reaches that part of the code, the js engine is already messed up. 18:26:14 but will that give us any javascript stack info? 18:26:41 nay 18:27:29 Ah okay 18:27:37 okay, keep us posted about this 18:27:48 seems pretty urgent to get fixed i guess 18:28:13 alas it's a bit hard to help as i am somewhat unclear what you have not tried yet 18:28:34 yes, it'll be our top priority this week 18:28:40 I would ask in jsapi to be sure, there is a function called DumpJSStack() that might be able to be called from a crash in gdb and give you a JS stack 18:28:42 sysrqb: have you reverted the commits you cherry-picked for that release and checked whether one of those is the issue? 18:29:02 tjr, oh great!, it will be helpful 18:29:12 nice 18:29:39 GeKo: no, i don't think we reverted - igt0, right? 18:30:36 alright, thanks for the update 18:30:53 I reverted few patches, however because I am not able to reproduce constantly, i am not sure if the reverted patch is the culprit. 18:30:54 isabela: you are up! 18:31:35 yes 18:31:54 i will start the process to extend our contract with sponsor9 18:32:10 *8 18:32:12 and wanted to check if you would want it to be dec 31 the end date 18:32:13 ops 18:32:14 yes 8! 18:32:40 sounds good to me 18:33:05 if you want more time than that is ok too 18:33:08 we had the stable tor browser for mobile as kind of christmas present in Rome :) 18:33:22 well i doubt we'll be done much earlier 18:33:47 me too 18:33:49 i meant to say later than dec 31 18:34:25 i think starting with dec 31 sounds like a good idea 18:34:47 they have a bit more paper work than otf 18:35:22 ok 18:35:25 i will go with dec 31 18:35:53 well, i am fine with march 31 if the risk is doing another round of paperwork end of dec 18:36:18 but i am a bit hesitant to do that tbh 18:36:25 np 18:36:43 k 18:36:47 arthuredelstein: you are up 18:36:53 lets go with dec 31 (i will also coordinate this with the sponsor and follow their guidance/feedback) 18:36:57 thx 18:37:10 We have a bunch of regression test patches in tor-browser.git 18:37:16 most for fingerprinting checks 18:37:38 But the fingerprinting patches are already uplifted with their own regression tests in mozilla-central 18:37:55 So the question is whether we want to hold on to our own regression tests or just drop them. 18:38:13 The only advantage in keeping them is redundancy, in case a something is removed or missed at Mozilla's end. 18:38:41 well, the problem is in part that our tests don't match the final implementation in mozilla anymore 18:38:54 i think that it true at least for some of the tests? 18:39:03 *is 18:39:10 That might be the case -- I'm actually not sure. 18:39:30 I am pretty sure that some of them will break :) 18:39:33 User Agent for example 18:39:37 yep 18:39:52 so that makes them less useful to begin with 18:40:06 and we should not spend time fixing our redundancy tests 18:40:21 That's my inclination as well 18:40:31 media statistics (if you have that test) probably, canvas prompt, keyboard layout... 18:40:42 and then there is the issue that we aren't running those tests anyway right now 18:40:56 yes, exactly 18:40:57 at least in a regular manner 18:41:14 so, all in all it does not sound that useful to keep them around 18:41:20 I think we'd be better off focusing on writing out-of-band tests that work in any browser in any case. 18:41:34 i agree 18:42:08 OK! So I will drop them from the #25543 branch 18:42:28 yes, sounds good 18:43:00 okay, anything else before we move to the discussion part? 18:43:34 okay, disussion then. 18:43:46 next meeting date: next monday is us holiday 18:44:07 does everyone have time on tuesday to do our weekly meeting? 18:44:19 same time and same place? 18:44:26 that's good for me 18:44:33 that's ok for me 18:45:30 hearing no complaints so far, good 18:45:31 I am not 100% sure if brade and I will be there but Tuesday is better than Monday, for sure. 18:45:44 works for me! 18:46:02 me too 18:46:02 then let's tentatively plan for that day 18:46:12 i'll send an email to tbb-dev tomorrow probably 18:46:23 the second item: all hands topics 18:46:36 tjr: looks like a good list to me 18:46:56 tjr this is what i said the other say: 18:46:56 Product Discussion I'm leaning on Wennie to arrange 18:46:57 14:42 < sysrqb> snorp, nalexander, anyone else who can help us help them help everyone 18:47:00 14:44 < sysrqb> it seems ike mobile is in a weird state right now, but if we can discuss how we can upstream fennec patches (particular who can review them) 18:47:03 14:44 < sysrqb> that'd be pretty worthwhile 18:47:19 err, *day :) 18:47:33 Fingerprinting / Tor Uplift I'll probably delay scheduling until Ethan has started and I've synced with him 18:47:41 should we ping network team to add stuff to this all hands list? 18:47:41 Network Programming I need t email about 18:47:52 UI/UX i have an email ready to go, same with sandboxing 18:48:28 tjr: let me or us know who you'd like to coordinate to get input for those sessions from our side 18:48:33 WebRTC I think we're set on, so long as Arthur or Richard knows what Tor would like to do in WebRTC land :) 18:48:52 not sure if a pad would help here 18:49:53 probably 18:49:58 just to make sure everyone's o the same page 18:50:21 yep 18:51:33 isabela: sounds good to me 18:51:47 i think having those items on the pad would be good as well 18:52:18 so that we have an overview of all our activitives/plans for the meeting at one place 18:52:39 ++ 18:52:49 isabela: could you poke the right people? 18:53:48 do we have anything else for today? 18:54:30 does not seem to be the case 18:54:38 thanks everyone then! *baf* 18:54:43 #endmeeting