mozilla :: #fx-team

18 Apr 2017
01:40jawssquib: i think we should change the pref name to toolkit.essential-animations-only=true after today's meeting where the terms essential/non-essential seemed to make the most sense when talking about them. also flipping the pref name so it is in the in affirmative instead of a negative
01:40jawsor use camel case
01:40jawsbut either way i like that naming better
01:41Caspy7jryans: might be nice if once search is enabled that it would be focused by default
04:09dietrichshutdown on nightly with lots of tabs got better in the last week or so, it feels like to me. any ideas of recent landings which might have impacted that?
04:40squibjaws: I'd prefer to avoid creating another pref that's got inverted logic; 'true' should mean 'enabled'
04:40jawssquib: fair enough, what do you think about toolkit.non-essential-animations=true ?
04:40jawsagain, camelCase if you prefer
04:41squibjaws: i don't think "essential" is quite the right word...
04:42jawsthere was another term that was used
04:42jawstrying to remember it...
04:42squibjaws: it really depends on what we want to indicate with the pref (bearing in mind that the name isn't *that* important since it'll have UI)
04:43squibjaws: do we have a "performance" pref branch anywhere?
04:43squibhm, looks like no
04:43squibhow about "toolkit.expensiveAnimations.enabled"?
04:43jawssame answer
04:43jawshah i would vote no
04:44jawsonly because what it implies
04:44jawsour animations shouldn't be expensive per-se
04:44jawssome people may be disabling them due to a11y, remote access, etc
04:44jawsyou can stay with what you've got. cosmetic
04:45squiba part of me is tempted to make the pref an int
04:45squiblike toolkit.animations.maxCost
04:46squibbut that opens a huge can of worms as to how we annotate the "cost" of an animation
04:47jawsyeah, go for simple now
04:47jawsif we want to do that later we can at that point
04:47squibwe could also go "toolkit.animations.cosmetic.enabled" so that we could add other animation types later
04:47squibe.g. "essential" or whatever we'd call it
08:18JuPanameyou need shell account for free ? contact me =)
08:22jlazbanned the user above, sorry about that
08:56makthe new machine looks good, clobber moved from 55mins to 18mins (Win10) \o/
09:38johannhwe should really make a BrowserTestUtils function that returns a promise when an observer was called
09:40johannhI have troubles finding a test that does _not_ use this pattern
09:43makjohannh: TestUtils.topicObserved ?
09:44makfixed :D
09:44johannhmak: oh! :D
09:45* johannh didn't even know there's "TestUtils"
09:45johannhas apparently a number of other people
09:46johannhmak: thanks!
09:46makyes, I think it wasn't advertized enough
09:46makmaybe it's a good point for the next desktop meeting
09:46* johannh scribbles it down for the next meeting
11:15Gijsmikedeboer: do you think you'll have a chance to look at my changes in bug 1354095 today? :)
11:15firebot ASSIGNED, Add 'New Window' and 'New Private Window' buttons to static hamburger menu
11:16* Gijs is building on them in bug 1354071
11:16firebot ASSIGNED, Switch overflow panel to using a panelmultiview
11:32mikedeboerGijs: yeah, but on sick pto though
11:32Gijsmikedeboer: oh no!
11:32Gijsmikedeboer: don't do reviews if you're sick, I can wait :)
11:33mikedeboerwill see...
15:19ddurstmconley: ping
15:20mconleyddurst: pong
15:20ddurstdothayer's on PTO today, but I think bug 1344003 is background hung (pun intended)...
15:20firebot NEW, Create (or resurrect) BHR dashboard
15:20mconleyddurst: do you know on what?
15:20ddurstMeaning, the request for the Profiler expanded to the API, and the Updater UI spawned some bugs
15:21* ddurst looks at others, standby
15:21mconleyah, so I've unwittingly overloaded dothayer?
15:21ddurstwe could swap Profiler with BHR?
15:21* ddurst in terms of priority
15:21ddurst^ not really, the Profiler scope crept
15:22ddurstlet's do that
15:22mconleyhold up
15:22ddurstit's hard to choose
15:22mconleyddurst: both are pretty important in terms of giving us actionable data to do perf analysis and getting bugs filed, which is of pretty significant importance at this stage of the game
15:23mconleyddurst: I wonder if the BHR stuff, at its current state, could be handed off to somebody to drive it over the line
15:23mconleyinstead of context-swapping dothayer's out of the Profiler work, which is also pretty important.
15:23mconleybsmedberg: ^--
15:23mconleyddurst: but just so I'm clear, BHR visualization is really only blocked on dothayer having gotten bogged down with creep in other projects?
15:24ddurst#c37 looks like it could be easy for doug to do the first half and someone else to do the airflow
15:24bsmedbergmconley, are you worried about visualization or about the processing/derived datasets/aggregation?
15:24* bsmedberg will totall hand visualization to other people
15:24bsmedbergprocessing sounds harder to hand off
15:24mconleybsmedberg: if I understand, dothayer's work kinda does both
15:24mconleyhe's got an airflow script or something that does the job of slurping the data out of BHR
15:25mconleyer, Telemetry I should say
15:25* mconley reads patches quickly
15:25mconley^-- this seems to be the guts of it
15:27mconleybsmedberg: seems like dothayer's got work for both halves of the problem - slurping the stacks (and symbolicating the native ones!) out of the BHR data in Telemetry, which then stashes the results out on S3 somewhere
15:27mconleyand then an HTML page to visualize that stuff that got slurped
15:28mconleyddurst: so I guess it's not clear to me in bug 1344003 what's left to do. Looks like dothayer was trying to figure out how to get his scripts put into the Airflow pipeline
15:28mconleybut from a quick glance here, it _seems_ like his scripts are feature complete
15:29ddurstTop priority is the Flash study work, but I'll ask him finish this off next.
15:29ddurst(tomorrow, however)
15:30mconleyddurst: alright, sounds good to me.
15:30ddurstsorry for the backup
15:34mconleyddurst: not a problem
16:02Gijsadw: meeting ping? We're in PhotonProgram
16:02adwGijs: i'm in another meeting
16:49sfosterjaws: the test-skipping stuff I added to the toolbariconcolor_restyles test is still letting win8 x64 through and failing that test.
16:49sfosterit does (AppConstants.platform == "win" && AppConstants.version == 8) { ok(true); return }
16:49jawssfoster: i don't think win8 reports itself as version==8
16:49jawssfoster: should be 6.2 iirc
16:49sfosterI guessed something like that must be going on.
16:50sfoster6.2? naturally :)
16:50jawssfoster: see for an example
16:50jawssfoster: vista was 6.1
16:51jawsi mean... win7 was 6.1
16:51jawswin vista was 6
16:51jawssomething like that, i'm sure wikipedia has it right
16:53sfosterso maybe >= 6.2 works for now?
17:16jawssfoster: no, >= 6.2 will disable the test for windows 10 where i thought it was passing?
17:16jawssquib: i left a comment on your pref bug
17:16sfosterjaws: I thought we didn't have win10 in automation yet?
17:17sfosterregardless, I saw the test was failing on osx this time too, so back to the drawing board.
17:18jawsi think win10 is coming but i couldn't find it in my browsing history
17:19squibjaws: should i use Preferences.set too?
17:19jawssquib: yeah
17:23squibjaws: this is maybe a pathological error, but should i have any special handling for if the user set one of these prefs to something other than a bool? if they did, then i'd be setting the new pref to something non-bool and things would break
17:23squibe.g. if the user set browser.tabs.animate to 1, we might set toolkit.cosmeticAnimations.enabled to 1 as well
17:23jawssquib: these prefs are all defined in all.js/firefox.js? i don't know how to change the type if they're defined in those files
17:25squibjaws: well, it's really pathological because you'd have to do it in your profile's prefs.js (and we can't enforce the type during this migration, since we removed the default pref values from firefox.js
17:25squibbut i should just convert the value to bool to be safe
17:25jawssquib: well when we call setBoolPref we can always do !!value
17:25RyanVMjaws: win10 on taskcluster is in testing right now, not sure on an ETA for going fully into production though
17:25jawssfoster: ^
17:25RyanVMbut soon enough that I'd concern myself with that possibility for test disabling :)
17:26squibjaws: yeah i could either use setBoolPref or Preferences.set(..., !!value);
17:26squibjaws: not sure which is better
17:26jawssquib: also, did you see f'lorian's comment on your bug about setBoolPref with a default value?
17:26sfosterjaws: I'm hoping I can remove that skip clause entirely. If this is failing on osx too I think I can't just punt on it.
17:26squibjaws: which is the new hotness?
17:27squibare we planning on moving to Preferences.jsm?
17:27jawsidk, Preferences.jsm is easier to use imo but it requires loading the extra JSM
17:27jawssfoster: but then are we saying we don't think the patch is actually fixing the bug
17:27squibit's already there though
17:28squibi think i'll just use Services.prefs because the type info is safer that way
17:28jawssquib: from where?
17:28squibjaws: in `currentUIVersion < 41`, we import Preferences
17:28sfosterjaws: no I&#39;m saying the test does in fact have a problem which I need to address before we can land this. Its a race condition with focusing/activating windows and measuring elementsStyled
17:28squibso i could move that up
17:28squibbut Services.prefs is probably easier
17:29jawssquib: migrating from 42 -> 44 wouldn&#39;t import that jsm
17:29squibjaws: right
17:30jawssquib: well, i don&#39;t want to do spin too much on this, feel free to use Services.prefs :)
17:32jawssfoster / squib: meeting ping, we&#39;re in PhotonProgram
17:32squibjaws: joining
17:42florianjaws: I&#39;m not convinced the minor convenience that Preferences.jsm brings is worth the overhead it adds. Especially on the startup path.
17:42jawsflorian: i agree
17:43jawsflorian: however the <41 branch already loads it. we could change that though
17:43florianyeah :)
17:44florianand there&#39;s another use of Preferences.jsm in nsBrowserGlue.js, related to
17:44florianthat was to avoid needing to use getComplexValue to read an unicode string, but that can now be replaced with getStringPref
17:44florianit&#39;s not in the startup path though
17:45MossopThe add-ons manager uses Preferences.jsm so it&#39;s already in early startup
17:46jawssfoster: hey, are you waiting on me for the panel open/close bug?
17:46florianMossop: it&#39;s even setting _two_ lazy getters for it!
17:46sfosterjaws: no I think I ni?d dao
17:47Mossopflorian: Yeah I just spotted that too
17:47sfosterjaws: but if you have feedback too, or feedback on their feedback, please add it.
17:47jawssfoster: no, you have me flagged for review
17:47florianMossop: and it looks like it&#39;s using it just to have support for default values on bool prefs
17:47jawsyes, there are needinfos but i&#39;m flagged for review
17:47jawssfoster: ^
17:47sfosterjaws: yeah I was looking for feedback on the approach before I take this further.
17:48florianI wonder if there&#39;s an easy way to spot (using a script) Preferences.jsm being used only for something that the prefs API now supports
17:48jawsokay cool i&#39;ll take a closer look at it
17:48sfosterso yes, I guess I am waiting.
17:48jawsokay sorry
17:48sfosternp, still trying to land this other bug and get it off my plate
17:48sfosterso its not actively blocking me
18:12Gijsflorian: have we considered removing Preferences.jsm ?
18:13Gijsflorian: I don&#39;t really see a use over Services.prefs.* anymore, and it&#39;s an extra jsm which is something we&#39;re trying to cut down (esp. in the content process)
18:18florianGijs: I would love to :)
18:34Gijsflorian: filed a bug yet? :)
18:57felipeGijs: has there been any thoughts thrown around about doing a profile clean-up/Firefox-to-Firefox migration, as part of the 57 release?
19:17aswanfelipe: there is this mysterious bug
19:17firebotBug 1334662 NEW, When a Photon-based Firefox starts up for the first time, it should tidy up existing profile data
19:18felipeaswan: thanks for the pointer!
19:18aswanno problem...
19:20Gijsfelipe: sorry, was away. Yeah, thoughts... not sure what the latest concrete plans are.
19:20Gijsfelipe: there was a photon-dev mailing list thread after I emailed some folks with some concerns about doing an automated clean-up
19:21Gijsbut that petered out without anything I really understood as a firm conclusion/plan
19:21GijsI think we&#39;ll get a lot of that thing for free by just disabling all the non-webextension extensions
19:22Gijswhen people talk about the clean-up it&#39;s usually not clear to me what kind of things they want &quot;cleaned up&quot; besides &quot;everything the user doesn&#39;t really need&quot; which isn&#39;t a very implementation-friendly description :)
19:22Gijsfelipe: if you have concrete thoughts about this that might be helpful.
19:22Gijsfelipe: was there a particular thing you noticed that prompted you to ask?
19:26felipeGijs: no, just something that occurred to me last week
19:33MossopI&#39;m worried about such plans costing us startup time when we want 57 to be shiny and fast
19:35andymcleaning up non-webextensions will really help some users, but most users won&#39;t notice i difference
19:36andymbased on the fact that most users don&#39;t have non-webextensions (or at least thats the hope by 57)
19:36felipeI was thinking like something that doesn&#39;t occur right on startup, but that would clean up profiles to make 57 run faster in general
19:36felipethe kind of things that can slow down the browser but doesn&#39;t get caught by our tests running with clean profiles
19:37felipelike large history, too many cookies
19:52florianGijs: just filed bug 1357517
19:52firebot NEW, Consider removing Preferences.jsm
19:52florianbut I&#39;m not convinced the overhead is big enough to justify making that block photon-performance
20:13dolskemconley: window.find? lolwat
20:13mconleydolske: yeah, the first time I heard about that API was when I got needinfo&#39;d on that bug. :)
20:14Mossopfelipe: I tested your bug, couldn&#39;t reproduce
20:14jryansis there an API that can force a prefs file flush, so i can set a pref and then restart the browser?
20:16dolskejryans: Services.prefs.savePrefFile(null)
20:16jryansdolske: haha, i just noticed that, thanks!
20:21felipeMossop: thanks!
20:53jryansis there any content process side API (from chrome JS) that enumerates content windows in that process? i can look up a single window by outer window ID assuming i have that ID already, but hoping for something that just lists them for me...
22:12mccr8it has an enumerator thing.
19 Apr 2017
No messages
Last message: 154 days and 13 hours ago