copying rather than having to select and copy each error separately. :-)
jsdebugger != jsconsole, over to hewitt.
Oops, sorry. Thanks for re-directing. As an additional comment, any sort of
multiple-selecting would be good. (Shift-click, Ctrl-click, etc)
reports against a site, relying on them to copy and paste the relevant messages
is not possible.
For security it is probably necessary to store the source domain with the
messages (and filtering those not relevant to the current page).
*** Bug 315896 has been marked as a duplicate of this bug. ***
It seems this bug is more about 'copy all' than 'select all' (see dupe).
*** Bug 481255 has been marked as a duplicate of this bug. ***
Going to take a stab at this...
Created attachment 365388 [details] [diff] [review]
Throwing this up, this is what I got to so far, still have a ways to go to get the string copying working and keyboard stuff (which fyi doesn't work).
More to come later this/next week.
The Console² console binding inherits from richlistbox which inherits from listbox so we can just do:
Perhaps instead of trying to reinvent the wheel why not explore making the console box inherit from richlistbox? Then you get all the multiselect and copy functionality for free.
<command id="cmd_close" oncommand="closeWindow(true)"/>
+ <command id="select_all" oncommand="selectAll()"/>
For consistency you should use "cmd_select_all".
+ <menuitem label="&selectAll.label;" accesskey="&selectAll.accesskey;"
+ id="menu_select_all" command="select_all"/>
Both Firefox and SeaMonkey use "menu_selectAll". In addition for the context menu item the Suite uses "menu_selectAll_cm". The latter fits in with the existing context menu item in the Error Console:
Thanks for the reference and tips, I'll be including those in the next patch!
I'm making some good progress on revamping the error console entirely, I'll attach a wip patch hopefully this week. Part of the refresh will include this bug, among others.
Pushing out old bugs that I won't have time to actually get to. Feel free to use/extend any patches attached...
Created attachment 569758 [details] [diff] [review]
I took Nochum's patch and reworked it a fair amount. I took out the keypress stuff he had since I don't think it was working anyway (I may have just broken it in the process of changing). Honestly I don't think we should have that anyway. Multiselect is inconsistent enough.
Comment on attachment 569758 [details] [diff] [review]
> - <xul:vbox class="console-rows" role="console-rows" xbl:inherits="dir=sortOrder"/>
> + <xul:vbox anonid="console-rows-vbox" class="console-rows" role="console-rows" xbl:inherits="dir=sortOrder"/>
I think this change to the anonid is unnecessary.
Comment on attachment 569758 [details] [diff] [review]
Review of attachment 569758 [details] [diff] [review]:
I didn't look too closely at this, but still a few comments. R+ assuming you have/will ponder them and fix if worthy.
@@ +91,5 @@
> <menuitem id="menu_copy_cm" command="cmd_copy"
> label="©Cmd.label;" accesskey="©Cmd.accesskey;"/>
> + <menuseparator/>
I probably wouldn't bother with the extra menusep here, since it's a short menu.
@@ +232,5 @@
> + // First we need to sort selectedItems since selectedItems is
> + // always the first selected, but not necessarily the first in the list.
> + // Then we'll separate each item with 2 newlines, otherwise it will be
> + // hard to distinguish messages.
> + function sortFn(a, b) a.getBoundingClientRect().top - b.getBoundingClientRect().top;
That's a little weird. No better way to get their index? Or add an index property instead?
Or drop selectedItems, and construct it on-demand by filtering all items for the ones selected?
@@ +310,5 @@
> + // We're going to be lazy here and just push the new node in. We use
> + // selectedItem to determine the first selected (for shift click)
> + // so we need to maintain that.
> + var selectedItems = this.selectedItems.slice();
> + selectedItems.push(aNode);
What happens when you select items, but further console spam causes them to scroll out of the console?
Also, presumably selectedItems gets nuked when closing the console?
What happened here? It looks like this patch fell through the cracks, despite the r+.
(In reply to Colby Russell :crussell from comment #18)
> What happened here? It looks like this patch fell through the cracks,
> despite the r+.
(probably) short answer is zpao no longer works on mozilla.
Plus, web console (ctrl+shift+K in nightlies) is just around the corner. Making this request near obsolete
Yeah, I think this is probably WONTFIX, but maybe someone else is interested in working on it.
Sorry, didn't mean to resolve this.
Selecting all entries is now possible with the new console.
Re comment #22: Starting with which version?
It should be the version with the new browser console. In this console you can now select all of the text.
(In reply to sworddragon2 from comment #24)
> It should be the version with the new browser console. In this console you
> can now select all of the text.
This bug is about the Toolkit Error Console. The Firefox browser console is not available in anything that isn't called "Firefox".
Possibly I have found this bug some time ago while searching for duplicates. At least this issue is fixed on Firefox so I haven't to create now another ticket.
The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed. If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.
I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console.
If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid. Do not push that work onto the bug reporters.
(It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify. But that is the ONLY situation where it is okay.)
(I'm going to have to do this in two steps because of the way the "change several bugs at once" form works. Apologies for the extra bugspam.)
This WFM in the new browser console.