• dietrich
    once the console api is called, are messages guaranteed to be shown in the order they're received? or is there a chance messages, after console.log is called, might be shown out of order?
  • nchevobbe
    dietrich: they should be shown in the order they are received
  • nchevobbe
    dietrich: are you seeing something weird ?
  • dietrich
    nchevobbe: ok thanks!
  • dietrich
    nchevobbe: i was told otherwise in bugzilla.mozilla.org/1406313
  • firebot
    Bug 1406313 — INVALID, nobody⊙mozilla.org — console.log from WebExtension experiment and a regular extension are not shown in chronological orde
  • nchevobbe
    oh, i was thinking in the same script
  • nchevobbe
    if you do console.log(new Date(), yourlog)
  • nchevobbe
    can you confirm that you do see them in non-chronological order ?
  • nchevobbe
    dietrich: that would help us to determine if it's the console.log that is shuffled, or the way your code is executed
  • nchevobbe
    pbro: hello :) not the first time I ask that, but would you have the intro video helen made last year ?
  • pbro
    nchevobbe: I do yes. What's the best way to get it to you?
  • pbro
    Oh wait, I'll put it on dropbox public
  • nchevobbe
    that would be nice to put it in the devtools-demo github
  • nchevobbe
  • nchevobbe
    also looks like we should update the icons
  • pbro
    nchevobbe: I'was looking into doing this and realized there's already a PR from me doing just that :)
  • nchevobbe
    ahah
  • pbro
  • pbro
    ok, I merged it. The video is in git LFS now, under github.com/devtools-html/demos/tree/master/assets
  • nchevobbe
    pbro: ok, thanks !
  • dietrich
    nchevobbe: i'll do some more testing and see...
  • stoyan
    Hey, is there a bug for the hardcoded accesskeys in the debugger?
  • nchevobbe
    stoyan: what do you mean ?
  • stoyan
  • stoyan
    There are a couple accesskeys hardcoded and not l10zable
  • nchevobbe
    stoyan: okay, got it. yulia might know ? or you can check if there's an issue about this in github.com/devtools-html/debugger.html
  • yulia
    stoyan: there isn’t an issue yet
  • stoyan
    yes, thank you. I'll file one in a minute.
  • ochameau
    gasolin_: ping
  • ochameau
    gasolin_: about l10n, I would suggest waiting for bug 1406311. jdescottes proved we can make it much faster.
  • firebot
    bugzil.la/1406311 — ASSIGNED, jdescottes⊙mozilla.com — L10N helper module is slow
  • ochameau
    gasolin_: also, L10N.getStr isn't the slowest, by fast. The problematic API is most of the other L10N APIs, like getFormatStr, which you are not planning to cache in all the bugs you just opened.
  • ochameau
    s/by fast/by far/
  • jdescottes
    +1, getStr should already be cached by l10n.js. I plan to get something reviewable for the more complex APIs today. After that we can profile again and decide what to do if l10n still shows up in the profiles
  • gasolin_
    ++
  • gasolin_
    It's still a good practice and nice for good first bug
  • Freyskeyd
    Hello
  • gasolin_
    hi
  • gasolin_
    ochameau, like Bug 1406312, I was thinking we can save plenty of time by get column tooltips when mouseover
  • firebot
    bugzil.la/1406312 — NEW, abhinav.koppula⊙gmail.com — Waterfall's timingBoxes is slow because of its l10n calls
  • jdescottes
    not convinced this is a good practice: it makes the files longer and more complex
  • jdescottes
    gasolin_: lazy loading of getFormatStr is a very good idea however
  • ochameau
    gasolin_: +1, I imagine contributors could work on more useful things. as it appears to be almost useless to cache L10N.getStr (as L10N caches it already).
  • ochameau
    gasolin_: and +1 on tooltip on mouseover. I imagine you can easily confirm that with perf-html profile
  • ochameau
    gasolin_: in which react component are they computed?
  • ochameau
    gasolin_: oh, is it done in all the request-list-column-*.js files?
  • gasolin_
  • ochameau
    so yes, I confirm most of request-list-column-*.js files have expensive call to getFormatStr, which takes most of their render() time
  • gasolin_
    yeah, we can save 3~4 getFormatStr each line, which will accumulate to a big number for many requests
  • ochameau
    you can see all this on this profile, if you expand the call tree until seeing all render() calls
  • ochameau
  • ochameau
    content-size, transferred-size and status are having slow calls to getFormatStr
  • ochameau
    Here is the weekly DAMP report:
  • ochameau
  • ochameau
    Main update is a small drop on console opening against complicated document. (cc: nchevobbe)
  • ochameau
    nchevobbe: this may be related to bug 1403895, It seems to be the only devtools change in the changelog
  • firebot
    bugzil.la/1403895 — FIXED, nchevobbe⊙mozilla.com — Split devtools/shared/client/main.js into multiple components
  • ochameau
    nchevobbe: nicely done. Code cleanup *and* performance improvements!
  • nchevobbe
    ochameau: hurray \o/
  • sole
    With a broken arm!!!!!
  • nchevobbe
    hehe
  • nchevobbe
    maybe I should break bones more often
  • nchevobbe
    the bug for console shutdown is showing improvements in damp too (and not only for console)
  • nchevobbe
  • Nitrogen
    hello everyone. this is probably the most specific place i could hope to find someone in the know...
  • Nitrogen
    i'm having trouble with the 'Edit and Resend' function of DevTool seemingly sending my POST data in non-UTF. despite Content-Type: application/json;charset=utf-8 header.
  • Nitrogen
    have anyone encountered this? i'm using Firefox 56.0 provided by the Ubuntu repository.
  • Nitrogen
    interestingly, when i do 'Copy as cURL' of that request and execute it via terminal - it's transmitted correctly.
  • nchevobbe
    Honza: ^
  • Honza
    Nitrogen: can you please file a bug. I recall there was similar problem with "Copy as cURL', so perhaps we have to fix it for "Edit and Resed" too.
  • Honza
  • Honza
    Nitrogen: the most important is to provide clean steps to reproduce and test case. So, we can see the issue on our machines.
  • ochameau
    nchevobbe: oh I see you are even hacking DAMP :)
  • nchevobbe
    ochameau: yeah, i'm not sure if it is substainable to add test for each case though
  • nchevobbe
    I guess it would grow the time to run damp
  • ochameau
    nchevobbe: yes, that is going to be an issue, but I was thinking about a third test, like simple/complicated. where we would open,reload and close but against a custom document doing all what we would like o cover
  • ochameau
    s/ o /to
  • nchevobbe
    that would be interesting
  • nchevobbe
    we could cover other things, like time to expand a large object/ typed array and stuff
  • nchevobbe
    ideally, the easiest would be to be able to add performance measurement in mochitests and have them stored somewhere
  • ochameau
    there is two issues still, 1/ mochitest runs on the cloud, so performance is expected to be quite random. 2/ you would still have to track zillions of graphs.
  • nchevobbe
    right
  • ochameau
    the issue with performance tracking is that it is hard to have a GREEN/NOT-GREEN state, that's the main issue :/
  • ochameau
    so we end up with having someone to look at a graph every now and then
  • nchevobbe
    with the work you're doing on these graphs, i hope we'll end up with weekly emails being sent to fx-devtools, or something alike
  • nchevobbe
    so everybody knows what's going on and can point to a regression that happened during the week
  • nchevobbe
    automatic email i mean, not only you sending these out to people :)
  • ochameau
    I wish we could get to a point where we could have the automated alert on bugzilla working correctly
  • ochameau
    that's the most efficient. then we only need to look at the graph to see what is the overall trend, but not to watch for regressions
  • nchevobbe
    yep
  • Nitrogen
    Honza, thanks! submitted bugzilla.mozilla.org/1407616
  • firebot
    Bug 1407616 — UNCONFIRMED, nobody⊙mozilla.org — Edit and Resend functionality ignores request Content-Type charset for POST body encoding
  • ochameau
    Honza: ping
  • Honza
    ochameau: in a meeting brb
  • Honza
    Nitrogen: thanks!
  • Honza
    ochameau: pong, I am here
  • ochameau
    Honza: so, I'm trying to come up with a generic way to fetch request data, like the old console code and its DataProvider
  • ochameau
    Honza: what about putting a "requestData" action in: devtools/client/netmonitor/src/actions/requests.js
  • ochameau
    ?
  • Honza
    ochameau: We can have an action, but I think it would be rather a helper. The bottom line is an abstract 'connector' that wraps a 'data-provider' and allows connection to various backends (we support Firefox and Chrome atm). The 'data-provider' is what should implement the actual fetching and data collecting. We only have 'FirefoxDataProvider' atm.
  • Honza
    ochameau: The old HTTPi impl in old Console UI did use the FirefoxDataProvider correctly. i.e. it requested data only when needed - lazily
  • Honza
    and I would definitely like to have that again.
  • ochameau
    Honza: it has to involve the connector anyway, in any case, FirefoxDataProvider will do the client.getResponseContent call.
  • ochameau
    it just that instead of calling the provider from the react component, you would call an action
  • ochameau
    behind the scene, the action will call the provider
  • Honza
    ochameau: yes
  • Honza
    ochameau: I think we should talk about this tomorrow at the meeting
  • Honza
    ochameau: since I've some patches that are changing the connector
  • ochameau
    I have no idea if that's any better, I know nothing about react/redux. it just seems to match what has been done in console
  • ochameau
    ah
  • Honza
    I want to land them asap, but i was caught by the intermittent issue
  • ochameau
    Honza: are these patch on bugzilla, or is this just intent to modify the connector?
  • Honza
    ochameau: Bug 1005755
  • firebot
    bugzil.la/1005755 — ASSIGNED, odvarko⊙gmail.com — A button to pause/stop the HTTP traffic in the network monitor view
  • Honza
    ochameau: it refactors the connector and passes reference down the tree of components. So, every component can use it and request data as needed (lazily)
  • Honza
    ochameau: this way we'll have an infrastructure for requiring the data as in the old HTTPi
  • Honza
    ochameau: through the abstract connector interface
  • ochameau
    Honza: ok, I see that.
  • Honza
    ochameau: every component will have an access to it (similarly as it has access to e.g. source map service)
  • ochameau
    I can rebase on top of this patch queue if that is ready to land. is it?
  • Honza
    ochameau: I wanted to do some tests, but I can do them as follow ups and land what's already R+
  • Honza
    ochameau: so, it isn't blocking any progress
  • ochameau
    Honza: please do some tests :) but I can only rebase once you know you won't change it a lot, just to prevent having conflicts
  • ochameau
    Honza: if you only add files, and do minor modifications here and there, that's is fine
  • ochameau
    Honza: I just rebased, just some simple conflicts.
  • Honza
    ok, good
  • ochameau
    Honza: btw, about pausing network listening, you can do more than stop listening for these events
  • ochameau
    Honza: toolbox force listening for network events in the backend, right here:
  • ochameau
  • ochameau
    you could also call stopListeners() when pausing, it will also be a signifiant relief on the backend side!
  • ochameau
    Honza: but I would suggest you doing that in a followup, as, who knows what will happen when you do that...
  • Honza
    ochameau: but that would also stop the Net in the Console panel , not sure if we want that.
  • Honza
    yes
  • ochameau
    Honza: ah, yes, I didn't thought about the console... too bad.
  • nchevobbe
    Honza: ochameau : from a user standpoint it might make sense to stop the console network logs
  • Honza
    nchevobbe: note that they can stop if the filter is off
  • Honza
    nchevobbe: even if ...
  • Honza
    nchevobbe: the filter is supposed to hide only I guess...
  • Honza
    nchevobbe: anyway, if an action in the Net panel affects also the Console panel the UI should be clear about that
  • nchevobbe
    agreed
  • ochameau
    I would be interested into the real cost of backend listeners. let's see what DAMP says. network listening is off by default on the console, right?
  • ochameau
    just pushed a try push commenting the startListeners call, waiting to see what effects it has on all but netmon
  • ochameau
  • ochameau
    (netmon will be mostlikely broken, now that I say that, I'm wondering if DAMP will complete)
  • flod
    jdescottes: ping
  • flod
    jdescottes: I see people pointing at bugzilla.mozilla.org/1369801 and system add-on scheduled for 58, but I haven't heard anything in months regarding l10n, and the time left seems too short
  • firebot
    Bug 1369801 — REOPENED, jdescottes⊙mozilla.com — Ship DevTools as a system-addon
  • jdescottes
    flod: hi, engineering efforts are on hold for this, won't happen in Q4 for sure
  • jdescottes
    will update the bug
  • flod
    jdescottes: thanks, looks like someone needs to update the slide in the cross-functional product
  • jdescottes
    flod: "I see people pointing at" any thread I should watch/where I should comment?
  • jryans
    ochameau: jdescottes: feels like lots of room to optimize node actor creation! it's a bit scary that we seem to remake them for existing nodes... :S
  • jryans
    (at least from the count of actors...)
  • ochameau
    yes this is surprising, there is caches at the actor level, but don't know about the client
  • jryans
    it's a bit odd to me that a childList mutation re-counts all children... couldn't it include just the change in number instead?
  • jdescottes
    jryans: the childList mutation by itself doesn't count the children, it's the markup view that decides to fetch the children when receiving a childList mutation
  • ochameau
    oh wait you will need react diffing algorithm then :)
  • jdescottes
    (but as you said, lots of room for improvements, just need to pick the good ones :))
  • jdescottes
    ochameau: regarding the caching, we cache nodeactors correctly on the server, we don't cache forms (that's what I'm trying to do as much as possible). On the client I don't believe we are caching anything
  • ochameau
    yes, I don't remember seeing anything about that
  • jryans
    jdescottes: ah, thanks for clarification. still, it appears the platform tells us for each mutation 1. what nodes were added / removed and 2. where from / to by referencing siblings. currently though we seem to just drop that data...
  • jryans
    jdescottes: seems like a possible approach would be to tell the client precisely where the new things go, and have it apply exactly those updates, instead of requesting all children.
  • jdescottes
    jryans: even if we have precise data, trying to update the markup view based on the information in the mutation means we trust mutations to be received in order and to not miss any mutation
  • jdescottes
    (if that's a safe assumption then yes, we can process mutations more efficiently this way)
  • ochameau
    jryans: yes, that's the theory again, did you even had your hand into the markup view? :p
  • jryans
    jdescottes: right, i believe those should be safe assumptions, at least at the protocol level... unsure if markup-view specifically breaks them somewhere... i might play around with the idea :) i think i agree a throttle / idle callback is a good workaround for now though!
  • jryans
    ochameau: haha, no, haven't worked on it much... but may need it more for designer tools stuff, so interested in seeing good perf :)
  • ochameau
    that updateChildren method is critical and quite daunting!
  • ochameau
  • jryans
    ochameau: it does seems to do too many things :S
  • jryans
    is zer0 on PTO lately?