121–130 of 360 posts
Thanks for doing this post! Some things I'd like to see: * Less UI chrome. The blue bar doesn't need to be blue and element breadcrumbs don't need to be fancy styled boxes. Large elements don't even fit in them and get chopped off. * When I hit Ctrl-Shift-I the FDT open, but if I have the dialog detached it immediately loses focus and I have to alt-tab to see it. * I find Chrome's Network inspector to be very useful…
This is a big request: Improve "design in the browser" capabilities. i.e. pushing CSS/HTML and maybe JS changes made in Dev Tools back to the source files without manual shenanigans in the middle. I probably waste more time copying CSS / HTML tweak diffs from the browser back into the related source files than anything else with in browser dev tools. Due to the nature of 'losing changes' if I happen to hit refresh or…
+1. I can't even add an element directly in the Chrome dev tools - you can only edit an existing elements HTML and append something after it. My kingdom for a '+' button.
Right click on an element and choose "edit as HTML" and you can add whatever you want, granted it offers no reasonable formatting, its just a wall of text, not even tabs / line breaks.
It is also broken in that when you do this Chrome rebuilds all the sub elements of what your editing so if there were event hooks or anything like that on the elements they will be gone.
Earlier quoted context omitted.
We already have a team working on memory consumption (and we already made some gigantic progress). We also have a team working on improving addons APIs (see the new builin SDK). We are also looking at existing extensions.
[deleted]
I don't see it on the roadmap but the firefox console is SO terrible at printing objects. In most apps I work on I'm shipping around 2kB+ JSON objects and the current console is absolutely worthless for these.
Related, but I think there's room for improvement in object printing in general. I find myself not really caring about most fields in an object but I'd like a couple fields printed inline before expansion. I like that the firebug console prints a few fields with the option to expand objects but would like to have control over which fields those are. FWIW, my preferred pretty printer is node's.
I find CSS errors/warnings to be absolutely useless in both the firefox dev tools and opera's. Pretty much any modern site is using vendor prefixes and the result is hundreds or thousands of errors which makes the console fall over.
Due to the above, I've been taking the approach of trying dev tools out again every time Aurora updates and then going back to using firebug and chromium after 15 minutes or so. I completely missed the jsterm addon despite following you on a couple channels. It looks reasonable so I'll be giving it a go today.
When you're doing your network cascade panel, please set it up to load HAR files. You can get HARs from a variety of sources but there isn't (yet) a convenient way to view them locally.
For the debugger, I don't know of an equivalent of webkit's source view cmd+o / cmd+shift+o, which are extremely useful. The cmd+p filtering is decent but most of the time I do actually know what file and function I'm looking for. I also use the reformat button and break on caught/uncaught exceptions on a regular basis. Actually, now that I think about it, I use every single function except for the editing functionality on the chromium sources panel at least once a week.
For the style editor, the side list of stylesheets isn't mousewheel scrollable on my machine (I'm on Aurora).
I find dock right to be the most useful attached view for chrome tools. Screens (and particularly laptop screens) are wider than they are tall and dock right takes advantage of that.
Edit: For a larger feature, I would very much like the ability to edit code when the browser hits an exception and then continue execution using the new code. I've only seen this in smalltalk demos so I assume it's difficult but being able to flip a variable to tweak an if statement when stepping through the debugger saves the effort of getting back into the correct state from pageload.
Honestly, the absolute best thing you could do for any dev, is lighten the footprint FF currently has on my ram, and continue to improve the api for add-ons/plugins. The more stable, extensible and fast FireFox is, the more useful I will find it for development. But if more kludge is added to it, and it continues to get slower/bigger, the less likely I am to continue to use it, regardless of what amazing plugins are…
I thought that the latest browser tests showed that FF used less ram than Chrome. http://lifehacker.com/5976082/browser-speed-tests-chrome-24-... Unfortunately, reputations stick.
Maybe there's a different way to do it, but I haven't found it yet.
Earlier quoted context omitted.
My understanding is that Firebug is discontinued from Mozilla's side (which means nothing wrt any volunteer effort ongoing there, btw!), but they assist in keeping it alive on Firefox updates because the native tools don't have the same functionality yet.
Our team also work on Firebug. So no, it's not "discontinued". We are working on sharing more code. In an ideal world, we will be able to merge these 2 tools in the future.