mozilla :: #devtools

9 Aug 2017
01:28jonathanGBhey, I wanted to know if there's a way to inspect the frames sent/received via devtools?
06:38nchevobbejonathanGB: Hello. I am not sure I understand, what do you mean by frames ?
06:44jonathanGBnchevobbe: the information sent back and forth using websockets. In chrome devtools, they're shown as part of frames
06:45nchevobbejonathanGB: I don't think we have that right into devtools. There is , but U don't know if it's working well those days. Honza would know better
06:46jonathanGBnchevobbe: ok yeah that's what I've seen online. Is it in the plans to bring that kind of tool in devtools?
06:47Honzanchevobbe, jonathanGB: WebSocket extension is based on Add-on SDK and needs to be rewritten into WebExtension, so it stopped working in Firefox 57
06:47Honza(Firefox 57 == current Nightly)
06:47jonathanGByep makes sense
07:54Honzanchevobbe: when executing webpack in webconsole it says it can't parse async functions. Have you seen that?
08:09nchevobbeHonza: I ddidn't. Maybe a problem with node version ?
08:10nchevobbeor something wrong with the webpack config
08:10nchevobbebut I think it was working well before
09:17Honzanchevobbe: Unknown plugin "transform-flow-strip-types", do you have it installed globally?
09:22nchevobbeoh, it might be that
09:22nchevobbeI think I do
09:22nchevobbeand this must be because the ObjectInspector is typed
11:56ochameaujlast: hi, I've been able to reproduce the browser toolbox failure locally once. hopefully it reproduces with some added debug statements...
12:01jlastochameau: i bet that after we changed the select source logic
12:02jlastit got a bit slower/async
12:05nchevobbeHonza: How do you test the launchpad with ? yarn link ?
12:05jlastochameau: this could fix it:
12:05Honzayes yarn link
12:05nchevobbewithout it i'm seeing an error on EventEmitter
12:05jlastjust need to see if there's a syntax issue
12:14ochameaujlast: that was too easy, it doesn't seem to reproduce with logs, let's see if I still repro without. then I can test with your patch
12:21nchevobbeHonza: I have it working :
12:22nchevobbeHonza: ^ this is all the CSS files that need to be required
12:22nchevobbeI wonder if we could use webconsole.xhtml directly in the launchpad though
12:28Honzanchevobbe: thanks, it's ok now
12:53ochameaujlast: ok looks like I reproduced it only once... so I can't help testing it. may be pushing your patch to try would be enough to confirm the fix?
12:57jlastyeah - i can put a fix in for that timing issue
13:01GijsIs there a bug on file about the inspector getting confused by XBL bindings and displaying a non-labeled empty blob as the only child of things?
13:09soleGijs: gl might know
13:23jlastochameau: mind taking a look at this fix:
13:24jlastthe tests pass
14:30jdescottesochameau Honza sole : gofaster meeting?
14:32solejdescottes: I'll be a touch late! but joining in a mom
15:19ochameaujlast: the patch applies fine for head.js but not for the other file (on beta branch)
15:19ochameaujlast: but the test still passes here
15:19jlasthmm, what do you mean?
15:19ochameaujlast: do you want me to push it to try for the beta branch?
15:20ochameauthere is conflict when I try to apply this branch against mozilla-beta branch
15:20ochameaubut only for src/test/mochitest/browser_dbg-pretty-print.js
15:21jlasti see. that's okay. i don't mind making a patch later today
15:22jlastwe can also ignore the pretty_print intermittent on beta
15:22jlastthe bug that introduced is not in beta
15:25ochameaujlast: here is a try build against beta:
15:26ochameautromey: ping
15:26tromeyochameau: hi, what's up?
15:26ochameautromey: I'm crying with the promise.jsm work, but I had question about another topic ;)
15:27tromeyI'm sorry the promise thing is like that
15:27tromeyit's a tricky area
15:27ochameauI was wondering if there is any platform code that we could disable when devtools are disabled, and here I'm wondering about the inspector
15:27ochameauthere is
15:28ochameaubut everything looks very "on-demand" so it shouldn't introduce any additional cost...
15:28tromeythat is my belief as well
15:28tromeythere are a few spots where there's a memory cost
15:28tromeyactually, if devtools aren't even installed, then there's usually no reason to compute async stack parents
15:28tromeythat might be a time saver
15:29ochameauwe are about to make console.log be no-op when devtools aren't used, but may be there is something to do in helpers for the inspector...
15:29tromeyI wouldn't expect so but I don't really know for certain
15:30ochameaudo you mean javascript.options.asyncstack feature?
15:31ochameauit is off on release/beta so we should be fine here:
15:31tromeyah ok
15:32ochameauI think we should look over JS Debugger API to ensure there is no additional cost there as well
15:33tromeyI think that's fine as well
15:33tromeyI think that's all dependent on the debugger actually being in use
15:34tromeythere's a small memory cost due to capturing source map URLs when parsing
15:34tromeythese are kept as long as the source is alive
15:35ochameausee bug 1382377's patch, we may introduce a "devtools.enabled" pref, which would help turn all such code on/off easily depending if the user is interested in devtools features or not
15:37tromeyspidermonkey would require extra work since I don't think it has access to prefs
15:37tromeybut it's not clear it is really worth doing
15:43julienw<ochameau> we are about to make console.log be no-op <== are you still putting messages in a stack somewhere so that we see the logs from before the devtools window opens ?
15:48ochameaujulienw: no, that&#39;s the whole point of this. but this pref is related to the devtools installation ui, so it will make it clear that anything that happened before the installation is missed
15:48ochameaujulienw: i.e. this new behavior will only happen after bug 1361080 is done
15:48firebot NEW, [meta][devtools-addon] Create a UI shim to install/bootstrap devtools addon
15:49Gijson my main nightly profile the browser debugger comes up blank
15:49Gijshow do I file a useful bug report about this?
15:50ochameautromey: I profiled an heavy webpage load with profiler recording agressively and I can only see this function from the debugger:
15:50Gijsnone of the panes load, the entire toolbox underneath the toolbox tabstrip is just blank
15:50ochameauand it isn&#39;t really significant
15:50tromeyochameau: yeah, that is one of the ones that calls into a slow path when debugging is enabled
15:51tromeyochameau: not sure if it could be sped up any more, maybe somehow if we were desperate
15:52ochameautromey: yes, this has nothing to do with console performances which is very impactful!
16:15ochameautromey: I looked for something related to devtools, but can&#39;t find anything. I saw the console and the debugger function, that&#39;s all.
16:16ochameautromey: what are the function involved in the source map, to see if I see them... ?
16:16tromeyand TokenStream::getSourceMappingURL
16:17tromeyand there&#39;s some associated memory use
16:19ochameauShould I see this method being called?
16:19ochameau(if I don&#39;t open the tools)
16:20julienwochameau, I see
16:22tromeyochameau: yeah
16:22tromeyit&#39;s called during js parses
16:22ochameautoo fast, the profiler don&#39;t record its call
16:22tromeynot too surprising
16:23ochameauwhat could we stop doing in this cpp if devtools are not enabled?
16:23ochameauis it the whole TokenStream we could disable?! I imagine not
16:25tromeyno, tokenstream is just needed
16:25tromeyyou could maybe make TokenStream::getDirectives return early
16:25tromeybut I tend to think this isn&#39;t worthwhile
16:27ochameauif it doesn&#39;t even appear on an agressive profile, yes it doesn&#39;t sound like a big win
17:28solegregtatum: remember this? =)
17:28firebotBug 1383825 FIXED, Workday homepage load animation laggy
17:30soleGijs: did you file anything? jlast might know
17:31soletromey: ha! I see you in the call
17:32gregtatumsole: nice!
17:32soletromey: exciting topic! I feel they missed an opportunity to use the emoji
17:32gregtatumsole: &quot;titanic box shadows&quot; is a great pull quote from that bug
17:33solegregtatum: yeees
17:33soleseriously it&#39;s even a bit pleasant to use workday now
17:33Gijssole: not yet, but will do I guess
17:33Gijssole: no way!
17:33soleGijs: sorry about this, the browser toolbox is in a bad state now :(
17:33jlastSome - know what?
17:33Gijs(re: workday)
17:34Gijsjlast: browser toolbox debugger is completely empty in one of my profiles on nightly
17:34Gijsjlast: just, nothing under the tabstrip at all, empty void is all I get
17:34Gijswondered how to get more info for a bugreport
17:35jlast:/ walks silently away
17:35jlastSorry, getting lunch. this is beyond my phone powers
17:35gregtatumwhoaaaa just logged in to workday and it&#39;s smooth
17:46monaddcamp Slayer, LoG tonight.
17:46jdescottesGijs: just to be sure, is the browser toolbox issue only about the debugger or is it affecting other tools as well ?
17:47dcampnomad: nice
17:47Gijsjdescottes: inspector and style editor seem to be OK
17:47dcampI&#39;ve still never seen slayer live
17:47monadget out.
17:47Gijsconsole too
17:47dcampLoG a few times awhile back, but never slayer
17:48monadFun crew.
17:49dcampMaybe I should find my way up to Seattle this weekend
17:49monadWhat&#39;s there?
17:50dcampLooks like slayer will be there :)
17:50monadah. yes. with LoG. 12th.
17:51firebotBug 1388825 NEW, Debugger pane completely empty in the browser toolbox in one of my profiles
17:51jdescottesGijs thanks
17:51monadYikes. Nothing but metal in Seattle in Aug.
17:51jdescottesah of course, line 37638!
17:51monadAUG 8 at Black Lodge: Black Vice, Haunter, Crawl
17:52monadAUG 9 at El Corazon: Eyehategod, Capitalist Casualties, The Accused AD, Coffin Break, The Plot Sickens
17:52monadAUG 9 at Highline: Barbarian, Peucharist, Kmmand, Ghostblood
17:52monadAUG 9 at CenturyLink Field: Metallica, Avenged Sevenfold, Gojira
17:52monadAUG 10 at El Corazon: The Battle for Summer Slaughter, with Ashes of Existence, Breather, Dismembering Mary, Vesuvian, Prey the Hunter, We Were Giants, Time Spent
17:53jdescottesGijs: can you tell me the value of devtools.debugger.prefs-schema-version in your profile?
17:54monadMust be some tension building in Seattle or something.
17:55Gijsjdescottes: in the browser debugger profile or the browser one?
17:55dcampIt&#39;s the rain
17:56Gijsjdescottes: browser has 1.0.1
17:56jdescottesGijs: both would be great :)
17:56dcampIt&#39;s like a milder version of the Scandinavian effect
17:56monadI suggest everyone stay away from the North West. Blood will flow.
17:58Gijsjdescottes: is there a sane way of getting the browser profile one?
17:58Gijslike, from the console or something?
17:59jdescottesGijs: I don&#39;t know, I get it from the prefs.js file in the chrome_debugger_profile folder. I&#39;m sure there&#39;s a better way
17:59jdescottesGijs: is this on nightly or on a local build? if local build can you share the m-c changeset you are on?
18:03Gijsjdescottes: they&#39;re both broken
18:03Gijsand have been for a while
18:03* Gijs was kind of hoping it was going to go away
18:04jdescottesok so my suspicion is that you are hitting a bug with the mechanism which is supposed to clear &quot;saved&quot; breakpoints, in case the breakpoints model changed
18:04jdescotteswe recently landed a fix for that:
18:04firebotBug 1388128 FIXED, Debugger does not remove some breakpoints
18:05jdescottesbut I just realized the fix might not propagate to the browser toolbox, because of the way the profile is created
18:06jdescottesGijs: if I&#39;m correct, forcing devtools.debugger.prefs-schema-version to &quot;1.0.0&quot; should fix your issue
18:12jdescottesGijs: I&#39;m attaching a patch on the bug you created, that will force the pref for the browser toolbox
18:20Gijsjdescottes: forcing it in which profile?
18:21Gijsdoing it in the main profile doesn&#39;t seem to do anything
18:21jdescottesGijs: the browser toolbox one
18:21jdescottes(I&#39;m not 100% if my patch is effective :( )
18:21soleah it&#39;s a different one? is it created invisibly?
18:21jdescottesoh yes
18:21* sole learns things
18:21soleIt makes sense
18:22jdescottesif you go inside your profile folder you will find another folder called &quot;chrome_debugger_profile&quot; which contains the browser toolbox profile
18:23soleohhhh true!
18:29jdescottesGijs: ok attaching a new patch that will really force a cleanup of the breakpoints in any case. could try this one?
18:29jdescottes*could you
18:31Gijsjdescottes: so I flipped the pref in the browser, restarted, didn&#39;t help, then flipped it in the toolbox profile, still the same...
18:31Gijsjdescottes: you mean build with the patch?
18:32jdescottesGijs: yes :/
18:33Gijsjdescottes: doesn&#39;t help
18:36Gijsjdescottes: fwiw, it looks like it&#39;s trying to parse a char pref with JSON.parse and there&#39;s just gobbledygook in it that makes JSON.parse() barf
18:36jdescottesGijs: ok, sorry about that. it looks like your issue is still related to preferences so if you can share the prefs.js file found in your chrome_debugger_profile folder I think it can help investigating
18:37jdescotteswe do the JSON.parse when retrieving certain prefs, maybe you have one which was badly saved?
18:38Gijsjdescottes: oh, I think I know what it is
18:39Gijs\&quot;Edit this bookmark (^XD)
18:39Gijsthat&#39;s copied from vi
18:39GijsI don&#39;t have a hex editor to hand
18:39Gijsbut I bet something expects there to not be random control chars in there
18:39Gijsthat&#39;ll be the OS X &#39;command&#39;/apple symbol
18:39Gijsit&#39;s the tooltip from the node in question
18:39GijsI... don&#39;t know why we save all of the value
18:40jdescottesoh that&#39;s probably it
18:41Gijsyeah, removing that, the debugger starts again
18:43jdescottesGijs: at least you&#39;re unblocked :) Looking at your pastebin, what kills the JSON.parse for me is the &quot;t rue&quot; at the end
18:44Gijsjdescottes: that&#39;s just broken line-wrapping from my copying from vi
18:44jdescottesGijs: oh ok
18:50jdescotteson the plus side, it has clear STRs now!
19:02Gijsthanks for creating those STR :)
19:06jdescottesnp, I&#39;m glad we figured out the root cause !
21:26jlastochameau: i&#39;m not sure how the test can fail, we are waiting for it to be true lol
21:26jlastit&#39;s the same assertion, i suppose I can move the checks to one shared helper
21:37ochameaujlast: tbh, I&#39;m quite lost in all these &quot;sources&quot;, there is too many ;)
21:38jlasthehe - updating the assertion a bit to cover stepping as well
21:38ochameauwaitForPaused doesn&#39;t check for a precise source, it just verify we are on the paused one, whereas assertPausedLocation accept a source and line, which make it very explicit
21:43jlasti see - that&#39;s interesting.
21:43jlasti wonder why the test is paused somewhere else in that scenario...
21:44jlasti&#39;m going to add some logs for that condition and see if i can answer the question
21:55jlastwe can see if waiting on the correct source helps:
10 Aug 2017
No messages
Last message: 13 days and 23 hours ago