mozilla :: #devtools

12 Jul 2017
07:41HonzaWhat API for prefs (in tests) should we use? (a) `Preferences.set("devtools.cache.disabled", false);` or (b) `Services.prefs.setBoolPref("devtools.cache.disabled", false);`
07:45jdescottesHonza: I would say pushPref from shared-head
07:45jdescottesit relies on SpecialPowers.pushPrefEnv which will make sure the pref is restored to its original value in the cleanuo
07:45jdescottes*cleanup
07:46Honzajdescottes: ok, sounds good, thanks
09:24pbrozer0: I know it's not clear yet what the issue is, but we really need to address https://bugzilla.mozilla.org/show_bug.cgi?id=1373994 and since you said it might be a platform issue, could you please needinfo someone you think can help on this asap?
09:24firebotBug 1373994 REOPENED, nobody@mozilla.org Element Picker unusable in Firefox 54 - It's dark and elements can't be selected
09:28zer0pbro: my bad, I pinged brad last friday but he replied just this week, I still have to got into details with him; I'll send to him an email to ensure we don't miss each other this time.
09:29zer0pbro: I could have try to talk with him yesterday but it slipped out my mind.
09:29pbrosure .Thanks
09:30pbroI've tried downloading a few differnet versions of Firefox release, and disabling some prefs ... still can't figure out when this started and who
09:30pbrowhy
09:31pbroit's really 54 thing. I've tried 53.0b10, no problem. But with 54.0, the problem occurs
09:32zer0pbro: thanks for these tests. I'll add the info to the email to brad
09:57ochameaumikeratcliffe: hi, you around ?
10:05pbrozer0: I downloaded some nightlies of 54 too, and the problem does not reproduce. So it's really something with release (maybe beta too, haven't tested yet). There are channel-dependent flags in the code, so maybe there is something that just works differently between nightly and release. And we don't have tests that check the visual appearance of the
10:05pbrohihglighter
13:16nchevobbedoes anyone has the following error when doing `./mach eslint --setup` : npm ERR! Could not install from "file:tools/lint/eslint/eslint-plugin-spidermonkey-js" as it does not contain a package.json file.
13:16nchevobbeI don't understand what's going on
13:20nchevobbeokay, updating npm fixed the error
13:32allstarschhpbro: ping
13:32pbroallstarschh: pong
13:33allstarschhpbro: thanks for the review for bug 1377523
13:33firebothttps://bugzil.la/1377523 ASSIGNED, allstars.chh@mozilla.com Convert tests within devtools/ to not rely on data: URI inheritance
13:33allstarschhpbro: however I am wondering the license
13:33pbroallstarschh: sure, what are you wondering about?
13:33allstarschhpbro: I thought we already use createcommons, like in bug 1073556
13:34firebothttps://bugzil.la/1073556 NEW, nobody@mozilla.org Mozilla Test Files Public Domain Dedication Registry
13:35pbroallstarschh: oh yeah, you're right, for test code, we should use the public domain license header, as per: https://www.mozilla.org/en-US/MPL/headers/
13:35pbrosorry about that
13:36allstarschhpbro: it's okay, I am not pretty sure either
13:36soleochameau: jdescottes would you be up for talking about go faster before the meeting?
13:37allstarschhpbro: do I have to add license header? I thought we will use publicdomain by default now
13:38pbroallstarschh: what do you mean by default? My understanding is that license headers in all files are a good practice
13:39allstarschhpbro: in comment 0 it said "to state that all test files checked in after a certain date without an explicit license are public domain (CC0)"
13:40allstarschhpbro: so after that policy change there are lots of tests don't have license headers
13:40pbroallstarschh: ok, sounds good to me then. Simpler!
13:41allstarschhpbro: okay, thanks
13:41allstarschhpbro: I'll address your other comments then :)
13:41pbrothanks
13:43jdescottessole: ochameau let's meet at 4pm/3pm your timezone?
13:43solePerfect!
13:57solejdescottes: your room?
13:57soleochameau: ^
13:57jdescottessole: yep my room!
13:58allstarschhpbro: hi
14:06jdescottessole: https://docs.google.com/document/d/15C0_Ug0g1q5gfKEHEJJggZwX1-Wzwdf9ONZUVOd25Uo/edit#heading=h.spowvxxx04ow
14:18pbroallstarschh: yes?
14:19allstarschhpbro: sorry for interrupting you again, https://bugzilla.mozilla.org/show_bug.cgi?id=1377523#c24
14:19firebotBug 1377523 ASSIGNED, allstars.chh@mozilla.com Convert tests within devtools/ to not rely on data: URI inheritance
14:20allstarschhpbro: also I've asked smaug in dom/ directort, he said we don't have specific naming rule for the support-files
14:20pbrono we don't, but having one makes sense I think. We have naming rules in some directories in devtools
14:21pbrojust not in the one where you added those file_...
14:21pbroI was suggesting that you renamed them doc_... instead, and also renamed the other (existing) files to this
14:21pbrothis way we'd have a nicer list of files
14:21allstarschhpbro: okay, I see
14:21allstarschhpbro: thanks
15:00allstarschhpbro: finished the renaming change
15:00pbroallstarschh: nice, thank you
15:00allstarschhpbro: :)
15:19soleclarkbw: jdescottes mind to look at the things I took notes of and see if the places with (?) are correct?
15:20jdescottessure sole !
15:21solethanks! \o/
15:22Honzabgrins: here is the pull request https://github.com/devtools-html/devtools-core/pull/498
15:22bgrinsah ok i was looking at bugzilla
15:22Honzabgrins: ah, okay
15:27jlastHonza - looks good
16:01solepbro: jdescottes ochameau do you mind if I don't attend the product cross functional meeting later? I'm not feeling too well, thinking of going home already
16:01pbrosole: sure.
16:02soleLet me know if there's something I should know tomorrow :)
16:02soleI mean something I should know today but you let me know tomorrow
16:02soleagh seriously I'm useless today
16:13gljryans: do you know if stylo will ride the train and be in 57?
16:14jryansgl: all signs point to yes so far.
16:15jryansgl: why do you ask?
16:16gljryans: just wanted to make sure we consider this for our q3 performance and polish goal
16:50jryansjdescottes: did you work out _why_ bare scripts are loaded into a sandbox?
16:53jdescottesjryans: argh yes I did (by that I mean I tracked down the code that created the sandbox) but I guess I just didn't write it anywhere, let me find it again
17:16jdescottesjryans: so the global scope for addons is created at http://searchfox.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#4191 and it is a sandbox. But reading it again made me wonder... That is only the global object [this], not [window]. Why would window automatically be a sandbox object for an iframe we are loading ourselves. I
17:16jdescottesdidn t think about simply using [window] instead of this, but it looks like it works actually.
17:20jryansjdescottes: aha! that's the scope for bootstrap.js, but not sure if that's also used for resource:// URIs inside the add-on as well... hmm.
17:21jryansjdescottes: but yes, `window` is probably more clear :)
17:22jdescottesI ll update the patch with this, but I guess I am still missing the complete picture about this Sandbox wrapper
13 Jul 2017
No messages
   
Last message: 15 days and 5 hours ago