bgrins

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.

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.

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

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.

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

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...

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

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).

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

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

I wonder when this will be available for iOS.

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 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 :)

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.

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.

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.

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?