Looking for "Expand All/Collapse All" option in firebug, on the console page.

[21st-schzman]

The main use case behind this enhancement request is a listed limitation in the firebug Export extension, which indicates that expandable log message information will not be exported to file unless each expandable log message is expanded prior to export.

There may be other use cases for having an 'Expand All' capability on the console page.

Please see detailed test case below.

CURRENT VERSION:

Firebug Version: 2.0.8
Browser version: Firefox 36.0.1
Operating system: Microsoft Windows 7 Enterprise, 6.1.7601 Service Pack 1 Build 7601

NOTE: Understand that future enhancements will be done a future release, not 2.0

TEST CASE:

Steps to reproduce

1. In firebug, select the [active] console page.
2. Select an expandable log message, and right click.
3. Mouse over 'Expand All/Collapse All' to get sub-menu with an 'Expand All' and 'Collapse All' option.
4. Select 'Expand All' to expand all current expandable log messages in console.
5. The default 'Collapse All' should now be deselected (no check mark), and 'Expand All' should now be selected (check mark).
6. Also, any future log messages should be automatically expanded with 'Expand All' enabled.
7. Follow the same steps as above to re-select 'Collapse All', to collapse all current and future expandable log messages.

Observed result
NO 'Expand All/Collapse All' option available on console page

Expected result
'Expand All/Collapse All' option available on console page, as described above

[fflorent]

What kind of logs should be covered for this?

• console.error/exception
• console.group (already expanded unless you use console.groupCollapsed)
• console.trace (already expanded AFAICT)
• console.dir (idem)
• console.dirxml (not yet implemented in DevTools)

Thanks in advance

Florent

[21st-schzman]

Hi Florent,

I would think that all message/log types that are not currently expanded when generated in the console log window could be supported by this feature enhancement.

What is primarily driving my enhancement request are HTTP requests, specifically, all HTTP transactions controlled by the Show XMLHttpRequests knob. HTTP requests are not currently expanded when generated in the console window. Each message has to be expanded individually.

Let me know if any of the above information is not clear, or if you need any additional information.

Thanks,

Rich

[fflorent]

Hi Rich,

So basically, your need would be to expand all the requests.

The thing is that if we expand automatically the objects, we would have memory and CPU issues (expanding properties leads to fetch information to the back-end through the Remote Debugging Protocol). I don't know if that is included in what you have in mind, but I don't think we can implement that.

However, for the XHR requests in the console, that should be doable. For this, we would either introduce a new option in the (so it is referenced in the Options panel), and then clutter more for this specific feature, or create a new hidden option (in "about:config") and then we wouldn't offer much discoverability for this feature.

So I am a bit embarrassed.

Florent

[21st-schzman]

Hi Florent,

If pull down menu real estate is a concern, then my belief is that users would be happy with a console api like console.expandRequests 0|1, with default 0.

0 == all requests collapsed
1 == all requests expanded

Is there any limitation on when such a setting would take affect? Would the setting apply to only to future requests, or can/should it apply to all requests already in the console log view, in addition to future requests? Thoughts on this point from am implementation standpoint? From a user point of view, in my opinion, expanding and existing and future requests would be most useful.

Also, with regard to feature exposure, as long as the property is published in the console API, my thinking is that a published API is sufficient. If someone needs it, they will find it with a proper search. This has been experience in similar situations.

With regard to not applying this feature to areas where scalability (cpu/memory usage) is a concern, then those are certainly valid concerns, and you right to raise them. I agree that it would not be a good idea to implement in those areas.

So does an 'expandRequests' console api sound like a good plan?

If so, would you like for me to rewrite the test case to reflect as such?

Thanks,

Rich

[fflorent]

Hi Rich, Sorry for the late reply. Exposing it in the console API has a major drawback : you expose the choice of expanding the requests by default to the Web page, whereas it is up to the user to decide it. I am thinking about an option in the context menu of an xhr log, that would allow to expand them all and the future ones. Also I am wondering about a real world use case. Do you have one? Also I reread your first message, and I may not have understood something : is that for the export or the live-display in the Console you want that feature? Florent

[21st-schzman]

Hi Florent,

Understood with regard to not wanting to expose the API. I do see your point with restricting it to the tooling only, via a menu option. If you can find a place to put it without over-subscribing the menu real estate -- great!

The use case is for gathering a bunch of requests in the console, expanded all of them, and then saving to file with the export plugin. This way, maximum possible dataset is saved for later analysis. The application is within UI unit test/QA workflow, where issue re-production with full data collection is required.

Example 1: Developer (or Tester) needs to reproduce an issue where requests are flying at high rate, and the only hope making sense of things is log all requests with the full dataset, and go back and look at it. Having the full request dataset in the log allows for later diagnosis independent of the reproduction environment state. Also, full data set in a log allows for offline tools to parse the log file (grep, or other tools), and for documentation/archival of the issue.

Example 2: Tester A is reproducing an feature issue for the feature developer B, feature developer B likely needs full start to finish logging with full data from issue reproduction, for issue diagnosis. Developer look at the required data maybe separated by time and/or geographically.

To specifically answer you question, this feature is for export of console data.

Thanks,

Rich

[21st-schzman]

Hi Florent,

What is the latest on getting this request into the enhancement stream? Do you need any additional information from me?

Thanks,

Rich

[fflorent]

Hi Rich,

Again, really sorry for the late reply.

Example 1: Developer (or Tester) needs to reproduce an issue where requests are flying at high rate, and the only hope making sense of things is log all requests with the full dataset, and go back and look at it. Having the full request dataset in the log allows for later diagnosis independent of the reproduction environment state. Also, full data set in a log allows for offline tools to parse the log file (grep, or other tools), and for documentation/archival of the issue.

Something that wasn't clear to me before (but that was my mistake) is that your enhancement was related to the Console Export feature. To me that sounds reasonable. @janodvarko thoughts?

The next steps is that we need an implementor. On Firebug.next, we're mostly busy at reimplementing the previously existing features. If you are interested in contributing, we can provide some assistance. Just tell us :).

Florent