mozilla :: #fx-team

16 May 2017
06:11nhnt11I feel like hg wip should be cached
06:11nhnt11like, any action that might change the output of `hg wip` should calculate the new value of `hg wip` and cache it
06:11* nhnt11 wonders how hard this might be to implement
06:12nhnt11or if there's a way to get this behavior already
07:15johannhnhnt11: is hg wip slow for you? it's pretty fast most of the time for me
07:15johannhnhnt11: maybe strip some merged refs?
07:15nhnt11johannh: hg wip 1.29s user 0.12s system 98% cpu 1.428 total
07:16nhnt111.29s is a lot
07:17nhnt11johannh: I don't have any strippable refs lingering around :/
07:17johannhnhnt11: oh, well, it's not much faster for me :)
07:17johannhbut it builds up incrementally, creating the illusion of being faster
07:17johannhor at least of progress
07:17nhnt11"builds up incrementally"?
07:17nhnt11you mean it spews output line by line instead of all at once, or something?
07:18nhnt11mine spews out all at once, but that might be because I've aliased it to cut off lines that exceeds the current terminal width instead of wrapping them
10:52Gijsdaleharvey: dao: where are the specs for the location/search bar, especially on OS X? I don't see anything on bug 1352366 or bug 1355386
10:52firebot FIXED, dale Implement new location and search bar appearance
10:52firebot ASSIGNED, shorlander [UX] Need spec for new location and search bar appearance
10:52daleharveyGijs: I am working from
10:53daleharveythere is also
11:00Gijsdaleharvey: hm. I guess the wrong height is covered by 1365213 . The colors of the border also look off to me, but maybe that's because the background of the toolbars is too dark still, given that the borders have alpha?
11:02daleharveyyup @ heights, just checking the patch for that now, the border should be identical on osx at least though (hsla(240, 5%, 5%, .25))
11:02daleharvey(on linux we just use ThreeDShadow so isnt exact
11:06Gijsdaleharvey: sure, but if the toolbar background is different the net visual result is different because of the alpha
11:06daleharveyGijs: ah yeh
11:35Gijspast: so, reviewing your patches on bug 1359056 next... I was confused by your fix. Is the customizing attribute guaranteed to be set by the time openPopup is called?
11:35firebot ASSIGNED, Search panel jumps when hovering the One-off buttons
11:39pastGijs: I can't assert any guarantees, as my familiarity with that code is minimal, but (a) it worked fine in my manual and automatic testing, and (b) even visually inspecting what is happening shows that openPopup is called way after we enter customization mode
11:40pastit took quite a few milliseconds for it to appear
11:41pastthere is other code that is pointlessly running before openPopup, but this was the most minimal patch I could come up with that fixes the issue
11:49Gijspast: hm... ok
11:49* Gijs will play around a bit
11:57Gijsgahhhh, why is nightly so crashy?
12:00pastGijs: it's been stable for me. Anything telling in about:crashes?
12:00Gijspast: local build, so I assume crashes aren't being submitted
12:01Gijscertainly the crash reporter doesn't come up
12:01Gijsjust the OS X one
12:01Gijswhich points to 0 XUL 0x00000001098fd325 JSAutoCompartment::JSAutoCompartment(JSContext*, JSScript*) + 21 (jsscript.h:1191)
12:01pastoh, I've had a few of those a couple of weeks ago
12:02pastbut none with that particular signature
12:03Gijsflorian: why do we still use promise-backend.js now that task.jsm is gone?
12:03Gijsis that Promise.jsm goop or is it what we actually use for 'native' promises?
12:03florianGijs: it's Promise.jsm
12:03florianGijs: I haven't removed these imports yet
12:03Gijsflorian: is there a followup for that?
12:03pastpaolo is working on killing that too
12:04florianGijs: we'll need a few follow-ups.
12:04florianGijs: there are 30 Promise.defer() calls left in browser/ and toolkit/ non-test code
12:04Gijsthat doesn't seem too bad...
12:04florianI was thinking most of that could become mentored bugs
12:05florianonce that's cleared, I'll do a scripted removal of the Promise.jsm imports
12:08Gijspast: so... one thing that your work is pointing me to is that we seem to do too many searches...
12:09Gijsoh, ah, no, I know what this is...
12:09Gijswe rebind the XBL binding because the element gets moved in the DOM
12:09Gijsthe search binding does not like this.
12:10* Gijs wonders if this bug is exposing bigger issues now :(
12:10Gijspast: so the search field is empty in customize mode... I guess we lose the value.
12:10Gijsthere's probably another bug on file about that, though maybe not
12:13Gijspast: so... we re-fetch remote results even if the search term is the same, when you focus and then blur and then refocus the search bar... you can see this in the network monitor
12:13Gijspast: is there a separate bug on this?
12:50pastback from lunch, let me check
12:52pastso bug 1105264 is about losing the search data after customization
12:52firebot NEW, Data from the Search Field is lost when entering Customize Mode
12:53pastand bug 1233289 is about the multiple fetches
12:53firebot UNCONFIRMED, Focusing the searchbar shouldn't refetch suggestions
13:04Gijspast: cool, thanks - r+, anyway, and I'll keep those bugs in mind...
13:05Gijsmikedeboer: so I'm looking at your find patch, and struggling...
13:06mikedeboerstruggling's not good!
13:06Gijsmikedeboer: under what circumstances do we disable the prev/next buttons after that patch?
13:07Gijs(if any)
13:07Gijsmikedeboer: put differently, why aren't we backing out all of bug 935521
13:07firebot FIXED, Findbar Previous/Next buttons don't have an inactive state
13:07mikedeboerwhen the findbar text input is empty, I believe
13:07Gijsmikedeboer: I'm reading the test you're changing in the new patch ( ) and it feels like it should cause all the other tests you added in 935521 to fail
13:08Gijsmikedeboer: and I presume it really doesn't (cause all of those to fail) but I don't understand why :)
13:08mikedeboerGijs: I didn't check that - I'll take a look at the try run
13:09mikedeboerGijs: at this point I was like: let's get to a point where we are as correct as possible and look at the tests later
13:14Gijsah, hm
13:14Gijsmikedeboer: OK, I cleared review - I'm not sure why we can't just revert the non-style changes from the other bug...
14:17RyanVMwoah, changing backgrounds on the location bar when hovering
14:17RyanVMnot the greatest experience with a dark theme
14:54GijsRyanVM: please file a bug and block bug 1352366
14:54firebot FIXED, Implement new location and search bar appearance
14:54RyanVMcan do
14:56RyanVMoh hey, I guess changing color when hovering over isn't supposed to happen at all
14:57RyanVMaha, it's an issue with LWT in general
14:57GijsRyanVM: I think there's a desired box shadow, but I would be surprised if the inside of the location bar would change colour by more than a highlight-y smidge
14:57RyanVMgoes transparent on hover
14:57RyanVMmy dark LWT wasn't showing that as well as some other ones on amo
15:00RyanVMfiled bug 1365275
15:00firebot NEW, Location and search bars become transparent on hover with a lightweight theme installed
17:31jawssfoster: meeting ping? we're in photonprogram
17:53_6a68Is there any reason I wouldn't be able to do an artifact build of beta?
17:54_6a68I'm getting "tried 48 pushheads, no built artifacts found"
17:56aswan_6a68: i think it should work if you apply the one-liner from
17:56_6a68aswan: oh, great! Thanks, didn't even know that was a thing
17:59RyanVMi managed to get my tab bar in a really weird state yesterday, which I had STR to go with it
17:59RyanVMoverlapping tabs and such
18:00_6a68aswan: hmm, it looks like that patch is already applied on beta, but I still can't get an artifact build to work?
18:01aswan_6a68: in that case, i dunno. maybe somebody in #build can help?
18:01_6a68 thanks anyhow
18:22dmoseis there any way to make the various browser/ XPCOM services available to xpcshell?
18:23dmoseit seems that getService doesn't find them, and it'd be unfortunately slow to have to write unit tests using browser-chrome
18:24* dmose wonders if perhaps bsmedberg knows
18:25MattNdmose: You have to add something to the xpcshell.ini file IIRC
18:25dmoseMattN: that's a good type
18:25* dmose pokes around
18:25MattNdmose: firefox-appdir = browser
18:25dmoseMattN: hawt!
18:26MattN(I'm not 100% sure but I think that's all you need)
18:26* dmose finds examples
18:29dmosew00t; works great!
18:37dmoseI justed added the info to the main XPCshell page on MDN
18:40paoloMattN, dmose: see also
18:40firebotBug 1168178 INVALID, xpcshell tests aren't being run with the firefox prefs - prefs in firefox.js don't take effect
18:41paolo(ignore the INVALID thing...)
18:45felipebsmedberg: do you know why would I see more infobars if "hidden_ctp_plugin" is set to Flash instead of empty?
18:45bsmedbergfelipe, yeah that's what it does
18:45bsmedbergif the site queries navigator.plugins or navigotor.mimeTypes the infobar always shows up
18:46felipebsmedberg: but not if flash is not hidden from there, right?
18:46felipeso if they just consult navigator.plugins with flash not being hidden, the infobar doesn't show up
18:47felipeah ok, that's why I'm seeing a lot of infobars everywhere
18:48felipebsmedberg: what determines if the infobar pops open, or just the plugin icon is added to the url bar?
19:00dmosepaolo: ah, interesting, thanks!
19:04felipebsmedberg: here's something interesting.. With the code to "bust" SWFObject, it still is able to detect flash's version correctly, presumably through some other means.. But it successfully avoids the infobar from showing up
19:05felipehopefully that's the intention, and not for it to think that flash doesn't exist
19:05bsmedbergfelipe, the basic rule of the infobar is:
19:05bsmedbergif there is a full-size Flash thing to click on, the infobar shouldn't show up
19:06bsmedbergbut if there's only small/hidden Flash, then the infobar should show up to provide an alternate click target
19:06bsmedbergand the hidden_ctp_plugin feature is considered equivalent to a hidden Flash element
19:07felipeok, that was my understanding
19:07felipethere is one website that is confusing me
19:07felipeit is showing different behavior on two different profiles
19:07felipemy main one and a fresh one
19:07felipebut I guess it's triggered by cookies info
19:07bsmedbergdo you have the blocking lists on? Perhaps your main one has the lists but new one doesn't.
19:07bsmedbergOh that tool.
19:08bsmedbergOr sometimes ad rotations cause varied behavior.
19:08felipeyeah, I do have the blocklist
19:08felipeyeah.. it's a local news website that I visit often so it's very likely something like that
19:09felipeI've been using nightly with CTP + blocklists for the past week
19:09felipebut I had forgotten to change the hidden_ctp_plugin setting
19:10felipeso the experience wasn't as good as it could have been
22:14adwmarkh: is there a way to tell whether a remote sync client is a mobile device vs. desktop?
22:15adwoh client.type maybe?
22:15markhadw: yeah :)
22:16markhthere's client.os etc too
22:16adwoh nice, DEVICE_TYPE_DESKTOP etc.
22:24sfosterdo we have any docs on -moz-context-properties somewhere?
22:25sfosterI see values of 'fill' and 'stroke', this is svg-related / svg-specific?
22:26MattN#developers would probably be a better channel
22:26MattNMaybe ask jwatt/dholbert since I see them on related bugs
22:27sfosterMattN: ok, thanks
23:14_6a68glandium: Hey, I'm trying to fetch m-c on windows using git-cinnabar inside MozillaBuild, and I've hit a MemoryError: "fatal: stream ends early". I've followed the windows instructions in the git-cinnabar wiki. What am I missing?
23:17RyanVM_6a68: you can try, which has 64-bit python
23:18_6a68RyanVM: oh, great! so I'm not the first one to run into this bug, then ;-)
23:19firebotBug 1344643 NEW, Use 64bits Python in MozillaBuild
23:19_6a68 thanks!
23:19RyanVMthough I thought cinnabar had been making improvements in that respect
23:21_6a68I don't necessarily blame cinnabar, since the python is mozillabuild's
23:22_6a68also I've been trying to build on windows, on and off, for weeks now - so I've got msys, mingw, and mozillabuild all installed, and the $PATH is a mess :-P
23:22_6a68hopefully 64-bit python in mozillabuild will fix it
23:28RyanVM_6a68: glandium has quite a few blog posts recently about cinnabar having crazy memory usage
23:28RyanVMand improvements he's been making
23:28_6a68oh, interesting
23:28RyanVMbut yeah, 32-bit python has been getting painful
23:29_6a68doing 'python' at the mozillabuild command line now says, among other things, "[MSC v.1500 64 bit (AMD64)] on win32"
23:29glandium_6a68: you need to use the master branch of git-cinnabar if you want the memory improvements
23:29_6a68I guess that means it installed successfully?
23:30_6a68Hmm, maybe not, actually
23:30_6a68glandium: cool, thanks. I thought I was using the master branch, but I'll double-check that it's up to date
23:31RyanVM_6a68: yes, that output means you're on 64-bit python now
23:31RyanVMshould at least alleviate the issues
23:31_6a68RyanVM: cool, thanks again
23:32glandium_6a68: cloning gets you the release branch
23:32_6a68glandium: oh!
23:33_6a68glandium: once I've checked out master, is there anything else to do?
23:36glandium_6a68: make helper ; or git cinnabar download
23:38_6a68cool. both fail with errors (make helper can't find cc; git cinnabar download needs the 'requests' python module). I guess I"ll give the python module a shot
23:38_6a68thanks for the tips
17 May 2017
No messages
Last message: 12 days and 14 hours ago