When moving through the Console's history (up arrow), if a multiline snippet is encountered then the Console View acts in a non-user friendly way, hiding all but the first line of the snippet. Expected Behavior: The Console View should scroll down to the bottom revealing as much of the snippet as possible. Current behavior: The Console View shows the top line of the snippet and requires that the user manually scroll the Console View to the bottom. Example Image: http://grab.by/aLV
We should let you use the arrow keys inside this code to move between lines. Only going back through history when pressing up on the first line, and only going forward through history when pressign down on the last line.
Created attachment 43468 [details] [IMAGE] "Console log" vs "Snippet editor" Note the tabs in the bottom. First is classical log, rest are multiline snippet editors.
Created attachment 43469 [details] [IMAGE] Snippet editor has debugger capabilities.
(In reply to comment #3) > Created an attachment (id=43469) [details] > [IMAGE] Snippet editor has debugger capabilities. "Elements" panel selected makes things look confusing. Maybe hide toolbar? But given that the user explicitly got there via selecting "Snippet 1" and console animated to full screen, it is no longer that confusing... Anyway. Thoughts?
(Last note before the day is over here.) Let me iterate over the rationale once again: - I don't think that history is useful of multiline console entries. - I think of multiline console entries as of snippets, little programs as Joe has shared. - I'd like user to be able to run such snippets and even debug them (i.e. break on errors) Now I am not sure that screenshots that I attached describe good solution, but they at least made me think about the problem :) It does not really make much sense to introduce such a complexity in the console view, especially when it is opened for Elements Panel. My second screenshot is especially not good about it. At the same time, it would fit the Scripts panel well. Imagine that: - in addition to the existing scripts in the combo box, you have a number of editable ones. - for them 'play/pause' button is available - you get full-blown debugging functionality on these - results are still dumped into the console
Joseph suggested to jump in here since it might interest me, so here I am! Some quick observations first: - when integrating multiline into the actual same state of the console input, navigating through history still needs to be possible, so here I like Timothy's idea of only going through history when the first line has been reached - it seems there are essentially two things we're doing here: 1. We are making sure the single line state of the console handles multi line input gracefully 2. We might want to introduce another, more textarea like state of the console input, which potential debugging capabilities Firebug solved the first issue by..well, not solving it :) It just triggers the second state (multiline) as soon as it recognizes multi line input in the console. Concerning 2): - One option is to make more use of the horizontal screen real estate, since horizontal screen estate is "cheap" on normal screens, vertical is expensive (one of the reasons bug 30282 is needed) - meaning the multiline console would open as a side pane, as it does in Firebug. However, this approach has the disadvantage that in editor terms, horizontal space is extremely important - Another option would be to make the little icon in front of the input a toggler, and when toggled, the input would transform into a textarea, effectively hiding the rest (so you'd have a full screen editor). This obviously has the extreme downside that you don't see the output without switching back. - The third option is to do another vertical pane, so console/input would be split vertically when hitting the toggler - this would possibly work well if the Web Inspector is opened in a new window and the new console full screen mode is used, but in any other modes, it would be pretty unusable I don't know what's best yet, these are only a couple of reflections. I'll talk to my collegues and see if they have a good idea. This multiline feature of Firebug is btw used a lot in Frontend conference presentations - if we can make it look awesome, it's a win-win situation.
I agree with Paul, I see us doing two things. Fixing existing multi-line to work better when using the up/down arrow keys. And addign a new snippet feature.
(In reply to comment #1) > We should let you use the arrow keys inside this code to move between lines. > Only going back through history when pressing up on the first line, and only > going forward through history when pressign down on the last line. See the patch on: https://bugs.webkit.org/show_bug.cgi?id=31400 This bug has turned into a Snippet feature, which is a great idea. =)
Created attachment 80336 [details] [IMAGE] Snippet editor is closed
Created attachment 80337 [details] [IMAGE] Snippet editor is opened
* Add "show/hide snippet editor" button next to "show/hide console". * Snippet editor is shown on the right side of console drawer and has text are and "run" button * When snippet editor is visible, you can still see classic console drawer at the left side, and you can also use classic command line to execute short commands while editing the snippet (firebug blocks command line input when editor is visible)