Bug 26602 – Web Inspector: caret moves past prompt in javascript console

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector (Deprecated)

[Pavel Feldman]

1. Open javascript console
2. Start typing "document" until auto-complete shows up, but don't finish the word
3. Hold backspace

What is the expected output? What do you see instead?
The caret should stop at the prompt character ">"
I'm seeing the caret jump past the prompt character.
If you start typing it goes back to normal, but it's a little strange!

(upstreaming http://code.google.com/p/chromium/issues/detail?id=14710).

[Joseph Pecoraro]

The style on the console-prompt is:

  -webkit-user-modify: read-write-plaintext-only;
  min-height: 16px;
  padding: 1px 22px 1px 24px;
  position: relative;
  white-space: pre-wrap;

So there is always 24px of padding on the left.  I'm guessing that the proprietary "-webkit-user-modify: read-write-plaintext-only" could be causing the problem by incorrectly working with backspace and padding? Attempting to change to margin-left didn't work either.

[Timothy Hatcher]

This smells like an editing bug.

I actually hit this today doing a demo.

[Alexander Pavlov (apavlov)]

Created attachment 51022 [details]
[PATCH] Proposed solution

[Timothy Hatcher]

Can you explain how this fixes the bug in the ChangeLog?

[Alexander Pavlov (apavlov)]

Created attachment 51037 [details]
[PATCH] Manual removal of empty Text nodes

[Timothy Hatcher]

Comment on attachment 51037 [details]
[PATCH] Manual removal of empty Text nodes

> +            var sibling = this.element.firstChild;
> +            while (sibling) {
> +                var nextSibling = sibling.nextSibling;
> +                if (sibling.nodeName === "#text" && sibling.nodeValue === "")
> +                    sibling.parentNode.removeChild(sibling);
> +                sibling = nextSibling;
> +            }
> +
>              prefixTextNode.parentNode.insertBefore(this.autoCompleteElement, prefixTextNode.nextSibling);

What prevent prefixTextNode from being one of the pruned nodes? Maybe this can be put into a helper function in utilities.

Is this the only place it needs to be called?

[Pavel Feldman]

Comment on attachment 51037 [details]
[PATCH] Manual removal of empty Text nodes

> +                if (sibling.nodeName === "#text" && sibling.nodeValue === "")

Use nodeType === Node.TEXT_NODE instead.

[Alexander Pavlov (apavlov)]

Created attachment 51042 [details]
[PATCH] Comments addressed, explanation added to ChangeLog

[Alexander Pavlov (apavlov)]

(In reply to comment #6)
> (From update of attachment 51037 [details])
> > +            var sibling = this.element.firstChild;
> > +            while (sibling) {
> > +                var nextSibling = sibling.nextSibling;
> > +                if (sibling.nodeName === "#text" && sibling.nodeValue === "")
> > +                    sibling.parentNode.removeChild(sibling);
> > +                sibling = nextSibling;
> > +            }
> > +
> >              prefixTextNode.parentNode.insertBefore(this.autoCompleteElement, prefixTextNode.nextSibling);
> 
> What prevent prefixTextNode from being one of the pruned nodes? Maybe this can

(a) we never show completions for an empty prefix,
(b) an empty prefix can either be there from the outset (which is not the case) or after a deletion of succeeding characters (which is the case we already sanitize)

> be put into a helper function in utilities.

A good idea, done.

> Is this the only place it needs to be called?

Added a pruning call next to the other deleteContents(), to be on the safe side.

[WebKit Commit Bot]

Comment on attachment 51042 [details]
[PATCH] Comments addressed, explanation added to ChangeLog

Clearing flags on attachment: 51042

Committed r56280: <http://trac.webkit.org/changeset/56280>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.