588967 - Console input field doesn't resize

Status: VERIFIED FIXED

(DevTools :: General, defect)

Description

[Patrick Walton (:pcwalton)]

The input field in the Web Console doesn't resize when long lines are entered anymore.

Comment 1

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch.

Proposed patch attached. This patch changes input resizing from row-based to pixel-based (which is needed as far as I can tell to account for word wrap). Because we work in terms of rows now (not pixels), a hard limit on the number of displayed rows is no longer easy to do, so I've removed that limit. Feedback requested.

Comment 2

[Mihai Sucan [:msucan]]

Comment on attachment 472888 [details] [diff] [review]
Proposed patch.

The patch looks good. Minor issues:

- case 101: setTimeout() function declares var endPos which seems unused. Perhaps you can remove it.
- again, tabBrowser misnomer, selectedBrowser instead of getBrowserForTab().
- the test file triggers an exception inside the HUDService, at the end, even if it passes all tests:

TEST-INFO | chrome://mochikit/content/browser/toolkit/components/console/hudservice/tests/browser/browser_webconsole_bug_588967_input_expansion.js | Console message: [JavaScript Error: "[Exception... "'Error: Cannot get outputNode by id' when calling method: [nsIConsoleListener::observe]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "<unknown>"  data: no]"]

This looks like a bug in HUDService. I think you can avoid it by running finish() a bit later - maybe executeSoon(finish) does the trick.

Comment 3

[Mihai Sucan [:msucan]]

I also wanted to add that when the input wraps to two lines (or more), when I write a long line, it's not intuitive in the sense that I can't use the Up/Down arrow keys to go from one line to another - it considers everything as a single line - not like in a normal textarea. Reminds me of vim behavior (k/j versus gk/gj). Not sure you can do anything about this, except maybe to switch to a different input type - a XUL textarea?

Comment 4

[Patrick Walton (:pcwalton)]

(In reply to comment #2)
> Comment on attachment 472888 [details] [diff] [review]
> - the test file triggers an exception inside the HUDService, at the end, even
> if it passes all tests:
> 
> TEST-INFO |
> chrome://mochikit/content/browser/toolkit/components/console/hudservice/tests/browser/browser_webconsole_bug_588967_input_expansion.js
> | Console message: [JavaScript Error: "[Exception... "'Error: Cannot get
> outputNode by id' when calling method: [nsIConsoleListener::observe]" 
> nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "<unknown>"
>  data: no]"]
> 
> This looks like a bug in HUDService. I think you can avoid it by running
> finish() a bit later - maybe executeSoon(finish) does the trick.

This is part of the test console.html page. I've avoided introducing a new HTML page to reduce churn; this is better as a followup bug to bug 581069 IMO.

Comment 5

[Patrick Walton (:pcwalton)]

(In reply to comment #3)
> I also wanted to add that when the input wraps to two lines (or more), when I
> write a long line, it's not intuitive in the sense that I can't use the Up/Down
> arrow keys to go from one line to another - it considers everything as a single
> line - not like in a normal textarea. Reminds me of vim behavior (k/j versus
> gk/gj). Not sure you can do anything about this, except maybe to switch to a
> different input type - a XUL textarea?

We're already on the XUL equivalent of a textarea.

This is actually a problem with the caretInFirstLine()/caretInLastLine() logic. I've filed a followup: bug 594497.

Comment 6

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 1.1.

Patch version 1.1 addresses feedback comments. Review requested.

Comment 7

[David Dahl :ddahl]

http://hg.mozilla.org/mozilla-central/rev/976d2a371fe3