mozilla :: #fx-team

10 Oct 2017
11:06flodjohannh: I think this bug should go through copy review before someone tries to reland it, but it's so huge I'm afraid I might miss if it already happened https://bugzilla.mozilla.org/show_bug.cgi?id=967895
11:06firebotBug 967895 NEW, cfu@mozilla.com Prompt (w/ Site Permission) before allowing content to extract canvas data (Tor 6253)
11:07flodhttps://hg.mozilla.org/mozilla-central/rev/0a482229bed6#l3.9
11:08flodthe message is cryptic, completely different from the others (permission to) "Do action x", and I'm not even sure it's correct (I'd expect "Extract canvas data")
11:12flod(commenting in the bug)
11:13johannhflod: the copy comes from jsavory on the UX team afaiu
11:13flodthanks, let me needinfo her to double check
11:14flodI can't find any mention in the bug
11:14johannhthe copy was discussed in bug 1382111 I think
11:14johannh(although I didn't explicitly check that it's the same copy as they agreed to)
11:14firebothttps://bugzil.la/1382111 FIXED, jsavory@mozilla.com UX improvement for permission prompt to allow extracting HTML5 Canvas data
11:14johannhflod ^
11:14flodchecking
11:16flodjohannh: the tooltip is not there :-\
11:16johannhoh, the tooltip, well
11:17johannhI actually noticed that but didn't think it looked particularly out of place considering it's "just a tooltip"
11:18johannhflod: feel free to flag it though
11:18flodit's really hard to miss when you look at the larger picture https://hg.mozilla.org/mozilla-central/rev/0a482229bed6#l3.9
11:18flodthanks for the info, NI her in the bug
11:37daleharveyhrm, whats the easiest way to test RTL? seems the forcertl plugin no longer works
11:46daleharveysetting intl.uidirection to 1 seems to have done the trick :)
11:48johannhflod: right, but those are not gonna be displayed in a row of text, in fact it's quite unlikely that even two permission icons appear next to each other
13:52Gijsdao: what are my odds on a review for bug 1402368 before I go away? :)
13:52firebotBug https://bugzil.la/1402368 is not accessible
13:52Gijsit's only a small patch ;)
13:52daowhen are you leaving?
13:52Gijsdao: end of tomorrow
13:52daoI'll try to get it done before that
13:52Gijsbut it's literally a 3-line affair that you already previously reviewed :)
13:53Gijscool, thanks!
14:14johannhMattN: thanks for getting the volunteers! are you filling the new contributors list or would you like me to do that?
14:14MattNjohannh: You're welcome. I am not
14:14johannhok, I'll look through it
14:49johannhmconley: oh, right, I forgot, new contributors get descriptions of what they did
14:50johannhmconley: thanks for taking care of that!
14:50mconleyjohannh: np - happy to. :)
15:08Gijsmikedeboer: are you in the fx-desktop meeting?
15:09mikedeboerGijs: not yet
15:09Gijsmikedeboer: if so, could you handle the structure section? I've added notes, but I'm in a caf and about to travel home, so I won't be able to read them. :)
15:09mikedeboerGijs: ok on it
15:09Gijsah, then it can be a readonly update, I guess ( ^^ johannh )
15:09Gijsok, or that :)
15:09Gijssorry to drop you in it!
15:09johannhok :)
15:11Gijsjkt: https://bugzilla.mozilla.org/show_bug.cgi?id=1384657
15:11firebotBug 1384657 NEW, tihuang@mozilla.com Pocket doesn't work with privacy.firstparty.isolate set to true
16:02Gijsmikedeboer: you joining us for the photon meeting? :)
16:03mikedeboerGijs: ye
16:03mikedeboers
16:34dolskejaws: I think you have the wrong bug # listed
16:35jawsdolske: ah in fact i do, will fix it
16:35jawsfixed
16:40Gijspun failing :(
16:54sfostermikedeboer: are you going to pick bug 1402845 back up, or should I?
16:54firebothttps://bugzil.la/1402845 NEW, nobody@mozilla.org When uBlock Origin button is put in the overflow menu, uBlock panel is shown with wrong size and wit
16:54sfosteror, is there any other higher priority backlog I should tackle?
17:13mikedeboersfoster: well, if you're free to work on it, please!
17:13mikedeboer:)
17:13sfosterok will do
18:09jawsGijs: are you still around?
18:26Gijsjaws: not right now, back in 1.5h
18:26Gijs_awayjaws: otherwise email/bugzilla?
18:26jawsGijs: okay
18:26jawsGijs_away: just curious if you could respond to the needinfo at https://bugzilla.mozilla.org/show_bug.cgi?id=1391616#c7
18:26firebotBug 1391616 FIXED, gijskruitbosch+bugs@gmail.com Migration from hamburger panel to overflow panel doesn't actually work
18:53rhelmerack initial hg clone is so slow on this connection... is there a way to resume the clone if it is interrupted? or maybe a full repo I can download as tarball or something? I know hg.m.o can download just the checkout of a particular rev but that's not quite enough
18:55Mossoprhelmer: You could download a bundle from https://hg.cdn.mozilla.net/ and unbundle that then update
18:55rhelmerMossop: oh cool thanks will look into it rn
18:56rhelmersetting up a new laptop, contributing to mozilla is hard :)
18:57Kwanhg clone should be doing that behind the scenes anyway these days, I think, though I don't know how it handles bundle download being interrupted
18:57rhelmeryeah I see that it's downloading the zstd-compressed bundle, so I am using wget instead... hopefully --resume will do the right thing
18:57rhelmerI got everything set up yesterday/overnight except that timed out at some point apparently :/
18:57rhelmer(that == hg clone)
18:58Kwanguessing it doesn't handle it well then
18:59MossopIt doesn't handle resuming at all I think
18:59rhelmerjust seems to hang indefinitely
19:01rhelmerhrm well downloading this bundle is going to take hours... I guess I'll download the tip of mozilla-central from hg.m.o and start using that in the meantime, painful though.
19:11mythmonrhelmer: hg robust checkout might be helpful, if you could get it working. shield uses that for our homegrown CI
19:12rhelmermythmon: oh cool... yeah speaking of which I was looking at your homegrown CI... for this study add-on I am working on I decided to just develop it in a mozilla-central clone, so I can write xpcshell/mochtest and use try and whatnot...
19:13rhelmerit's really painful to develop things out of the tree that you want to be able to throw up on try etc.
19:13mythmonindeed
19:13rhelmerin my case I hooked it up in the build as if it was a built-in add-on (./browser/extensions/) even though it's probably not going to ship with firefox (it may ship in a funnelcake though)
19:14rhelmerit'd be nice if I could point mach at a directory outside of the tree, and have it automatically load the add-on in the dir and run the tests in the dir etc.
19:14rhelmermythmon: I know you had to deal with all this integration stuff like maintaining jar.mn and moz.build out of the tree and so on. it's hard :P
19:15mythmonour code lives out of tree, but all our tests run by doing what you're describing
19:15mythmonso we kind of do both
19:15rhelmerdo you still use a script which copies your stuff into the m-c tree?
19:15mythmonyeah
19:16rhelmerI'd like to not have the build step, but still keep the add-on in a separate repo, ideally
19:16rhelmerI am just going to hack on it inside the hg clone to avoid it, for now
19:16mythmonit is very similar to the script we use to build the xpi, but instead of zipping it copies to the target dir
19:16rhelmermakes sense
19:19MattNFWIW, `mach mochitest` has an `--install-extension` option that perhaps could be used for installing an add-on for your add-on tests
19:20mythmonMattN: would that be able to run tests that are part of the add-on?
19:20rhelmerthat does sound useful, thanks! depends on how it installs it...
19:20MattNyeah, it was able to install a legacy extension for me today
19:21MattNmythmon: if they are mochitest that are part of mozilla-central then I think it would work
19:21mythmonMattN: "that are pard of the add-on"
19:22Gijs_awayjaws: thanks for forwarding, I'll reply
19:22MattNthat's ambiguous but if if you mean part of a separate add-on repo then I think you would have to have a moz.build in m-c reference it in a subdir.
19:22rhelmeryeah, that's exactly what I have... github repo w/ a moz.build and jar.mn etc.
19:23rhelmeroh, so you'd need a moz.build in m-c for it too? that's a little annoying but ok
19:24MattNmaybe? Not sure if mach can look for tests outside of an m-c clone
19:24rhelmerhm do we have docs or scripts etc. for how funnelcake repacks actually work? I wonder if we could just do this as a built-in system add-on, or if it needs to be a distribution add-on where it gets installed into the profile on first-run... I'd like to just set my tree up like the latter
19:24MattNbut perhaps we could have a moz.build rule that adds any subdirectory of some directory to the build system
19:24rhelmerMattN: yeah, that's the kind of feature that would be handy but probably doesn't exist now, which is fine... I see people working around it in all kinds of creative ways which'd be nice to avoid
19:25rhelmercommon pattern seems to be to download firefox and run it headless w/ selenium, and use more standard/modern tools than mochitest
19:25rhelmerlike on travis or circleCI or such
19:25mythmonselenium to test add-ons is pretty painful in my experience
19:25rhelmerbut I'd like to be able to just use the moz infra for my CI, even if I am using github (have it to a tryserver or custom taskcluster job etc when PR is opened)
19:25MattNe.g. DIRS += ['**']
19:26rhelmerhuh interesting
19:26MattN(perhaps that just works now)
19:27MattNeven if you just have to add `DIRS += ['myextension']` to a moz.build it at least saves having a build step to copy files
19:27rhelmerwhat I'd really like is to have a tiny github repo with just my add-on, and when people open PRs they get a tryserver run (and a build artifact etc they can download) with the add-on bundled in it
19:27rhelmerso for the moment I'll just have a giant m-c repo instead of a tiny github repo, but I can get what I want otherwise
19:27MattNyou know about https://github.com/mozilla/example-addon-repo , right?
19:27rhelmeryeah I do
19:28rhelmerbits currently missing are "integration w/ m-c" :)
19:28rhelmerbut yeah it's a good starting point. just a lot of work, I am pretty busy actually coding this thing heh
19:28zombierhelmer: can you put your addon in m-c (including tests, build config and all), but also as a github repo that you can update more often?
19:29rhelmerzombie: that's exactly what I am doing in the meantime
19:29mythmonzombie: that's what shield does, too.
19:29zombieah, well ;)
19:31rhelmerMattN: I'll see if I can get the example-addon-repo to be more like what I am imagining... I think we could make it really simple
19:31zombieso the addons are in m-c, and tests run as usual on try, and you sync from github to m-c every week or two?
19:31mythmonzombie: but we also want CI runs on Github for every PR
19:32mythmonfor that Shield runs some hacky taskcluster jobs that clone m-c, copy in our add-on, build firefox, and run the tests. duplicating a lot of work
19:32zombienod
19:32mythmonrhelmer has looked into making PRs trigger Try builds, but I don't think he got anywhere
19:33rhelmeryeah, I really just want to be able to push to try, without having a whole m-c clone, or having to write a bunch of test infra code
19:34rhelmereven if mach did something as dumb as "take the tip of m-c, copy the contents of this github repo to ./browser/extensions, then run build + test as normal" it'd be an improvement imho
19:35dmoserhelmer: so AS does this with a project branch which we use as an auto-try server that runs after merge on github
19:35dmoserhelmer: it's not wonderful, but it's something. and it gets us stuff like talos data.
19:35rhelmerdmose: interesting, thanks
19:35rhelmerdmose: would be nice if we all could share more :)
19:35mythmonrhelmer: how would you get mach if you don't have an m-c checkout?
19:35dmoseyeah, so i believe someone on sphilp's team is working on addressing the simple case
19:36dmoserhelmer: ^
19:36* dmose goes to look at his email archive
19:36rhelmermythmon: all I care is that tryserver has one, and I have one locally, github doesn't need an m-c checkout/clone is my point
19:36mythmonah
19:36rhelmerso someone else can clone my repo, test it locally w/ about:debugging etc, and then push a PR and get the benefit w/o the pain
19:37dmoserhelmer: i just forwarded you a thread
19:37rhelmerdmose: thanks!
19:38dmosethe thread sort of died, likely because everyone got busy
19:38_6a68What's the bug for flash of unstyled content on nightly? I'm seeing it again
19:38dmosebut it should probably be resurrected. or something.
19:38dmose_6a68: on web pages or about:newtab/about:home ?
19:39_6a68dmose: on web pages
19:39dmosethat one i don't know, unforch
19:39_6a68no worries :-)
19:41rhelmerdmose: yeah. I think we could do a lot more to support out-of-tree development in a way that integrates more seamlessly... there's just no way we're going to force everyone to have an m-c clone, as evidenced by the history of backflipping people will do to get out of it
19:41dmoserhelmer: give that the open source world lives on github, there's a very deep pool of contributors to attract new ones from
19:41dmoseaka HELLZ YEAH!
19:42_6a68dmose: would core::layout be the right component to file a bug? I'm not sure
19:42rhelmerI think the right way to fix it is for mach to understand this model better, and for us to support more modern testing tools in-tree... I don't want to try to re-create the world outside of our infra, since there are lots of benefits too (and we're going to have to maintain it for a long time in an case)
19:42dmose_6a68: sounds reasonable to me. you could also ask in #content
19:42dmoseor #layout, actually
19:42_6a68cool, thank you
19:43dmoserhelmer: i totally think the two things you propose are a fine idea, i suspect more may be necessary as well.
19:44rhelmeroh I'm sure... I am hyperfocused on my use case, as I sit here cloning m-c :)
19:44dmosebut there is a lot of win to living on modern infrastructure rather even if it means some pain in letting go of the past
19:44zombierhelmer: you seem to be in a perfect position to at least document the current best practices :P
19:45mythmon_6a68: I'm interested in that FOUC bug
19:45rhelmerdmose: eh I think that's a misnomer... taskcluster et al are modern too. mochitest, not so much, but we have so much existing test code I suspect we'd want to add support for more, not necessarily switch
19:45_6a68mythmon: hi! I'm seeing a really ugly FOUC on github pull request pages today, for example, https://github.com/mozilla-services/screenshots/pull/3614
19:45dmosetrue, i'm not really speaking about task cluster
19:45_6a68mythmon: I'm seeing a CSP error on that page, I wonder if that might be causing a race somewhere
19:45mythmon_6a68: by "interested" i mean I'm also seeing the same stuff, mostly on Github as well. Not that I can help sadly
19:46_6a68oh, no worries :-)
19:46dmoserhelmer: and you're right that trying to do a big switch away from the test code soudns like a plan doomed to failure
19:46rhelmerdmose: my point is that we have infra that can spit out firefox builds, so if you want to get your stuff into a firefox build we should make that doable
19:46_6a68I thought maybe you were dabbling in, uh, core layout stuff...
19:46mythmonthat's a bit... beyond me
19:46_6a68mythmon: I'll ping you when I figure out whether to pile onto an existing bug or file a new one
19:46mythmonthanks
19:46_6a68np!
19:46dmoserhelmer: that said, deprecating old test harnesses for new tests at least gets on a good trajectory
19:47Gijsmythmon: Osmose: heads-up that I'm out on PTO starting end of tomorrow
19:47mythmonGijs: thanks. Though Osmose isn't working on Shield anymore, as of today.
19:47Gijsoh?
19:47mythmonhe's moved over to Socorro
19:47dmoserhelmer: zombie: i suspect that catching up with davehunt and/or sphilp would be a good first step. a bunch of us, including mythmon and i think jlaster from devtools had a meeting with him which is where that email thread came from.
19:47Gijsaha :)
19:48Gijsmythmon: looking at the review you assigned me now, but that'll be the last one until I get back (in November), unfortunately...
19:48rhelmerdmose: nice. yeah devtools folks are in the same boat, I suspect they'll help push this forward
19:48GijsI noticed you got some other fx peers involved, so I assume you'll be OK?
19:48mythmonGijs: I think we'll be fine. My fallback is generally rhelmer
19:48Gijsyepyep
19:48mythmonrhelmer: are you ok with picking up some more shield reviews?
19:48rhelmermythmon: sure
19:49mythmonthanks!
19:49Gijsmythmon: "the bug we had with Screenshots" - which one? :)
19:49rhelmerI will spread around the ones I am not comfortable reviewing... as usual :P
19:49mythmonGijs: let me go find the post mortem
19:49sphilpdmose: rhelmer whoa backscroll :P yeah dave hunt can update you in a bit more detail (he's at a conf this week tho), we stopped the project for now as there were several dependencies to work through, but it's a common enough case that we do need to find a solution and have some plans
19:49rhelmersphilp: nice
19:50rhelmersphilp: from my pov what I'd like is a way to treat moz infra (from github PRs or wherever) as if it were a testing service that ran a headless firefox on my code + tests... where my code could be an add-on or a webpage etc
19:50dmosesphilp: good deal
19:53rhelmerdmose: that email you forwarded looks promising, thanks!
19:53dmosesphilp: i like rhelmer's framing here a lot, my gut is that that's just the right way to look at it
19:53mythmonGijs: https://mail.mozilla.org/pipermail/dev-shield/2017-September/000302.html (there also some issues in the github issue that the PR fixed)
19:54rhelmerdmose: I think modernizing the test harnesses is important too but separable... iirc bgrins was looking into this not too long ago
19:55dmosein particular, the framing was referring to liking a lot is "treat moz infra (from github PRs or wherever) as if it were a testing service that ran a headless firefox on my code + tests... where my code could be an add-on or a webpage etc is "
19:55rhelmerI can't imagine how much work it'd be to onboard someone to work on this add-on with me... it's using xpcshell and mochitest and requires an m-c clone and build, etc. basically would need to be a firefox dev already
19:55rhelmerjust the add-on dev part is hard enough!
19:56dmoseshilp: rhelmer: in other words, if we could have a github integration that worked like travis-ci
19:56rhelmeryeah. I don't really want to have to configure anything except auth, to get a usable result
19:56dmoserhelmer: devtools does it, they have lots of contribs, i understand. part of it is avoiding the mozilla test stack except when truly necessary.
19:57dmoserhelmer: i.e. use web standard tooling for as much as is practical
19:57rhelmeryeah.
19:57rhelmermoving to an add-on helps with shipping but not with dev at all right now, in my experience...
19:58rhelmereither you continue working out of m-c (which is fine, for us :) ) or you do a bunch of custom CI work, which seems like a waste
19:58dmoseyeah, depends a lot on what you're working on
19:58dmosebut if you use tooling that everyone already knows/understands (eg React/mocha/chai/webdriver)....
19:58dmosefor the dev work itself
19:58dmoseassimilating is much less work
19:59dmoseand that's well documented on the web at large, including stack overflow
19:59rhelmerright, but it takes on a ton of debt having to maintain some wacky circleCI or travis or taskcluster setup
19:59rhelmerall of these seem like reasons we should be able to use these tools in m-c anyway
19:59dmosemaintaining a travis setup isn't very hard
20:00rhelmerwell it's more the config is brittle
20:00dmosemuch less work than trying to debug mochitests
20:00rhelmerhah
20:00dmosemy feeling is that the pain saved by doing everything with web tools outweighs the pain of having to handle travis quite substantially
20:01dmosethat said, i totally agree that being able have the m-c test stack Just Work as a github integration would be huge
20:03zombieoh example-addon-repository doesn't actually use travis
20:03zombiewhy did i thought it did
20:03_6a68mythmon: filed as bug 1407401
20:04firebothttps://bugzil.la/1407401 NEW, nobody@mozilla.org Hard refresh causing severe flash of unstyled content
20:04zombiedmose: does any of our addons use travis currently?
20:05dmosezombie: activity stream
20:05dmoseprobably others too
20:05mythmon_6a68: thanks
20:05_6a68
20:06zombieright, i conflated.. thanks
20:06rhelmerzombie: yeah, errbody does it differently, which it'd be nice to get ahead of ...
20:07dmoserhelmer: ITYM "catch up with" :-)
20:07rhelmerlulz
20:15Gijsmythmon: so I'm looking at this patch and I'm confused
20:15Gijsmythmon: what calls PreferenceExperiments.start() ?
20:15GijsI can't find any callers in the tree...
20:15mythmonGijs: that's exposed via the driver to shield actions, which aren't in tree
20:15Gijsoh-kay
20:16Gijsmythmon: so the fundamental thing I don't get is, you're not touching start(), which is the only other place (besides stop, which only reads it) which sets the previous pref value
20:16mythmonhttps://github.com/mozilla/normandy/blob/master/recipe-server/client/actions/preference-experiment/index.js#L57-L64
20:16Gijsmythmon: we write to previousPreferenceTHingy before calling startup(), so that's before any recipes or (therefore) shield actions run.
20:17Gijsmythmon: so... how would this work? Don't the pref actions just overwrite the previous pref value?
20:18mythmonrecipes from the server only start or stop experiments. they won't update the previousValue each time
20:19mythmoni'm not quite sure i understand where you're getting stuck though
20:19Gijssfoster: wrong bug number in https://bugzilla.mozilla.org/show_bug.cgi?id=1402845#c12 ?
20:19firebotBug 1402845 ASSIGNED, sfoster@mozilla.com When uBlock Origin button is put in the overflow menu, uBlock panel is shown with wrong size and wit
20:20Gijsmythmon: start sets the experiment object to: previousPreferenceValue: getPref(preferences, preferenceName, preferenceType, undefined),
20:20Gijsmythmon: and then stores that
20:20Gijswouldn't that overwrite whatever we set it to in startup?
20:21mythmonit shouldn't, because when PreferenceExperiment.start() gets called, it should be creating a experiment, not modifying an existing one (in fact, it errors out if there is a duplicate experiment)
20:21mythmonthen bootstrap.startup() is intentended to run on the *next* time firefox starts, to keep the preferences in sync with that experiment
20:22mythmonGijs: and the writes to previousValue in bootstrap.startup() only read from preferences that have been created with calls to PreferenceExperiments.start()
20:22Gijsmythmon: hrm.
20:22mythmoner, only read from *experiments*
20:24Gijsmythmon: OK, that makes more sense to me. Thanks for clarifying!
20:24mythmonGijs: this PR may provide some h elpful context as well https://github.com/mozilla/normandy/pull/1024
20:25Gijsmythmon: did you have a link to that postmortem in the end? :)
20:25mythmonGijs: i didn't find what i was looking for, but there are more details here: https://mail.mozilla.org/pipermail/dev-shield/2017-September/000302.html
20:30Gijsthanks, that's helpful
20:38sfosterGijs: ah yeah I moved the wrong dependent
20:38sfosterthanks
20:40sfosterer. Wrong wongness. I'll fix it :)
11 Oct 2017
No messages
   
Last message: 6 days and 17 hours ago