Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 360 posts

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#51

Post by sisk »

Hey Paul. First off, thanks for reaching out to the community like this.

A few things:

Visualized event bindings. Would be awesome to have a visual indicator of event bindings right on the page. Color-coded bounding boxes drawn around elements with a label denoting the event type. Clicking on that box (or label in the case of an element with multiple bindings or nested elements with bindings) would direct you to the code that does the binding.

An aggregate repaint view. Chrome lets me view repaints but it clears after every one. If I have a method that is doing a lot of dom manipulation, I have to step through the code to view all of the repaints. Would be great to have the repaint bounding boxes drawn with a low opacity background so that I could see (and clear out) an aggregate view (with highly redrawn areas having higher opacity due to there being multiple layers).

An intelligent debugger that would automatically step over certain files (selectable per debugging session). I occasionally want to step into jQuery but less often than not. I know I can step over those methods but would be great if I could just keep stepping in without accidentally stepping into something when I don't want to.

I'll edit this as I think of more.

EDIT:

Breaking on navigation or on a particular request in order to manipulate headers. Breaking on the response from those requests for the same reason (plus manipulating the body).

The timeline and profiles sections in Chrome are under-utilized but infinitely useful. Anything close to those would be much appreciated.

Throw warnings for potentially orphaned event listeners. Granted, the number one offender recently introduced methods to address this (backbone's #stopListening) but it's still a easy mistake to make. This might bleed into too much hand-holding and open up a can of worms but just a thought.

Throw warnings for overloaded event listeners that fire a lot. Like the last suggestion, this may be heading in a direction you don't want to go in (educating the developer by means of the dev console) but, all too often, I find pages that overload, e.g., the scroll event. If there was some way to inform the developer of this potential problem, I think the web at large would greatly benefit. Perhaps this and the last suggestion would better reside in an auditing section?

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#52

Post by paulrouget »

rebelde wrote: post #40

Maybe this is provided and I haven't found it yet: - Rendering speed - show what slows it and what we can do to improve it. (Too many DOM objects, external files, redrawing?). Thanks!

We do have a profiler now (alpha stage in Firefox 21).

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#53

Post by olivierbeaulieu »

I work a lot on a Firefox extension, and honestly, the absence of dev tools for addons is really painful. Developping our extension for Chrome was super easy, since all their default devtools work in extension panels as well, but in Firefox it's been a nightmare, almost no tools. We are left off in a console.log madness trying to figure out what's causing bugs.

It would be soooooo awesome to have Firefox's default devtools working easily in extension panels!

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#54

Post by gcp »

[deleted] wrote: post #43
paulrouget wrote: post #11

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]

How exactly does this help web developers?

This has been considered and rejected as inferior to the current approach. The Android browser used this and it was rewritten to get rid of it.

Let's focus on doing things that improve the user experience rather than blindly copying features from other browsers without considering if they make sense.

Moreover, it has absolutely nothing to do with the question asked.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#56

Post by paulrouget »

timme wrote: post #32

Make the native 'Inspector' tool go away. Accidentally opening that thing (because they're next to each other in the context menu and the labels are similar) instead of Firebug is infuriating.

There's an option in Firebug to disable the inspector button.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#58

Post by steffoz »

oneandoneis2 wrote: post #47

I have to be honest - I find the developer tools a pain: They aren't even close to replacing Firebug, yet they're more obtrusive. So I can't stop using Firebug, and I can't remove the unwanted built-in menu options. So for me personally, what I'd really like to see is either one of: - Match Firebug feature for feature - Allow for the dev tools to be completely removed from the interface Sorry, but it really does come…

Couldn't agree more on this.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#59

Post by mixedbit »

Would it be possible to make JS lint available in Firebug? Preferably in such a way that all scripts included from a currently opened site are automatically linted?

At the moment I go to www.jslint.com to lint scripts, which is such a PITA.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#60

Post by EGreg »

I'm glad you asked! This is a good time for me to bring up something I wrote two years ago:

http://news.ycombinator.com/item?id=2024164

I really wish browser makers would do this! Mozilla can lead the way.

I am going to post it here for ease of reference:

1) I propose a simple mechanism to guarantee that a resource located at a certain URL is always the same. Similar to how we have https:// blabla, and the user agent warns us if the server's certificate is not trusted, we should have httpc:// blabla to indicate constant resources. Sites all over the world can download resources from httpc:// urls and store hashes to them in various formats, and your user agent can trust one or more of these authorities. When downloading, it would compare the hashes against the ones downloaded from these authorities, and if there is even a small deviation, it would give you a warning just like https://

This must be done by the user agent. Right now we do have "cache control" headers, but I am talking about the server making a promise to the world that a page is really truly static, and user agents having the ability to verify that. This is different from server-controlled caching.

I can see this being used in app stores for the web (curating apps and various versions of apps, like Apple does) and also for secure logins. I would like someone to make guarantees that my password is not being sent in the clear to the server that I am connected to. Right now, the web forces us to trust a remote server completely, when interacting with a website. For example, when I enter a password, I have no assurance that the server won't misuse it. (See http://xkcd.com/792/)

This simple change would make possible a variety of applications that we haven't even thought of, besides these two.

2) The second proposal is to have iframes that are on top of everything else in the containing window, no matter what. That would enable 3rd party logins (such as OAuth) do be done in the iframe, without worrying about clickjacking. The javascript inside the iframe should have a way of checking whether the iframe is of this type. At most one such iframe can be shown in any given window.

This would lead to much more pleasant interfaces, and once again, the user would receive the extra protection. Of course, this means that Flash and other plugins would have to play nice with this. We could implement this rather easily with a browser extension that causes a borderless window to appear (like Flash does) above the actual browser window.

Thoughts?

Post reply on HN