Feedback for devtools team

[Mike Taylor]

We discussed gathering feedback for the devtools team during our work
week. I figure we could kick off that discussion here and pass along
prioritized feedback or requests.

The number #1 request from me is the ability to actually remote debug
webpages from within the Firefox OS browser. I've filed
<https://bugzilla.mozilla.org/show_bug.cgi?id=975084> to this end.

Anyone got something to add?

--
Mike Taylor
Web Compat, Mozilla

[Karl Dubost]

Hi,
mike thanks for starting this devtools feedback list.
I have sent this to individual in the past, it would be interesting to dig if there are bugs for them and create new ones if none or if it has been implemented since.


# Un-minified JS crazy renaming

Once the JS has been un-minified, the possibility to change the value of a variable and/or function.

Use case: When a JS is minified, sometimes the variables and functions names are called things such as a, b, c, etc. which makes it harder to read the code.

What the feature does: If for example a function is called "a", I can select it anywhere, somewhere in the code, rename it "a_better_name" and it will change the value everywhere in the code where it has been used. (it should warn if the name is already taken).


# Select a piece of code and share

When selecting a piece of JS, DOM, CSS, etc. Having a possibility to send this selection to an online gist of your choice (or stackoverflow) or send it by email or save it locally directly from the browser.


# Inline Documentation

On selecting a DOM element, a JS feature, a CSS property, having the possibility to have a link to the spec for this specific feature and/or a documentation explaining the feature. Basically it is a continuation from "View Source" to "Learn in Context".


# SVG, use elements and Graphics

When inspecting SVG files, give the possibility to explode the graphics into its constituent. See the source code of http://www.la-grange.net/2012/03/08/odevrel/index Basically an "exposé" view of all defs and maybe a graph relation in between the use and the defs.


# HTTP Network traces

Export the HTTP traffic with the HAR format. So you can send a trace to someone.
http://groups.google.com/group/http-archive-specification/web/har-1-1-spec?hl=en



# Flexbox selector

When a CSS is using Flexbox, having a view which gives the different boxes with handles that you can resize, move around, etc. The CSS being modified live and exportable for reusing in your own project.


# Screenshot of the full page

A feature to take a full screenshot of the page, not only the one shown in the window.


# Metadata (Microdata/RDFa) View

A way to explore and have a graph, table view of all metadata contained in that page. It would probably show also things like title, rel/rev values relationships. etc. Basically the meaning hidden in the markup.


# HTML, CSS Code analyzers

Notifications, flagging of:

* duplicate CSS rules
* unused selectors (with no matches)
* Empty CSS rules
* Show properties/elements spelling mistakes


# Conversion of rules

If CSS rules are only expressed for one browser but with no equivalent for Firefox, get the possibility to have a fixer that will create the equivalent CSS for a selector and to export it in an email to share with someone else. Infamous example: flexbox. old/new syntax.


# Sharing a DOM in between two browsers across the network

Mike is in USA, Karl is in Japan. They are working on the same project and want to code together and explain some bugs (and they cope with the time zone ;)). Their Developer tool environment is paired across the network and so they can have a kind of "Etherpad Developer tool" where modifications are visible on both side.

I'm pretty sure they could have a console for chatting about the bug too. P2P Feature that people would probably just used for chatting at a point.


# Versioning of your modifications

When debugging a DOM or something, you might want to be able to version your modifications. So you can come back a little bit backward in your modifications when working directly in the Developer tools.


# Identify Missing CSS prefixes

When someone is using CSS Vendor prefixes, and not showing certain prefixes for other vendors or worse not having the unprefixed fallback, making a notification in the CSS view.


# Code Syntax Highlighting themes

Having the possibility to choose a specific highlight syntax theme.


# Search by Selectors, XPath, regex

Having the possibility to search the DOM by one of these, Search by selectors, XPath, regex. See Opera Dragonfly. Extremely practical.

Bonus: Look ahead. Aka when typing the XPath or Selector Path, having a list of all paths ahead which will be available. So to guide the person to make the right choice.


# From DOM to XPath/CSS Selectors

Selecting an element in the DOM and having the possibility to copy its XPath/CSS Selectors Path.


# HTTP client for crafting requests

When testing a Web site and exploring the different answers you might receive in the browser it is useful to have a possibility to craft an HTTP request and saving profiles of these requests. For example, one personal profile could be

HTTP/1.1 GET /foobar
Host: example.org
User-Agent: FuckYeah/1.0
Accept: application/xhtml+xml

And later on, you could reuse it. Useful when you are testing how a Web server reacts to modifications of different headers such as User Agent Sniffing.



# Profiles to link to physical files.

Something there are projects where the CSS is a physical files. Being able to link to them and remotely modify them can be an asset. But it might too much of a niche feature. Not sure.

"Love tweaking CSS in Web Inspector. Wish I could link it to the physical CSS file to save changes *adds to TODO list*" –http://twitter.com/jaffathecake/status/105994051630796800


# HTTP full trace view

Sometimes it is good to be able to see what is going on on the wire. ala

curl -I --trace-ascii - http://www.mozilla.org/
curl -I --trace - http://www.mozilla.org/


# HTTP POST request editor

When creating a POST request to test something, being able to create a "key, value" table of what we want to send. either from scratch or pre-built from exploring a page containing a FORM.



# Faking Geolocation

When debugging sometimes you need to fake the geolocation information, so the server thinks you are elsewhere than you really are, to have the specific view for this geolocation.

--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Hallvord R. M. Steen]

Now, now.. I personally don't want any of Karl's amazing features implemented until they've made the existing tool *rock solid* and bug-free!! Especially the JS debugger.. It seems to never work quite like I expect it to. Just now, for example, I tried to use it from Nightly on desktop to debug m.fisher-price.com in Firefox beta on Android, I saw in the error console that some "g is undefined" error was thrown and wanted the debugger to stop there so I could find the code that caused the exception. Enabling "pause on exception" stopped on plenty of other stuff, but the error I wanted to look at was printed to the console *without* the engine pausing there. And yes, I made sure "ignore caught exceptions" was un-checked (although it going to the console sort of made it likely that it wasn't a caught exception in the first place).

I keep seeing it failing to pause on breakpoints after a reload. (This is also when trying to debug remotely). Maybe I have to use Nightly on desktop with Nightly on the phone? This is very basic stuff. It MUST be bug-free. :-/

I think I should talk to the devtools team directly and figure out what version matching they consider most stable, then see if I can reproduce problems with that combo of desktop and mobile versions. This sort of feedback is probably better delivered as bug reports..

Small feature request though: once in a while we get a console error saying that the page has disabled the window.console API. Could that error come with a small "restore" or (even better) "disallow disabling the console on next load" button?

Oh, and I agree with Mike that debugging the Fx OS browser is a must.
-Hallvord

PS: Karl, I don't mean to pick on your amazing wishlist - just a bit annoyed because I never get to the point where I actually trust that debugger..

_______________________________________________
compatibility mailing list
compat...@lists.mozilla.org
https://lists.mozilla.org/listinfo/compatibility

[Mike Hoye]

On 2014-03-03, 7:23 AM, Hallvord R. M. Steen wrote:
> Now, now.. I personally don't want any of Karl's amazing features implemented until they've made the existing tool *rock solid* and bug-free!!

I'd be happy to see a nuanced discussion about what "good enough to
ship" means, but "don't work on new things until the old things are
bug-free" is a guarantee of market irrelevance.

It's hard to believe Mozilla (or Google, or Apple, or anyone who makes
any nontrivial piece of software) would ever ship anything to anyone
ever, if held to that standard.


- mhoye

[Lawrence Mandel]

Top posting because there are lots of great suggestions below.

My contribution: Longer term I would like to see the tools flag compatibility issues as warnings for devs. For ex,
1. the use of a single vendor's prefix on a CSS property without an unprefixed version
2. the use of frameworks with known compatibility issues
3. the use of outdated frameworks

Given how many suggestions have been listed I suggest that we create a prioritized list of our requests and then review them with the dev tools team.

Lawrence

----- Original Message -----
> Now, now.. I personally don't want any of Karl's amazing features implemented

[Karl Dubost]

Lawrence,

Le 13 mars 2014 à 00:09, Lawrence Mandel <lma...@mozilla.com> a écrit :
> 1. the use of a single vendor's prefix on a CSS property without an unprefixed version

Created
https://bugzilla.mozilla.org/show_bug.cgi?id=982970

> 2. the use of frameworks with known compatibility issues

Hmm this is a bit harder. How do you propose it would be working?
There is a out-of-the-band maintenance issue too.

> 3. the use of outdated frameworks

Same questions.

> Given how many suggestions have been listed I suggest that we create a prioritized list of our requests and then review them with the dev tools team.

When we have a clear description, I think we should open individual bugs and indeed proposed a list of priorities for us (on the wiki? on bugzilla?). We may even be able to propose patches if it helps accelerate for the ones which do not modify the global architecture of the products.

[Lawrence Mandel]

----- Original Message -----
> Lawrence,
>
> Le 13 mars 2014 à 00:09, Lawrence Mandel <lma...@mozilla.com> a écrit :
> > 1. the use of a single vendor's prefix on a CSS property without an
> > unprefixed version
>
> Created
> https://bugzilla.mozilla.org/show_bug.cgi?id=982970
>
> > 2. the use of frameworks with known compatibility issues
>
>
> Hmm this is a bit harder. How do you propose it would be working?
> There is a out-of-the-band maintenance issue too.

This would be a case where we have already done the investigation and know of a compatibility problem that has been fixed in a later version of the framework. In this case we can flag version x and lower as problematic.

>
>
> > 3. the use of outdated frameworks
>
> Same questions.

This is tougher. As you said, we need a way to update this out of band. Perhaps we can have a scraper that pulls this information automatically. But, this is probably not something that we want to take on without some real thought to the maintenance cost.

>
>
> > Given how many suggestions have been listed I suggest that we create a
> > prioritized list of our requests and then review them with the dev tools
> > team.
>
>
> When we have a clear description, I think we should open individual bugs and
> indeed proposed a list of priorities for us (on the wiki? on bugzilla?). We
> may even be able to propose patches if it helps accelerate for the ones
> which do not modify the global architecture of the products.

Yes. Let's file the bugs.

Lawrence