18:02:44 <mikeperry> #startmeeting app-dev
18:02:44 <MeetBot> Meeting started Mon Sep 14 18:02:44 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:44 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:04:04 <mikeperry> Last week, I wrote a handful of Tor proposals so they'd be available to roadmap/discuss at the dev meeting. I also coordinated with Nick, and I think we now finally have an Apple developer account for #6540.
18:04:14 <mikeperry> This week, we need to decide what should go into 5.0.3/5.5a3. I am looking at the tickets now, which is why I started things a bit late.
18:04:48 <mikeperry> We should be getting tags for the next Firefox ESR pointfix tomorrow/weds
18:05:16 <mikeperry> So we should aim to have everything in by Weds/Thursday.
18:05:53 <mikeperry> I also may miss the IRC meeting next week. It will be a lose call
18:06:56 <mikeperry> I think I might end up spending time wrapping up my Tor proposals, but I plan to get #16783 in for 5.0.3 at least.
18:07:07 <mikeperry> that's it for me for now, I think
18:10:53 <GeKo> here is what i did
18:11:07 <mikeperry> it seems like my IRC client is lagged and may fall off
18:12:13 <GeKo> i worked on #10599, #13419 and #15578
18:12:24 <GeKo> and looked at some code to review
18:13:08 <GeKo> it seems i have to update the fun story abuot getting hardened builds within gitian
18:13:31 <GeKo> the latest episode is missing which costed me several hours to sort out
18:13:37 <GeKo> but there is progress :)
18:14:01 <GeKo> this week I'll do more of the above + reviews and release preparations
18:14:10 <GeKo> that's it for me.
18:15:07 * mcs will go next
18:15:14 <mcs> Last week, Kathy and I fixed #16910 and worked on #16735 (we posted a fix for the latter ticket earlier today).
18:15:22 <mcs> We looked briefly at #16620 and did a code review for #16909.
18:15:34 <mcs> We made some travel arrangements for Berlin (I will be there the first part of the week for the planning sessions).
18:15:40 <mcs> This week we will work on #16937 and look at #16753, at least to see if it is less of an issue now that we are planning to whitelist more fonts in TB 5.5.
18:15:42 <GeKo> \o/
18:15:56 <mcs> We may also work on a design for #16940.
18:16:01 <mcs> That's all for us.
18:16:31 * arthuredelstein can go
18:16:39 <arthuredelstein> Last week I wrote patches for #17009, #16983, #17046.
18:16:49 <arthuredelstein> And I did some work on #17023.
18:17:00 <arthuredelstein> This week I hope to work further on #14429, #16672, and #16936.
18:17:38 <arthuredelstein> I'll also be at the planning part of the Berlin meeting.
18:17:39 <arthuredelstein> That's all for me
18:17:41 <GeKo> arthuredelstein: what remains in #15646 to be done assuming the AltGr thing is handled in #17009 too?
18:18:48 <arthuredelstein> GeKo: I think I need to look the AltGr there as well -- there may be an additional issue. Apart from that I'm not sure if there are further issues.
18:19:27 <GeKo> okay, just to not forget all the loose ends here
18:19:44 <arthuredelstein> yes, good point
18:22:42 * boklm can go next
18:23:18 <boklm> This week I looked at some tor-messenger build problem on wheezy (for gtk3 with firefox42) and found that firefox42 can still be built with gtk2 using a configure option, so we will switch back to Ubuntu lucid
18:23:41 <boklm> In the split-repo script to fetch results from Try, I added an option to download failure logs and parse test filenames, and list them in the results
18:23:48 <boklm> I added a config option to ignore tests by filename, and an other option to check that a test failed (for the branches where we want to check that a test is failing without its corresponding patch)
18:23:59 <boklm> I also added notes on which branches are already upstreamed
18:24:10 <boklm> The config to check some tests failed and ignore others looks like this: https://people.torproject.org/~boklm/tmp/try-config.txt
18:24:17 <boklm> The results with test filenames look like this: https://people.torproject.org/~boklm/tmp/failed-branches.txt
18:24:27 <boklm> This week I'm planning to add more test files to the ignore list
18:25:00 <boklm> That's all for me
18:26:29 <huseby> i'll go
18:26:44 <huseby> so last week i got an r- from the peer for bz 232227 (system colors)
18:26:53 <huseby> i need to break that patch up into two patches and resubmit
18:26:56 <huseby> that will happen today
18:27:40 <huseby> i also gave up on writing a solid unit test for bz 962358, there's not way to do it without patching up necko
18:27:51 <huseby> so that's going out for review today, sans unit test
18:28:36 <huseby> I also started in on bz 962358, Provide an API/observer to close persistent connections
18:28:54 <huseby> there's some design work that needs to be done that i'm working on now
18:29:22 <huseby> i'm taking over steve e's work on containers/first-party isolation, so all of this is related
18:29:29 <huseby> that's it for me
18:29:45 <GeKo> in case you have questions for us just ask
18:29:56 <huseby> I will :)
18:29:57 <GeKo> ( re 962358)
18:30:00 <huseby> sure
18:30:10 <GeKo> and other things of course
18:30:11 <huseby> i'm also booked for the meetup in two weeks
18:30:12 <GeKo> :)
18:30:14 <huseby> so i'll see you all there
18:30:16 <mikeperry> mcs: I think I agree with the review on https://bugzilla.mozilla.org/show_bug.cgi?id=232227#c25. it seems odd
18:30:27 <huseby> mikeperry: me too
18:30:38 <huseby> that's why i'm not pushing back, i'll just split it out, submit two patches
18:30:50 <mcs> Regarding https://bugzilla.mozilla.org/show_bug.cgi?id=232227, it seems like the original report is describing a different thing that what the patch is intended to fix.
18:31:13 <mcs> "different thing THAN what the patch is intended to fix"
18:31:22 <huseby> (BTW, i set up a bugzilla url shortner over the weekend just for fun so http://bgz.la/232227 should work)
18:32:09 <huseby> mcs: yes there's two things here
18:32:16 <mcs> OK
18:32:17 <huseby> 1) report system colors always when the pref is on
18:32:26 <huseby> 2) when using system colors, make sure we never show black-on-black
18:32:54 <huseby> also, the nit about the proper way to get the doc pointer is valid
18:33:08 <huseby> i need to double check that i can always get it tho
18:33:17 <mcs> I agree; it sounds like a different approach there will be cleaner.
18:33:39 <mcs> Right. Let me know if you need any help, but it sounds like you are on top of things.
18:34:29 <huseby> i also have a question about bz 962358
18:34:36 <huseby> the tor patch has this: https://gitweb.torproject.org/tor-browser.git/tree/netwerk/protocol/http/nsHttpHandler.cpp?h=tor-browser-38.1.0esr-5.0-1&id=e8fa092280b57f8315115f25bc4d18a909bae8a8#n346
18:34:57 <huseby> the nsMainThreadPtrHolder holding the pointer to the observer service
18:35:06 <huseby> we don't do that in FF
18:35:10 <huseby> is that something Tor added?
18:35:19 <huseby> or is that something we had and later removed?
18:35:32 <huseby> (I could figure this out in history, but I thought I'd ask here first to save some work)
18:36:33 <huseby> for comparison, here's what the mainline code does: https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpHandler.cpp?from=nsHttpHandler.cpp#358
18:36:40 <huseby> mikeperry, arthuredelstein ^^^
18:38:37 <mikeperry> It looks like that was added by McManus
18:39:18 <mikeperry> bug 897503 - part 3 several nsHttpHandler nsCOMPtrs need to be nsMainThreadPtrHandle r=sworkman
18:39:44 <mikeperry> so possibly later removed?
18:41:16 <huseby> mikeperry: thanks, i'll check it out
18:44:48 <mikeperry> mcs: look forward to meeting you in Berlin, finally, btw! :)
18:44:56 <mcs> :)
18:47:03 <mikeperry> hrmm. I am bothered by #17046. tempted to just flip that pref, but wondering what else might break by it
18:48:18 <arthuredelstein> I think the two main concerns with the current DOMHighResTimeStamp is that
18:48:27 <arthuredelstein> (current implementation)
18:48:38 <arthuredelstein> 1. It won't be very precise
18:48:51 <arthuredelstein> 2. It doesn't account for adjustments in the system clock
18:49:00 <arthuredelstein> I think we don't care about (1)
18:49:09 <arthuredelstein> but #2 could occasionally be an issue.
18:50:21 <arthuredelstein> I suppose the other approach we can take is to patch the existing implementation, but we would also need to worry about (2) potentially.
18:51:05 <mikeperry> hrmm. I wonder what sort of issues that would cause, though? Is #2 why Mozilla wants to switch to OS-sourced timestamps for it?
18:51:55 <arthuredelstein> I have asked birtles that question but didn't get a reply yet.
18:52:08 <arthuredelstein> But #2 is an issue even if you use OS-sourced timestamps.
18:56:26 <mikeperry> hrmm, well I guess update the bug when you get more info? but yes, we could also just patch it. I'd like to get rid of this somehow in 5.0.3
18:57:56 <mikeperry> is mega broken for normal firefox due to #16855/https://bugzilla.mozilla.org/show_bug.cgi?id=1198559 too?
18:58:20 <GeKo> no
19:00:02 <arthuredelstein> It's broken in Tor Browser because our blob isolation needs the correct first party, and the buggy code in FF doesn't provide the right first party.
19:00:07 <mikeperry> that also seems like something we should fix. Can we just grab that patch from the bugzilla bug?
19:00:31 <arthuredelstein> Yeah, I'd be inclined to use the patch GeKo used in https://trac.torproject.org/projects/tor/ticket/16855#comment:8
19:00:41 <mikeperry> otherwise random things using blob will be broken for a while, which seems bad
19:02:24 <GeKo> arthuredelstein: we might get some help from bz. could you answer his need_info?
19:02:33 <GeKo> he is usually quite helpful.
19:02:57 <GeKo> i don't like to backport that patch as is given that there seem to be a bunch of issues with it
19:03:20 <GeKo> definitely not for the stable. who knows what this is going to have for an effect
19:03:57 <arthuredelstein> Yes, will do
19:05:32 <mikeperry> ok, then perhaps we consider #17046 and #16855 + backport for 5.5a3.
19:05:49 <mikeperry> Is the story similar for #16874 and ICU?
19:06:00 <GeKo> that was my thinking, yes
19:06:23 <mikeperry> ok
19:06:34 <GeKo> we don't have stuff for that one right now.
19:07:13 <GeKo> i might get the cross-compilation things sorted out in which case we could test a fix in the alpha
19:07:50 <GeKo> but i am not overly optimistic given ICU's complicated build system
19:09:07 <mikeperry> sad
19:10:33 <mikeperry> I wonder if we can fill in that intl property with some bogus info.. our own polyfill for example
19:11:10 <mikeperry> just enough so that exceptions aren't thrown
19:12:00 <mikeperry> ok, well I guess we can ponder that later. anything else for the release/meeting at present?
19:12:07 <arthuredelstein> Any opinion on #17009? It potentially breaks some sites, so it's certainly something we would want to test in an alpha first.
19:12:59 <GeKo> yes, definitely
19:13:16 <GeKo> I gonna test it tomorrow a bit and look at the code
19:14:06 <arthuredelstein> thanks
19:14:17 <mikeperry> arthuredelstein: hrmm... I am imagining some webapp that gives you a menu when you pres alt or shift...
19:14:23 <GeKo> mikeperry: might be an idea. we should be able to put a hack into torbutton, uh
19:14:39 <arthuredelstein> mikeperry: exactly
19:15:11 <arthuredelstein> It's definitely a tradeoff
19:16:40 <mikeperry> I think alt is bad news. shift seems ok, though
19:16:58 <mikeperry> in terms of stuff most likely to break
19:17:48 <arthuredelstein> suppressing alt is bad news?
19:18:07 <mikeperry> yeah, I don't think we should suppress alt at all
19:18:56 <arthuredelstein> Because alt is more typically used to show a menu?
19:18:57 <mcs> What about my pinball game that ues shift for flipper/paddle control? I am not sure if that is still a thing, but it was on some old PC pinball games ;)
19:19:14 <mikeperry> oh dear
19:19:15 <mcs> alt does seem like it is more likely to cause problems
19:19:55 <mcs> Is there already a pref so users can disable the suppression if they find it is causing a problem?
19:20:28 <arthuredelstein> A simple example for ALT is the German Eszett
19:20:44 * GeKo is looking forward to playing some games tomorrow with the patch
19:20:45 <arthuredelstein> Which is alt-s on a US keyboard
19:21:05 <arthuredelstein> but the - key on a German keyboard (at least on my present computer)
19:21:43 <arthuredelstein> So if we don't suppress alt, then those two keyboard will be distinguishable if someone types ß
19:22:02 <arthuredelstein> *keyboards
19:23:03 <GeKo> yeah, that rabbit hole is deep it seems :/
19:23:50 <GeKo> but i think having a pref even for the alpha seems to be smart
19:23:55 <GeKo> given the possible breakage
19:24:01 <arthuredelstein> I agree
19:24:15 <arthuredelstein> I'm not aiming for perfection here, but the alt and shift keys worry me in particular
19:24:32 <arthuredelstein> Another case is that on the AZERTY keyboards, } requires the alt key.
19:27:58 <GeKo> yes. if you could add a pref i think trying that in an alpha is good
19:28:17 <GeKo> even if the only purpose is to get some data what really is breaking
19:28:27 <GeKo> *about
19:28:30 <mikeperry> hrmm.. well, we can try it in the alpha. I am skeptical about the reward vs impact, so we def want a pref for this so we don't have to juggle the patch when we get to 5.5-stable
19:29:50 <arthuredelstein> I'll work on adding a pref.
19:31:16 <mikeperry> in terms of most important things, I still think finding workarounds for the blob issue and the ICU issue are more important
19:31:35 <mikeperry> #16874 and #16855..
19:32:21 <mikeperry> having websites broken like that will cause people to do much worse things, like use an old TBB or not use TBB at all
19:32:30 <mikeperry> so in the grand scheme, they are way worse for privacy :)
19:33:54 <arthuredelstein> I think you're right!
19:35:45 <mikeperry> ok, cool. just wanted to make sure we agreed on priorities for fixes/stopgaps for now
19:35:48 <mikeperry> anything else for this meeting?
19:37:02 * mikeperry winds up..
19:37:09 <mikeperry> #endmeeting *baf*