mozilla :: #devtools

21 Apr 2017
05:37Honzarickychien: ping
06:20rickychienHonza: pong
06:26Honzarickychien: I was playing with the new CSS layout ...
06:28Honzarickychien: I don't understand why the last column needs to use vw units.
06:28rickychienHonza: Make waterfall column resizable
06:29Honzarickychien: yes, but why not % ?
06:32rickychienHonza: there are some problems when using %, you can modify .requests-list-waterfall and reload again (in launchpad)
06:33rickychienHonza: Is that slow on your machine?
06:33Honzarickychien: yap, I am doing that
06:33HonzaAnd yes vw makes it slow
06:34rickychienHonza: Resizing animation in waterfall column will look weird if we use %
06:34Honzarickychien: My assumption was that if we set width of all columns using % and make sure that the total is 100% it should work (and solve hidden columns after)
06:39Honzarickychien: ok, % now work for me (all columns displayed)
06:40rickychienHonza: Do you try to resize window?
06:47Honzarickychien: yes, it seems to be faster than vw
06:50rickychienHonza: would you like to upload your patch? Or tell me what you changed?
06:52Honzarickychien: yep, let's discuss at out meeting in 10 min
06:53rickychienHonza: ok
07:26pbrobirtles: daisuke: We should totally blog about the new animated properties visualization in the inspector! An article that shows people what it looks like, and what problems does it solve. Have you thought about that already?
07:26pbrointerested in doing it??
07:27birtlespbro: yeah, we should definitely do it
07:27birtlesActually Daisuke and I are presenting the tools to a Web developers meet-up in Tokyo in a few hours
07:27pbrooh nice!
07:27pbrowill this be recorded?
07:28pbro(hmm, having said this, I'm guessing it'll be in Japanese ...)
07:30birtlesYeah, it will be in Japanese
07:31birtlesWe have slides but the DevTools part is mostly just an extended demo
07:46pbrook. Anyway, let me know if you want to write a blog post
08:15rickychienhonza, ntim: bug for implementing column resizer has filed. See bug 1358414
08:15firebot NEW, Introduce column resizer in request list
08:15Honzarickychien: thanks
08:25nchevobbejdescottes: the backend-way for connected node feels so much better on my open-in-inspector patch
08:25jdescottesnchevobbe: I can imagine, quite crazy to see how this started :)
08:26nchevobbejdescottes: yeah, i lost so much time on this and now the solution is so elegant
08:26nchevobbebut it made me learn to check on the backend side of things :)
08:27ntimrickychien: ping
08:27rickychienntim: pong
08:28ntimrickychien: I couldn't find a solution, it seems like CSS tables are bricked the way they are
08:28ntimrickychien: If we really want to get rid of flex however, a possibility is to use normal display: inline-block; for the layout
08:29rickychienntim: yep, layout with css table is hard
08:29ntimthen compute the column width via JS
08:29ntimand sharing those widths via CSS variables
08:29ntimrickychien: Chrome currently computes column widths via JS
08:29rickychienntim: agree. This our conclusion. Finally, we need to distribute the available width via JS
08:30ntimrickychien: another advantage of doing that is that implementing resizing will be easier
08:30rickychienntim: You're right. Chrome is using a column resizer which forces width and position of column, it's faster
08:31rickychienntim: That's right! I'm in favor of column resizer solution
08:31ntimI would suggest using CSS variables here and basic block layouts rather than chrome's way
08:32rickychienntim: do you see any performance impact if we go with block layouts?
08:33ntimrickychien: block layouts are the most basic kind of layouts available, so I suspect they'll be faster than flex at least
08:34ntimrickychien: another option is using column based markups
08:34ntim(like the storage inspector)
08:34rickychienntim: We're using display: table layout in WIP patch
08:36ntimrickychien: I think display: inline-block should be as fast as display: table
08:37Honzantim: what's the 'column based layout' ?
08:37ntimHonza: If you inspect the storage inspector, you'll see that the markup is like:
08:37ntim<div class=&quot;column&quot;>
08:38ntim div.header
08:38ntim<div class=&quot;column&quot;>
08:38ntim div.header
08:38ntim div.cell
08:38ntim div.cell
08:38Honzantim: ah, I see. And there is a splitter in between ...
08:40ntimHonza: resizing seems instant with the storage inspector, so it might actually be a good solutio
08:40pbrohave you considered using css grid?
08:40Honzantim: yes
08:40Honzapbro: yes, but nobody tried it yet
08:40pbrothe most important in terms of perf here is how fast can new rows be added when requests are being logged, right? Not really when resizing columns
08:41Honzapbro: yes
08:41Honzapbro: also CSS relayout perf is important
08:41pbroif we&#39;re comparing perf of inline-block vs. table vs. grid vs. something else, we should really do stress tests with lots of rows being added quickly first
08:43ntimpbro: though flexibility should be taken in consideration: in case resizing gets implemented, we don&#39;t want to rebuild the layout once again
08:44pbroagreed. By resizing, do you mean resizing columns?
08:44pbrocss grid might make this easy with the grid-template-column property
08:44rickychienFor column resizer, please see See bug 1358414
08:44firebot NEW, Introduce column resizer in request list
08:45pbrorickychien: can you help me understand how having a way to resize columns help performance?
08:45rickychienCSS Grid is a good option but it will conflict with react-virtualized
08:45pbroI see it blocks a perf bug, and is marked as P1
08:51rickychienpbro: When using div display: table, column width will be calculated after first row data is ready. With column resizer, we can fetch stored column width from prefs and I think it should be faster. It also help fix the hidden column issue.
08:52ntimI&#39;m personally reluctant to use display: table, it&#39;s very clumsy :)
08:52Honzantim: we can try the &#39;column&#39; layout...
08:52Honzait&#39;s sounds promising
08:53Honzaeven for the future resizer support
08:53pbrorickychien: ok, I see, if we have column widths in pixels, persisted in a pref, we can retrieve them and set the widths of columns this way instead of letting them be set by CSS?
08:57rickychienpbro: yep. We can force column widths in px. Chromium is using column resizer approach. This also fix the issue when user hide columns. CSS solution (no matter Grid / table) is hard to calculate the distributed widths for columns because the number of column is dynamic.
08:58pbrogrid of table can still define columns in px however. So maybe these are not incompatible. Anyway, thank you for the clarification. I just want to make sure I understand the work being done now!
09:00rickychienpbro: cool!
09:02rickychienbtw, do we have Grid expert? I wanna know how to deal with dynamic number of column in Grid
09:02pbrothere are several ways I think
09:03pbroyou could update the grid-template-column property dynamically
09:03pbroor use grid-auto-columns property so new columns do have a default size
09:03pbrocss grid doesn&#39;t prevent you from adding columns even if they&#39;ve not been defined at first
09:04pbroI suspect the list of visible columns is available in a pref?
09:05rickychienIt looks like we still need JS.
09:06pbroyes, because you only know how many and which columns you have in JS code.
09:07rickychienI see!
09:09SoItBeginsWhen youre developing the dev tools, do you debug them with the dev tools?
09:09nchevobbeSoItBegins: Yes :)
09:10SoItBegins:D Id used the Browser Toolbox for extension debugging before, but...
09:10SoItBeginsthats awesome, though :D
09:10nchevobbeSoItBegins: And some panels can be run in tabs directly, so you can use devtools as for any other webapp
09:19pbrorickychien: I&#39;m doing some quick profiling, the resizeWaterfall function forces sync reflows everytime the panel is resized, but it looks like that&#39;s useful only if you resize the width, not the height. Do you have plans to address this in your current work?
09:20rickychienpbro: Are you profiling on my WIP patch?
09:20pbrorickychien: no, just nightly
09:21pbrojust thinking that the waterfall graph has a very large part to play in the bad perf when resizing the panel
09:22rickychienpbro: My patch reduces the resize frequency by increasing setTimeout from 50ms to 500ms. Ideally, resizing speed is smoother than before.
09:23rickychienpbro: Agree your point. We had discussion about waterfall column width. Width in px and vw both are good options.
09:25rickychienpbro: another perf issue in waterfall is that when loading large amount of data in or bbc. Too many requests render in document will slow down waterfall especially when doing window resizing.
09:25rickychienpbro: React-virtualized could help
09:26rickychienUnfortunately, it is blocked by APZ
09:26pbroyeah, I was following that bug a little bit
09:28pbroanyway, yes, this waterfall graph seems to be the most expensive thing now in the netmonitor
09:28rickychienpbro: You can play with Chrome&#39;s netmonitor. It draws waterfall with canvas and the width of canvas is set by column resizer. So it&#39;s blazing faster when resizing.
09:30pbroFor me, that means one thing: the layout technique we use is of very little importance compared to the waterfall graph. That&#39;s what needs fixing first. Even on when close to 200 requests, a table, grid, divs, whatever would perform just as good
09:31pbroit&#39;s really just the fact that the graph causes reflows all the time, and is heavy to resize
09:48rickychienAgree. graph just affect when window resize
10:00pbroyeah. It also causes style recalc very often because of the --timings-scale and --timings-rev-scale properties and how they are used to transform the graph. iiuc everytime a new request is added, these properties are changed and that slows things down. The canvas idea you mentioned would solve this very nicely!
10:00pbroSo anyway, great that you are working on the waterfall graph
10:07mikeratcliffeThat moment when you think something is finished and then you realize you need to fix all the tests:
10:08* mikeratcliffe mumbles inanely
11:17mikeratcliffeOMG: I didn&#39;t know we were limited to 150 cookies per page...
11:18mikeratcliffeI have taken ages trying to work out why the storage inspector wasn&#39;t displaying the first 10 cookies when I created 160.
11:18mikeratcliffeYou go over 150 and the first ones disappear.
11:26pbrogood to know!
11:26pbronot that I&#39;ll need to create more than 150 cookies anytime soon :)
12:25mikeratcliffeYou can&#39;t inspect the browser when debugging any more... apart from breaking browser inspection it breaks the inspect link next to items in the variable view. Known issue?
13:03solemikeratcliffe: searching for &#39;cookies 150&#39; yields ... this...
13:03soleUp to 150 cookies per minute! Woohoo!
13:04mikeratcliffeWe must use that inside Firefox... it would explain the limitation.
13:04soleBut do we have multiple cookie designs too? 8-)
13:04mikeratcliffeA bargain at a mere $42,000 ;)
13:04* sole My favourite thing is that the machine is called Thunderbird
13:05soleOne can get so many weird things in amazon...
13:05solemikeratcliffe: nchevobbe : Reviewed everything for you!
13:05mikeratcliffeThanks, I will correct my grammar when I finish my current patch.
13:05nchevobbesole: saw that, thanks !
13:07mikeratcliffesole: Do you really want to know why we using YAML in one file and JSON in the other?
13:07mikeratcliffeThe only reason I can think of is because YAML is cool.
13:09soleBut that means we&#39;re using different syntaxes for that reason
13:10soleI don&#39;t really see it like a valid reason, I thought that the data group required .yaml instead of JSON now
13:17mikeratcliffeYes, that sounds familiar.
13:20solemikeratcliffe: I don&#39;t deny that yaml is cool, but most people are probably used to JSON (specially if they haven&#39;t done any Ruby but they have done JS). It makes adding probes more complicated because you also need to take file syntax differences into account as well, which adds friction
13:20soleWe should be aiming at reducing friction, not adding it :)
13:20mikeratcliffeTrue... I will look into why we changed, don&#39;t worry.
13:21solemikeratcliffe: seriously if the rest of the codebase used yaml I&#39;d suggest we kept using yaml
13:22mikeratcliffenchevobbe: Just sent you a review &#39;cos I could see you are around.
13:22nchevobbemikeratcliffe: sure :)
13:31solemikeratcliffe: I see that you didn&#39;t add the file!
13:31solemikeratcliffe: You could just have told me &quot;I&#39;ve no idea why&quot; :P
13:32mikeratcliffeAh, you thought it was me?
13:32mikeratcliffeNow it makes more sense lol
13:32mikeratcliffeI&#39;ll still try to work out why they used YAML though.
13:33solemikeratcliffe: yes that&#39;s why I asked you!
13:33soleThere&#39;s also Events.yaml
13:43HonzaHow can I quickly use my modified Reps module in m-c?
13:46nchevobbeHonza: you can use yarn copy-assets
13:46nchevobbeit will take the bundle and the tests, and move it to the path you have in development,json
13:47Honzanchevobbe: ok, let me try it
13:48nchevobbeHonza: if you don&#39;t need the tests, you can even use yarn copy-assets-watch, so every changes will create a bundle and move it to you path
13:48Honzanchevobbe: nice
14:17Honzanchevobbe: There is getGripPreviewItems helper in reps-utils that does what I need with one little exception. I need also property keys from generic grip. Note that keys from Map are already used so, perhaps it isn&#39;t a problem? See quick diff:
14:17Honzanchevobbe: plus also support for RegEx
14:22nchevobbeHonza: At first sight this looks good, except maybe the change in l.37-38
14:22tromeyfitzgen: so I had some back and forth with the bug author about source-maps and his claim is that there are no longer available node releases that do not support Set
14:23Honzayeah, that&#39;s about the keys
14:23nchevobbei&#39;m worried it would break what we have, can you check that the reps mochitest are still fine with this change ?
14:23tromeyfitzgen: is there some other case we care about here?
14:24Honzanchevobbe: `mach test devtools/client/shared/components/reps/test/` says Failed: 0
14:24nchevobbeHonza: okay nice
14:25Honzanchevobbe: cool
14:54Honzanchevobbe: The generated Reps bundle is using &#39;CRLF&#39; instead of &#39;LF&#39;. Any tips how to fix it?
14:55Honzagit settings wrong?
14:55nchevobbeHonza: I really don&#39;t know. Let me see if I can find something
14:59nchevobbeHonza: maybe you have something set for core.autocrlf ?
15:00nchevobbeor core.eol
15:01Honzanchevobbe: yeah, I&#39;ll check it
15:01HonzaI was suspecting this
15:05wedrIs it just me, or is it Firefox Developers Edition being unpredictable when it comes to when a breakpoint is hit?
15:06nchevobbewedr: If something looks weird and is reproducible, please file a bug with detailed steps so we can have a look at what is going on
15:07wedroh, so it&#39;s not me then.
15:10solewedr: it might just be you, that&#39;s why nchevobbe is asking you to help us help you by filing a bug
15:10soleSo we can try and see if it happens in our side of things too
15:10wedrsole: Currently browsing bugzilla to see if there are duplicate bugs.
15:10wedrJust gotta make sure.
15:13wedrsole, nchevobbe: This seems to be what I&#39;m experiencing:
15:13firebotBug 977972 NEW, Breakpoints not working inside callback functions
15:15wedrYeah, sometimes, breakpoints set inside callbacks aren&#39;t even triggered, despite knowing certain console.log() inside the callbacks are being triggered.
15:16soleinteresting, it seems to be related to XHR?
15:16soleI have never encountered this
15:18tromeyyes, there is a bug here with XHR and some other things
15:18tromeyin a meeting, I can explain later
15:18tromeyI forget the keyword to find the bug
15:19tromeyactually maybe this is &quot;backward&quot; from the bug I know about
15:21soletromey: it seems that eddy forgot to needinfo boris and so the help he needed from platform to do things right was never provided (and the bug unfixed)
15:23tromeyok, yeah, it is the event loop thing
15:32soleThe Event Loop: is back to bite you
15:32clarkbwthanks tromey!
15:32tromeyclarkbw: no prob; just to make sure I understand, it&#39;s going to be rebuild now and I can close the repack bug
15:33clarkbwtromey: this week, the answer is a rebuild
15:33solehehehe clarkbw
15:33clarkbwtromey: i don&#39;t want to make assumptions about next week though :)
15:33tromeysole: as I understand it, this is a problem in platform. however, it&#39;s difficult to fix. there were several talks between Eddy, jimb, and bz about the bug
15:33sole&quot;this week&quot;
15:33tromeysole: and there were some patches to add a warning that is printed when we trip over a code path that would have the bug
15:34tromeyalso there was some talk that multi-e10s (or one of these projects) might make the bug more tractable somehow
15:34tromeyclarkbw: ok, I can leave it open for a while longer, no big deal
15:35tromeyanyway, it&#39;s a serious problem :(
15:35tromeyit is super confusing when you are stopped at a breakpoint but your XHR keeps going
15:51soletromey: agreeing!
15:51tromeyI wonder if this was the concrete thing that the rust-based debug server was supposed to help with
15:51tromeynot sure
15:51tromeywe can ask jimb when he&#39;s around
15:52solenchevobbe: do you want me to approve the review and merge? or do you want to merge it yourself
15:53nchevobbesole: If you have the page open, you can merge it :)
15:54solenchevobbe: done!
15:54nchevobbesole: thanks !
15:55solenchevobbe: you&#39;re welcome! now you&#39;re ready to go for your friday with the satisfaction of a job well done!
15:58solemikeratcliffe: also rereviewed yours \o/
16:02mikeratcliffethx and thx
16:12wedrHmmmm.... Sounds like the breakpoint bug is probably not going to be fixed any time soon. :(
16:13tromeysadly no
16:14wedrAs I feared.
16:17gregtatumzer0: lol, nice review request
16:18zer0gregtatum: I was actually commenting the attachment, so wait a sec :D
16:18zer0(before reviewing)
16:18gregtatumzer0: sure thing, I&#39;m catching up on a bunch of reviews today anyway
16:22zer0gregtatum: done; I&#39;ve to go. Talk you later and enjoy the review!
16:22gregtatumzer0: enjoy your weekend!
16:45pbronchevobbe: ping
16:45nchevobbepbro: pong
16:46pbronchevobbe: am I right in remembering that one can test Reps independently, via launchpad, with a special page where you can input expressions, right?
16:46pbrodoes that also work with DOMElement Rep, in order to test the various modes, etc.
16:46nchevobbepbro: Yes :) All is in the readme
16:47pbronchevobbe: Awesome. I might do some changes, this willbe super useful
16:47nchevobbepbro: since you connect to a specific page with the launchpad, you can use document and evaluate what you want
16:48tromeyit&#39;s quite nice
16:48nchevobbeso, document.querySelectorAll would render a NodeList reps corresponding to your selector
16:48pbroyeah, that sounds great. I&#39;ve seen it, but I didn&#39;t remember exactly. And I&#39;ve never actually used it
16:48nchevobbeit&#39;s really super nice to use when you have Reps work to do, and that you don&#39;t need all the toolbox integration
16:48pbronchevobbe: the thing I might try to do is adding yet another mode for even shorter represnetations of dom elements
16:49pbroin cases where you don&#39;t have a lot of space, maybe use only one class if there are several, and maybe use an ellipsis in the middle
16:49pbroor maybe the tiny mode needs to support a max-length property or something
16:50nchevobbeThat would be nice
16:50tromeystrings have a &quot;crop length&quot;
16:51pbroah, maybe we should reuse that then
17:13clarkbwcan we include this add-on into the DE build?
17:13clarkbwor at least an add-on like it? doesn&#39;t have to be mine
17:13clarkbwI was about to send out email asking about this, but figure I should ask here first
18:20bkellydoes devtools have anything to debug appcache?
18:31jdescottesbkelly: looks like there is a command in GCLI
18:37bkellyjdescottes: thanks!
18:39jryansgregtatum: are there any compat issues with old servers for bug 1350503?
18:39firebot ASSIGNED, sharedLibraries return value is broken: &quot;Error: Server did not specify an actor, dropping packet&quot;
18:40jryansgregtatum: (not sure how much we can atm for profiler about that, but...)
18:40gregtatumYeah, let me chat with mstange about it
18:40mstangejryans: only the profiler add-on was ever using the sharedLibraries field
18:40mstangeso we broke compatibility with the old add-on
18:40jryansmstange: aha
18:40jryansmstange: well, sounds probably okay then
18:40mstangeactually we broke that compatibility when we renamed it from getSharedLibraryInformation to sharedLibraries
18:40mstangeyeah, I think it should be ok
18:41gregtatumthanks mstange
20:17wedrThere&#39;s a bug in the FF Developers Edition. Will be reporting it in Bugzilla, but I want to make clear one thing: Is the Github &quot;debugger.html&quot; the same thing as the stable released FF Dev Edition DevTools?
20:18wedrAnd it&#39;s very consistently reproducible on my end.
20:21jdescotteswedr: the debugger used in FF Dev Edition is GitHub&#39;s debugger.html. But it&#39;s not the latest version, so a bug you face in Dev Edition might have already been fixed on GitHub.
20:21wedrNo wonder...
20:21wedrThat&#39;s it, uninstalling FF dev edition
20:22wedrIt&#39;s of no use to me, thanks to this stupid inconsistent bug I JUST NOW FOUND OUT that it&#39;s not related to the breakpoints at all.
20:22* wedr is mad as ever.
20:24nchevobbewedr: Could you still report and give us the link so we can look how to fix it ? (or if it is fixed in the latest version of debugger.html )
20:32wedrSure, nchevobbe, Bugzilla or on Github?
20:32wedrI&#39;m trying to create a GIF, showing the issue.
20:33nchevobbeFile one in github we&#39;ll move it if it&#39;s a platform bug
20:33nchevobbeokay thanks
20:33wedrGot it.
20:45wedrI gotta leave work. :(
20:45wedrBye everyone.
22 Apr 2017
No messages
Last message: 154 days and 18 hours ago