bgrins

Good luck! FYI, there's a hidden developer menu that's handy for browser developers to change the number of iterations, select specific tests, etc: https://browserbench.org/Speedometer3.0/?developerMode, and ?startAutomatically avoids needing to click the button to start the tests.

I worked on this project - Web Components had a lot to do with it. It's true they weren't feature complete in Firefox when we started the project (notably missing Shadow DOM) - but the first migration from late 2017 was XBL->Custom Element (https://bugzilla.mozilla.org/show_bug.cgi?id=1500626), and we used the migration project to inform performance and feature work for Web Components within Firefox.

We could have converted the bindings to JS modules (and we did plenty of that too), but Web Components were key because they allowed us to migrate in-place with near API compatibility rather than rewriting the UI. I have a post at https://briangrinstead.com/blog/firefox-webcomponents/ with more detail on that point.

There are pros and cons to using web tech for the application UI. To be clear, the old XBL code was already using JS/DOM, so the most obvious pro in this case was that it didn't require completely rewriting Firefox from scratch (which hasn't historically worked out well). I also expect that dogfooding web technologies means we can improve the tooling and web standard implementations in Gecko.

Regarding performance, this work didn't regress anything. Performance is measured on every commit and staying at least at parity was a requirement for the project.

you now need to right click in the console and tick "Log request and response bodies" every single time

Yes, seems like there could be a pref for that. Filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1064458.

The eyedropper is using a panel with a call to openPopupAtScreen to open it (http://dxr.mozilla.org/mozilla-central/source/browser/devtoo...).

I'm not sure exactly in what ways this is failing, but please file a bug under "Developer Tools: Inspector" if you have STR and we can try to narrow it down: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox.

Thanks for the link. What about IndexDB, Web SQL and Local Storage?

Not yet, but a storage inspector panel is being worked on: https://bugzilla.mozilla.org/show_bug.cgi?id=970517

A storage inspector is not part of the tools yet. Some of the functionality for this has landed, but the frontend is still being worked on here: https://bugzilla.mozilla.org/show_bug.cgi?id=970517.

I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=987877 for adding a Copy XPath menu item in the inspector

Thanks for the info. What are you wanting to do with xpath? The console supports the $x function, like $x("//body"). Also, HTML node drag and drop is on the radar here: https://bugzilla.mozilla.org/show_bug.cgi?id=858038

It's mostly JavaScript. Take a look at https://wiki.mozilla.org/DevTools/GetInvolved and https://wiki.mozilla.org/DevTools/Hacking for more information

The contrast for the selected node in the markup tree is being updated here: https://bugzilla.mozilla.org/show_bug.cgi?id=968315.

This feature is being worked on, and is close to landing: https://bugzilla.mozilla.org/show_bug.cgi?id=663778

Yes, the current dark theme does not have high enough contrast. There is a bug opened to switch to higher contrast colors in the dark theme here: https://bugzilla.mozilla.org/show_bug.cgi?id=971418 (and this will likely be uplifted to Aurora after landing).

There is also a work in progress to add a better interface for inspecting storage (including cookies): https://bugzilla.mozilla.org/show_bug.cgi?id=926449

At least in current Nightly, you can hit the Esc. key, to pop up the console regardless of the panel you're currently using

This split console feature landed in 28 (so it is moving up to Beta now): https://hacks.mozilla.org/2013/12/split-console-pretty-print...

Audio processing works, but certain codecs do not come bundled with it. It should be possible to configure it with --enable-libmp3lame if you had the source alongside and had everything set up correctly. We didn't have time to try this, but the closest thing I found similar to this when researching was: https://github.com/manuels/unix-toolbox.js-imagemagick. You can see that libpng, libjpeg, etc are all being included in the output.

If you'd like to give this a shot, definitely open up an issue on Github and we can talk more about the details!

Thanks! It will be interesting to see how much it will speed up as JS runtimes get faster, and as we are able to apply additional optimizations with Emscripten.

In particular, asm.js is explicitly disabled right now because of the need for memory growth. In the meantime, I'm planning on having a build with it enabled just to benchmark times on smaller files (where the growth is not needed).

Here are the mock ups: https://people.mozilla.org/~shorlander/mockups/devTools/ux-r...

Regarding theming, here is a bug that can be followed for updates: https://bugzilla.mozilla.org/show_bug.cgi?id=916766.

Here is the bug for the "Edit as HTML" feature: https://bugzilla.mozilla.org/show_bug.cgi?id=895561.

Here is a way to fix this: https://gist.github.com/bgrins/5108712. When you call `log` it will preserve the line number.

Here is a demo: http://jsfiddle.net/bgrins/MZWtG/.

Remote debugging is so useful: http://www.igvita.com/slides/2012/devtools-tips-and-tricks/#.... It is painful to try and make and test changes on mobile devices without developer tools.

I wonder when this will be available for iOS.

If you end up adding IE support, check out this hack to get multi-stop gradients in IE for the hue slider: https://github.com/bgrins/spectrum/blob/master/spectrum.css#...

Neat project, I just got done doing the 10K Apart contest and this would have saved me a lot of resizing when testing different widths!

http://www.w3.org/TR/CSS2/box.html#margin-properties

When margin top or bottom is a percentage, it refers to the width, not height, of the containing block. If the parent is 100% width (say, the body), the element will move down 50% of your screen width.

Usually, you don't want this, but you can use it to do some cool tricks with keeping the aspect ratio of an element, like this: http://jsfiddle.net/bgrins/999FP/

I really like that visualization! It would be awesome to see that same visualization side by side with Dijkstra's algorithm (same as astar, but with fixed heuristics) to see how much better it can perform.

Hey Matthew, great job on this! I had fun learning this algorithm, too. My implementation is here: https://github.com/bgrins/javascript-astar/blob/master/astar..., and I have a demo here: http://briangrinstead.com/files/astar/

I have added in a few optimizations: in my first run at it (https://github.com/bgrins/javascript-astar/blob/master/astar...) I used a standard array for the open and closed lists, and I found it slowed down quite a bit as the graph size got larger. I switched the implementation to a binary heap, which made it much faster for larger graphs. Try the original demo then the new one at 100x100 to see what I mean :)

Awesome! There are some really things you could use this for. I have done something similar here: https://github.com/bgrins/DrawWindow

I'm interested to look through the source and see how this was implemented. There are many things that are really tricky to handle using the computedStyle way of rendering HTML. Just to name a few:

* Form elements

* Dotted, dashed, rounded borders

* Gradients

* Text with word-wrap: break-word applied (for some reason measuring each character does not work properly here).

* CSS Outlines can be tricky, though I have gotten that to work pretty well in my implementation using getClientRects().

* Overflows / scrolls with fixed width or height divs (and nested ones)

* Iframes

For basic text and images (such as http://bgrins.github.com/DrawWindow/tests/basic.html) it holds up pretty well.

I have thought about the two window browser IDE before and am glad you implemented that idea, I think it could be really useful for quick HTML/CSS comps.

Two small suggestions:

* When in the two window mode, make ctrl+s do an instant refresh on the preview, and preventDefault on the event so that it doesn't open up the browser save window. I save constantly out of habit, so that gets distracting.

* For the 'inspect element' control: Don't use borders on the active element, because it causes the layout to jump around and if you already have a border applied to an element, it wipes it out. The easiest way to fix this would be to use 'outline' instead - and if you apply it with a class instead of inline styles, it will not wipe out existing outlines after leaving (as it does with borders now). If you really want to make it work to not replace existing outlines, see the 'Firebug.Inspector.BoxModelHighlighter' in http://code.google.com/p/fbug/source/browse/branches/firebug... for an implementation that uses completely different elements instead of changing the style of the active element.

Nice, I have noticed the same thing when working with canvas - any time you can get the pixel level manipulation to happen in native objects there are big performance gains to be had.

I am interested on the general idea behind your new import an existing site feature. I have played around with this a little bit before, and realize that there is no way to directly render HTML onto a canvas (unless of course you have add on permissions in firefox, like this: https://developer.mozilla.org/en/drawing_graphics_with_canva...). Then of course there is something like this: http://www.cuppadev.co.uk/projects/a-browser-within-a-browse... which seems a little incomplete.

I assume you build up the elements array from the elements in the DOM, and manually generate a canvas for each one? That seems like it would be quite tedious, and handling inherited styles, etc could be a pain. Also, once you start moving elements around, they may not really have a place in the HTML anymore, so if I want to share the mockup, is it just an image, or does it become absolutely positioned HTML elements?

Great job on this by the way, I'm impressed with how well it is working.

For a tiled repeating background, I would recommend looking into createPattern function https://developer.mozilla.org/en/Canvas_tutorial/Applying_st....

You can use code like this:

    context.fillStyle = context.createPattern(img, 'repeat');
    context.fillRect(0, 0, 100, 100);

If this doesn't work in your situation, I would at least build this image once in a canvas in memory (using document.createElement), and reference it in the 'drawImage' function instead of building it from scratch each time. Though it sounds like you might already be doing this. Do you have a link to your game?