731815 - XUL level inspector / debugger?

Status: RESOLVED WORKSFORME

(DevTools :: Inspector, enhancement)

Description

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

For Test Pilot studies, I find the major blocker for creating new studies is trying to figure out:

1) names of the elements on a page (Chrome layer)
2) what actions are triggered on them during 'activity' sequences.

To solve the former, I can use DOM-Inpsector, MXR code archaeology, or asking people.  All of these methods are non-scalable and error-prone.

I would like a tool (and am quite happy to dive in!) to solve this in some way.  Other beneficiaries are UX, addon developers, and testing.

As a motivating example, consider this study:  "How do people go 'back' a page?"  Test Pilot makes it easy to watch for events in the chrome layer, if one can figure out what they are.  Here these include:

*   clicking on back
*   back in the right click menu
*   swipe left (osx, other guestures on other platforms)
*   actions of add-ons
*   History > back  (menu)

My fantasy project would allow the study builder to *do* each of these actions and see a log appear somewhere with the names of what happened.  For me, no other UI is needed.  Ideas of for doing this are welcome :)

Comment 1

[Blake Winton (:bwinton) (:☕️)]

As a related question, what are the problems with running the current devtools on chrome-level stuff?  (I saw a screenshot from robcee, but he suggested it was unstable, or at least untested…)

Comment 2

[Josh Matthews [:jdm]]

I just tried opening chrome://browser/content/browser.xul and running the fancy new inspector tool, and it appeared to work just fine.

Comment 3

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

(In reply to Josh Matthews [:jdm] from comment #2)
> I just tried opening chrome://browser/content/browser.xul and running the
> fancy new inspector tool, and it appeared to work just fine.

I made the CSS tools work with external xul a few weeks ago.

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #1)
> As a related question, what are the problems with running the current
> devtools on chrome-level stuff?  (I saw a screenshot from robcee, but he
> suggested it was unstable, or at least untested…)

I don't see any issues with simple inspection of chrome level stuff, we would "just" need to attach the appropriate listeners to all chrome windows ... to have the tools running in other apps is a bigger issue because development in toolkit is more complex than in browser and would slow us down.

Comment 4

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

to jdm, 

That is a good intermediate step.  Unfortunately, opening "chrome://browser/content/browser.xul" doesn't quite give a reflection of how the browser actually looks (at least for me!).  Things also break down a bit for elements that require clicking to expose (menus for example), where the best way seems to open the HTML representation, and explore.  

As a particularly gnarly motivating example... what do I instrument to see whether a user accepts one of the suggested searches in the search box (i.e., they type into:  searchbar#searchbar, they type, then go down and select something).

I love the inspector, btw :)  The visual nature of it is aweseome!  I just worry that because it intercepts clicks, and creates visual ui, it might not be the best way of doing this "instrument everything" task I am begging for :)  I propose "dump"s of 'event stacktraces' :)

Comment 5

[Paul Rouget [:paul]]

The inspector can now inspect XUL windows.
The debugger can also debug Firefox and Chrome documents.

The UI is missing thought, but this is another bug.

Comment 6

[Paul Rouget [:paul]]

See bug 816325 for next steps.