561293 - Hide the placeholder when caret browsing is used to navigate to a text box with placeholder set

Status: RESOLVED INVALID

(Core :: DOM: Selection, defect)

Description

[(no longer active)]

Load the test URL, turn caret browsing on, click somewhere on "test", and move the caret to the right.  The caret enters the textbox, and moves over the placeholder value.  This behavior is very strange.  I would expect that the placeholder value needs to be hidden when the caret browsing selection enters the text box.

This might be easily fixed using nsEditorInitializerOnSelection code added in bug 560665 (although I haven't tested that approach.)  I'm setting a dependency for now.

Comment 1

[Mounir Lamouri (:mounir)]

As far as I can test, caret browsing lets the user to browse text nodes. So, if you have an empty text field, it will not go into but if you have a text field with a value, it will browse the value. I guess it is looking for text nodes and when an input has a value or a placeholder it contains a text node.

But caret browsing isn't really focusing the text field so the user can't begin typing in a text field if the caret is in there with caret browsing. It has to click on it (or use tab or any regular way) which will hide the placeholder correctly.

For me, the current behavior is correct and hiding the placeholder when navigating into the input element with caret browsing sounds like a bad idea. Maybe we could prevent caret browsing to go into an input element if it shows the placeholder but that would be inconsistent.

Consistency of the behavior can be tested with:
data:text/html,<input value='foo'>bar<input placeholder=foo>bar<input>

Comment 2

[(no longer active)]

Well, the problem is that we don't have a clear idea on how things _should_ work.  It looks strange to me that we can interact with text which is non-interactive like this...

Comment 3

[Mounir Lamouri (:mounir)]

(In reply to comment #2)
> Well, the problem is that we don't have a clear idea on how things _should_
> work.  It looks strange to me that we can interact with text which is
> non-interactive like this...

For me that does not sound strange. At least less strange than removing the placeholder which would let the user think he have the text field focused which is not the case. By the way, the caret doesn't let the user interact with the text if browsing a value or a placeholder text so I don't think that may let the user he can interact.

Maybe we should have the opinion of the person(s) who is/are in charge of this feature?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

David Bolter might have some feedback

Comment 5

[Mounir Lamouri (:mounir)]

We know show the placeholder on focus so this bug is no longer valid.