Last Comment Bug 673873 - display placeholder when focusing an empty input
: display placeholder when focusing an empty input
Status: RESOLVED FIXED
[mentor=mounir][lang=c++]
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal with 5 votes (vote)
: mozilla15
Assigned To: Frank Yan (:fryn)
:
Mentors:
data:text/html,<input autofocus place...
: 726058 726748 (view as bug list)
Depends on: 843284 702184 737786 758996 765646 769405 786630 789484
Blocks: 737273
  Show dependency treegraph
 
Reported: 2011-07-25 02:41 PDT by Anthony Ricaud (:rik)
Modified: 2013-05-31 02:58 PDT (History)
32 users (show)
mounir: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase 2 (142 bytes, text/html)
2012-01-21 08:07 PST, Mounir Lamouri (:mounir)
no flags Details
patch (5.84 KB, patch)
2012-02-13 15:53 PST, Frank Yan (:fryn)
mounir: review-
Details | Diff | Splinter Review
part 1: display placeholder when focusing an empty input (5.59 KB, patch)
2012-05-22 11:46 PDT, Frank Yan (:fryn)
no flags Details | Diff | Splinter Review
part 2: update reftests (13.17 KB, patch)
2012-05-22 11:49 PDT, Frank Yan (:fryn)
no flags Details | Diff | Splinter Review
part 2: update reftests (take 2) (13.18 KB, patch)
2012-05-22 11:56 PDT, Frank Yan (:fryn)
mounir: review-
Details | Diff | Splinter Review
part 2: update reftests (12.19 KB, patch)
2012-05-22 13:02 PDT, Frank Yan (:fryn)
no flags Details | Diff | Splinter Review
part 3: remove duplicate tests (2.94 KB, patch)
2012-05-22 13:03 PDT, Frank Yan (:fryn)
no flags Details | Diff | Splinter Review
part 3: remove duplicate tests (4.10 KB, patch)
2012-05-22 13:05 PDT, Frank Yan (:fryn)
mounir: review+
Details | Diff | Splinter Review
part 1: display placeholder when focusing empty input/textarea (6.91 KB, patch)
2012-05-22 18:46 PDT, Frank Yan (:fryn)
mounir: review+
dao+bmo: review-
Details | Diff | Splinter Review
part 2: update reftests (12.18 KB, patch)
2012-05-22 22:41 PDT, Frank Yan (:fryn)
mounir: review+
Details | Diff | Splinter Review

Description Anthony Ricaud (:rik) 2011-07-25 02:41:20 PDT
Behaviour of all placeholder changed with OS X Lion. Now the placeholder text is also displayed when focusing an empty field.

Safari, of course, supports this.
Comment 1 Anthony Ricaud (:rik) 2011-07-25 02:43:12 PDT
This is also visible in the search field for Firefox. Should I file another bug for it or will it be fixed with this?
Comment 2 Mounir Lamouri (:mounir) 2011-07-25 09:47:08 PDT
I do not want to make @placeholder behavior platform-dependent except if the specs ask for it. A discussion began to make placeholders having the behavior you described given that it seems that most platforms actually have this behavior.
Comment 3 Mounir Lamouri (:mounir) 2012-01-06 09:02:27 PST
The specs currently allow us to show the placeholder even when the element is focused. Karl, do you know if there is any convention for placeholders in GTK?
Currently Mac and Windows show the placeholder when the element is focused so I wonder if we should have that behavior for all platforms or a per-platform behavior which is going to be harder to maintain.
Comment 4 Mounir Lamouri (:mounir) 2012-01-06 09:05:53 PST
BTW, this is the commit that did change the requirements:
http://lists.w3.org/Archives/Public/public-html-diffs/2011Oct/0174.html
Comment 5 Karl Tomlinson (:karlt) 2012-01-07 19:44:41 PST
Placeholders have only recently been added to GtkEntry (3.2).  They are displayed "when it is empty and unfocused".
http://developer.gnome.org/gtk3/3.2/GtkEntry.html#gtk-entry-set-placeholder-text
In Qt Designer, I also see the placeholder text hidden when the widget receives focus on X11 systems.
Comment 6 Karl Tomlinson (:karlt) 2012-01-07 22:31:42 PST
The GTK placeholder may be modelled after the Maemo and/or Firefox implementations.
Its docs give a good reason why displaying the placeholder when focused could be helpful:
"Note that since the placeholder text gets removed when the entry received focus, using this feature is a bit problematic if the entry is given the initial focus in a window."
Comment 7 Mounir Lamouri (:mounir) 2012-01-08 09:42:59 PST
I've just opened a bug to have this fixed in GTK:
https://bugzilla.gnome.org/show_bug.cgi?id=667502

Karl, would you be okay if we have the same implementation for all platforms and we would show the placeholder if the entry is focused but has no value?
Comment 8 Karl Tomlinson (:karlt) 2012-01-08 13:27:05 PST
Yes, showing the placeholder even when focused sounds fine to me.
The GTK implementation isn't old enough to feel the need to imitate that.

Will there be additional space in front of the placeholder, as I see on NT 6.1, to separate the placeholder from the caret?
Comment 9 Karl Tomlinson (:karlt) 2012-01-08 13:29:54 PST
Actually, I notice the NT implementation hides the placeholder when the input widget is clicked, but shows the placeholder if the widget receives focus by other means.
Comment 10 Mounir Lamouri (:mounir) 2012-01-10 05:23:50 PST
If someone is interested to fix this bug, you have to change how the placeholder is shown in content/html/content/src/nsHTMLInputElement.cpp and a few changes in content/html/content/src/nsTextEditorState.cpp too. Finally, you might want to change layout/forms/nsTextControlFrame.cpp.
To know what you have to change, searching for "placeholder" and understanding what is done should be quite straightforward.

After doing so, you will have to update tests and make sure the UX is okay but that's parts 2 and 3.
Comment 11 Keith "SuPeR K!" Kocienski 2012-01-12 15:52:29 PST
Webkit and IE 10 support this style of placeholder display. The placeholder text stays visible until the user actually enters a character.

Sorry, I've had a bugzilla account forever, but I don't know where to download the source to attempt to fix this... Can someone point me in the right direction. I'd be interested in trying to create a patch.
Comment 12 Karl Tomlinson (:karlt) 2012-01-12 17:08:11 PST
https://developer.mozilla.org/En/Simple_Firefox_build looks a good place to start.
Comment 13 Mounir Lamouri (:mounir) 2012-01-21 08:07:23 PST
Created attachment 590476 [details]
testcase 2
Comment 14 Mounir Lamouri (:mounir) 2012-02-11 15:00:54 PST
*** Bug 726058 has been marked as a duplicate of this bug. ***
Comment 15 Markus Stange [:mstange] 2012-02-13 13:31:31 PST
*** Bug 726748 has been marked as a duplicate of this bug. ***
Comment 16 Frank Yan (:fryn) 2012-02-13 14:03:01 PST
"student-project"? I will happily be that student for this bug. :P
Comment 17 Frank Yan (:fryn) 2012-02-13 15:53:05 PST
Created attachment 596829 [details] [diff] [review]
patch

Here's a patch!

Because the cursor can now be visible while the element is in the :-moz-placeholder state, this can cause the :-moz-placeholder styling to change the cursor styling in that state. I think the solution is to change :-moz-placeholder from a pseudo-class to to a pseudo-element, i.e. ::-moz-placeholder. Since it's not broken in the default styling and the pseudo-class is vendor-prefixed, it can be done in a followup bug, IMHO.
Comment 18 Jared Wein [:jaws] (please needinfo? me) 2012-02-15 11:41:56 PST
(In reply to Frank Yan (:fryn) from comment #17)
> Created attachment 596829 [details] [diff] [review]
> patch

These reftests will need to be updated:
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/input/placeholder-simple.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/input/placeholder-focus.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/input/placeholder-blur.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/input/placeholder-complex.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/input/placeholder-add.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/input/placeholder-value-unset.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/input/placeholder-value-reset.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/input/placeholder-type-change-1.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/textarea/placeholder-simple.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/textarea/placeholder-focus.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/textarea/placeholder-blur.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/textarea/placeholder-complex.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/textarea/placeholder-add.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/textarea/placeholder-value-unset.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/css-placeholder/textarea/placeholder-value-reset.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/forms/placeholder/placeholder-7.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/forms/placeholder/placeholder-8.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/forms/placeholder/placeholder-9.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/forms/placeholder/placeholder-15.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/forms/placeholder/placeholder-16.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/forms/placeholder/placeholder-17.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/forms/placeholder/placeholder-20.html | image comparison (==)
Comment 19 Mounir Lamouri (:mounir) 2012-03-06 10:42:24 PST
Comment on attachment 596829 [details] [diff] [review]
patch

Review of attachment 596829 [details] [diff] [review]:
-----------------------------------------------------------------

r-, because the caret coloring issue is a big deal. This patch is breaking :-moz-placholder and we should find a solution.

On top of my head, we could try to use a ::value pseudo-element or change :-moz-placeholder to ::-moz-placeholder.
We probably need CSS/layout people in the discussion.

::: layout/forms/nsTextControlFrame.cpp
@@ +669,5 @@
>  
>    // Revoke the previous scroll event if one exists
>    mScrollEvent.Revoke();
>  
> +  if (!aOn)

Keep the { } please:
if (!aOn) {
  return;
}

::: layout/style/forms.css
@@ -175,5 @@
>  
> -input:-moz-placeholder,
> -textarea:-moz-placeholder {
> -  color: GrayText;
> -}

I don't like that...
Comment 20 Frank Yan (:fryn) 2012-03-06 13:57:04 PST
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #19)
> [...] or change :-moz-placeholder to ::-moz-placeholder.

Yes, this is what I suggested.

> We probably need CSS/layout people in the discussion.

Who do you suggest?

> ::: layout/style/forms.css
> @@ -175,5 @@
> >  
> > -input:-moz-placeholder,
> > -textarea:-moz-placeholder {
> > -  color: GrayText;
> > -}
> 
> I don't like that...

What don't you like about it, and what would you prefer? In the patch, I replaced it with the following to ensure that the caret is not also GrayText:

 input > .placeholder,
 textarea > .placeholder {
+  color: GrayText;
Comment 21 Mounir Lamouri (:mounir) 2012-03-07 05:15:54 PST
(In reply to Frank Yan (:fryn) from comment #20)
> Who do you suggest?

Boris and David Baron.

> > ::: layout/style/forms.css
> > @@ -175,5 @@
> > >  
> > > -input:-moz-placeholder,
> > > -textarea:-moz-placeholder {
> > > -  color: GrayText;
> > > -}
> > 
> > I don't like that...
> 
> What don't you like about it, and what would you prefer? In the patch, I
> replaced it with the following to ensure that the caret is not also GrayText:
> 
>  input > .placeholder,
>  textarea > .placeholder {
> +  color: GrayText;

Using :-moz-placeholder in a content script breaks that, I think.
Comment 22 Boris Zbarsky [:bz] 2012-03-07 07:55:28 PST
Assuming you want to keep the pseudo-class but keep the caret styling, could you do something like this?

  input:-moz-placeholder {
    color: GrayText;
  }
  input:-moz-placeholder > .anonymous-div {
    color: -moz-FieldText;
  }

This would color everything in .anonymous-div -moz-FieldText when we have a placeholder, but the only thing in there at that point should be the caret, right?
Comment 23 Mounir Lamouri (:mounir) 2012-03-07 10:08:14 PST
"anonymous-div" is actually used for both the placeholder div and the editor div. Though, it's possible to select the editor div by doing :not(.placeholder). I tried that. This is indeed solving the issue but it is creating a new one:
input {
  color: green;
}
<input placeholder='foo'>

Shows a regular (black) caret when focusing the text field instead of a green one. It changes when the placeholder disappears. Does that mean the rule in forms.css got an higher priority than the rule in the content stylesheet?
Comment 24 Boris Zbarsky [:bz] 2012-03-07 10:14:05 PST
No, it means the rule in forms.css is applied to a descendant of the element the content stylehseet rule applies to.

If you don't want that behavior, then you can't keep using a pseudo-class here....
Comment 25 Frank Yan (:fryn) 2012-03-08 16:17:33 PST
Since it's affecting only the placeholder text and not the caret, it really should be a pseudo-element. I'm happy to help make that happen, but I don't have experience with implementing pseudo-elements, so I'd need some hand-holding there.

Given that :-moz-placeholder is a vendor-prefixed pseudo-class at the moment, I think it's better to improve the placeholder behavior while removing support for our proprietary pseudo-class first and then re-implement the pseudo-element properly than to block this improvement on fixing :-moz-placeholder.
Comment 26 Mounir Lamouri (:mounir) 2012-03-09 06:37:34 PST
Frank, could you update the patch with Boris hack. I would prefer that than having :-moz-placeholder not working anymore for the moment.
Using a pseudo-class isn't going to be trivial. I tried to do that when implementing the placeholder feature and I remember I had a lot of issues.
Comment 27 Boris Zbarsky [:bz] 2012-03-09 14:17:11 PST
I agree that spinning off the pseudo-element bit into a separate bug makes sense.

Now that bug 654989 is fixed, doing the pseudo-element thing actually shouldn't be that hard, I suspect... I could be wrong, of course.
Comment 28 Mounir Lamouri (:mounir) 2012-03-09 14:36:40 PST
Oh, this is a good news. So Frank what about fixing that bug then working on the pseudo-element?
Comment 29 Frank Yan (:fryn) 2012-03-09 14:39:42 PST
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #28)
> Oh, this is a good news. So Frank what about fixing that bug then working on
> the pseudo-element?

What do you mean? Bug 654989 is already fixed.
Comment 30 Mounir Lamouri (:mounir) 2012-03-09 14:41:55 PST
I meant this bug, bug 673873.
Comment 31 Frank Yan (:fryn) 2012-03-13 17:53:34 PDT
(In reply to Boris Zbarsky (:bz) from comment #22)
>   input:-moz-placeholder {
>     color: GrayText;
>   }
>   input:-moz-placeholder > .anonymous-div {
>     color: -moz-FieldText;
>   }

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #23)
> "anonymous-div" is actually used for both the placeholder div and the editor
> div. Though, it's possible to select the editor div by doing
> :not(.placeholder).

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #26)
> Frank, could you update the patch with Boris hack.

Okay, do you mean that I should use the following?

input:-moz-placeholder {
  color: GrayText;
}
input:-moz-placeholder > .anonymous-div:not(.placeholder) {
  color: -moz-FieldText;
}

Wouldn't `color: inherit;` make more sense for the second block?
Comment 32 Frank Yan (:fryn) 2012-03-13 18:22:44 PDT
(In reply to Frank Yan (:fryn) from comment #31)
> Wouldn't `color: inherit;` make more sense for the second block?

Never mind. I wasn't thinking clearly.
Comment 33 Frank Yan (:fryn) 2012-05-22 11:46:17 PDT
Created attachment 626113 [details] [diff] [review]
part 1: display placeholder when focusing an empty input

Using bz's workaround until :-moz-placeholder is re-implemented as a pseudo-element.
Comment 34 Frank Yan (:fryn) 2012-05-22 11:49:24 PDT
Created attachment 626115 [details] [diff] [review]
part 2: update reftests

Updated reftests.
Removed placeholder-15.html, placeholder-16.html, and placeholder-17.html, since they were exact copies of placeholder-7.html, placeholder-8.html, and placeholder-9.html.
Removed placeholder-10.html, placeholder-20.html, placeholder-21.html, placeholder-22.html, because fixing this bug makes them redundant and unnecessary.
Comment 35 Frank Yan (:fryn) 2012-05-22 11:56:03 PDT
Created attachment 626120 [details] [diff] [review]
part 2: update reftests (take 2)

Forgot to qref a change.
Comment 36 Mounir Lamouri (:mounir) 2012-05-22 12:21:30 PDT
Comment on attachment 626120 [details] [diff] [review]
part 2: update reftests (take 2)

Review of attachment 626120 [details] [diff] [review]:
-----------------------------------------------------------------

Do not remove tests, instead you should just change the result.
Comment 37 Frank Yan (:fryn) 2012-05-22 12:25:37 PDT
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #36)
> Do not remove tests, instead you should just change the result.

Why are we running the same test twice? Compare placeholder-7.html and placeholder-15.html.
Comment 38 Frank Yan (:fryn) 2012-05-22 13:02:48 PDT
Created attachment 626142 [details] [diff] [review]
part 2: update reftests
Comment 39 Frank Yan (:fryn) 2012-05-22 13:03:47 PDT
Created attachment 626143 [details] [diff] [review]
part 3: remove duplicate tests

placeholder-7.html === placeholder-15.html
placeholder-8.html === placeholder-16.html
placeholder-9.html === placeholder-17.html
Comment 40 Frank Yan (:fryn) 2012-05-22 13:05:19 PDT
Created attachment 626146 [details] [diff] [review]
part 3: remove duplicate tests

Forgot to update reftest.list.
Comment 41 Frank Yan (:fryn) 2012-05-22 18:46:24 PDT
Created attachment 626283 [details] [diff] [review]
part 1: display placeholder when focusing empty input/textarea

Forgot to update nsTextAreaElement.cpp.
Comment 42 Frank Yan (:fryn) 2012-05-22 22:41:00 PDT
Created attachment 626330 [details] [diff] [review]
part 2: update reftests

Accidentally used value attribute instead of text node for a <textarea/>.

All tests now pass locally and on tryserver.
Comment 43 Dão Gottwald [:dao] 2012-05-23 01:51:25 PDT
Comment on attachment 626283 [details] [diff] [review]
part 1: display placeholder when focusing empty input/textarea

> input:-moz-placeholder,
> textarea:-moz-placeholder {
>-  color: GrayText;
>+  color: DarkGray;

DarkGray isn't guaranteed to be visible on natively styled input fields. What does this change have to do with this bug anyway?
Comment 44 Frank Yan (:fryn) 2012-05-23 02:22:40 PDT
(In reply to Dão Gottwald [:dao] from comment #43)
> DarkGray isn't guaranteed to be visible on natively styled input fields.
> What does this change have to do with this bug anyway?

It has to do with this bug, because having the placeholder visible while the caret is visible and the field is focused means that we need to ensure that it's clear the placeholder isn't a prefilled value.
GrayText is too dark to make that clear distinction, at least on Windows and Mac.

Secondly, GrayText is supposed to be used for _disabled_ fields, not for placeholders.
We should not style read-only fields and placeholders the same.
I chose DarkGray to match WebKit, with which we want to standardize this pseudo-element anyway:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css#L502

Mounir mentioned wanting to use opacity instead, but there are rendering and performance problems that we'd need to resolve with that.
Comment 45 Mounir Lamouri (:mounir) 2012-05-23 04:11:10 PDT
Comment on attachment 626330 [details] [diff] [review]
part 2: update reftests

Review of attachment 626330 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, with the possibility that the placeholder color changes.

::: layout/reftests/forms/placeholder/placeholder-style.css
@@ +1,3 @@
>  textarea.placeholder,
>  input.placeholder {
> +  color: DarkGray;

This might need to change but I will not block that patch because of this.
Comment 46 Mounir Lamouri (:mounir) 2012-05-23 04:17:24 PDT
Comment on attachment 626283 [details] [diff] [review]
part 1: display placeholder when focusing empty input/textarea

Review of attachment 626283 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the color value reverted.

::: layout/style/forms.css
@@ +141,5 @@
>  }
>  
>  input:-moz-placeholder,
>  textarea:-moz-placeholder {
> +  color: DarkGray;

I agree with Dao, you shouldn't change the color. Unfortunately, you can't use opacity here because it's not a pseudo-element.
Comment 47 Dão Gottwald [:dao] 2012-05-23 04:58:24 PDT
(In reply to Frank Yan (:fryn) from comment #44)
> I chose DarkGray to match WebKit, with which we want to standardize this
> pseudo-element anyway:
> http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css#L502

I don't think there's a point in matching Webkit here. The spec can't require DarkGray for said reason. GrayText may be suboptimal but DarkGray isn't a sane choice at all.
Comment 48 Mounir Lamouri (:mounir) 2012-05-23 05:00:28 PDT
I agree. GrayText is guaranteed to be visible on the text field background.
I will push for opacity when we will have a pseudo-element instead of a pseudo-class.
Comment 49 Boris Zbarsky [:bz] 2012-05-23 06:54:34 PDT
> I chose DarkGray to match WebKit

Does WebKit also apply some sort of native styling to the placeholder, in addition to the CSS rules you looked at, perhaps?

If not, how do placeholders end up looking when the OS theme sets a black background on text inputs?
Comment 50 Frank Yan (:fryn) 2012-05-23 19:37:11 PDT
(In reply to Boris Zbarsky (:bz) from comment #49)
> > I chose DarkGray to match WebKit
> 
> Does WebKit also apply some sort of native styling to the placeholder, in
> addition to the CSS rules you looked at, perhaps?

I don't know. I didn't find any.

> If not, how do placeholders end up looking when the OS theme sets a black
> background on text inputs?

First of all, DarkGray is #a9a9a9. It's lighter than Gray.
http://en.wikipedia.org/wiki/Variations_of_gray#Dark_medium_gray_.28dark_gray_.28X11.29.29
It would be _more_ visible on black backgrounds.
Comment 51 Dão Gottwald [:dao] 2012-05-24 00:43:02 PDT
(In reply to Frank Yan (:fryn) from comment #50)
> > If not, how do placeholders end up looking when the OS theme sets a black
> > background on text inputs?
> 
> First of all, DarkGray is #a9a9a9. It's lighter than Gray.
> http://en.wikipedia.org/wiki/Variations_of_gray#Dark_medium_gray_.
> 28dark_gray_.28X11.29.29
> It would be _more_ visible on black backgrounds.

More visible than what? GrayText isn't some specific gray. It can be any color. In a dark theme (not necessarily black!) it's likely closer to white than in a bright theme. In a high contrast theme it's usually something like lime, pink, yellow, ...
Comment 52 Frank Yan (:fryn) 2012-05-24 04:04:52 PDT
(In reply to Dão Gottwald [:dao] from comment #51)
> More visible than what?

There is greater difference in luminosity between DarkGray and black than between DarkGray and white.

I understand what system color means.

Part 1 w/o changing GrayText:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bfd3a65c0feb
I guess we'll just go with applying opacity once we fix bug 737786, which I prefer as a more robust and accessible solution anyways, but I anticipate rendering and performance issues that we'll have to resolve.

Part 2:
https://hg.mozilla.org/integration/mozilla-inbound/rev/75571af38ce5

Part 3:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0d782874abea
Comment 53 Ed Morley [:emorley] 2012-05-24 06:16:25 PDT
Sorry had to back out due to the significant increase in failures of bug 702184:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=0d782874abea
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=bb8a34106b05

I wouldn't feel comfortable merging that level of failures into mozilla-central, so the (long overdue due to DB/infra issues) merge would be blocked by this otherwise.

https://hg.mozilla.org/integration/mozilla-inbound/rev/7115f9e1f76f
Comment 54 Frank Yan (:fryn) 2012-05-24 06:35:53 PDT
The code changes I'm making here don't seem actually to regress bug 598726, for which that unreliable 598726-1.html is supposed to test.
Could we fix the test or, if we don't know how, disable it for now in bug 702184?
Comment 57 Alex Shilov 2012-06-15 13:24:42 PDT
Hixie has changed "and" to "and/or" and you started to implement it without thinking. How could you? It still has "and" part.

I am very disappointed. I am using firefox for years, and it always be consistent. Why should you change behavior of something if it just has changed in SomeOS ? MacOS doesn't even have such share as Windows!  
For me new behavior has serious UX problems. There is no way that it is convenient to somebody, to start typing in field that already has the text! How can I expect that the text is magically disappear if I start typing? The placeholder text can't be deleted by "delete" key, it can't be deleted by "Ctrl+A, Backspace" combo. It can't be delete at all, except me start typing. 

Want example for a field that has a text on focus, which replaced on typing? It is mcedit (linux Midnight Commander). After you open a search dialog the search field already have a last used keyword. And if you start typing it behaves as placeholder. But if you don't - it start searching by the last keyword, not for the empty string! 
Want another? It's in windows, just press Win+R and you have the Run dialog where you have your last command, selected in it - if you start typing it obviously deleted, because it was selected text, but if you don't - last command be executed. 

How can user distinguish whether it is a placeholder, or a predefined value? The only method is by focus them! 
So, how can user expect that in Firefox when he focus field and it behaves like predefined value it will be submitted like empty string? The rule was simple, if after focus you has empty string - it will be submitted as empty string!
Have you tried this behavior on mobile devices, like on small android devices where you cant clearly see the text caret? There you cant be sure that you hit where you like. 

For me, you broke the whole functionality of placeholder. The only way is to emulate it by javascript, like we did decade ago. Like http://mail.yandex.com/ is doing today. 

And what for? For those users who forgot placeholder text right after they click to input field? Isn't it?

P.S. Bug 758996 depends of this bug.
Comment 58 Jared Jacobs 2012-06-15 14:00:37 PDT
mr.troll, please allow me to respectfully answer two of your questions that struck me as genuine rather than rhetorical, at least from my point of view:

> How can user distinguish whether it is a placeholder, or a predefined value?

Placeholder text is faint, typically light gray.

> And what for? For those users who forgot placeholder text right after they click to input field?

No. The most important case I can think of is when a field with placeholder text is focused when it first appears (e.g. with the autofocus attribute). In this case, if the placeholder text were not shown, the user might be staring at an empty field with no indication as to what it's for.
Comment 59 Alex Shilov 2012-06-15 15:03:06 PDT
Thank you for your answer Jacob! My questions is both genuine and rhetorical (i wish, but i don't believe that this bug will be reopened).
Site i'm working right now - http://mskfactory.ru has light gray input text (#a0a4ad) and if you can pick a color - you can see that placeholder in my case use input color. And is doesn't change anything onfocus (except of text caret), that's the point.

If the input with placeholder has autofocus - great. It is how webmaster want it. If not - webmaster should place label outside of input. See http://mail.yandex.com/ again - it has autofocus input. If user not smart enough to determine that it is login field - he will unfocus and read, and in second time he will already know what it is. But the text in focused field will stress him every time! It can't be helped. Why not to show placeholder only with autofocused focus if it so matter?
Execute the code like this and try to submit field:
<form><input type="text" required placeholder="Something"></form>
It can stress even me! It tell me that the field is empty, but hei, it has focus and I swear to Mozilla I see the text in here!

Why there is no UX review? The simple old usability rule is said "When you have enough space and the input label is important - use <label> outside of input, instead of placeholder, use labels then you have many inputs at form. But if is's like search form with single text-input, or login/password, or anything when user can easily guess it - you can make placeholder". So i assume that placeholder attribute is only used then user can guess it (ie8 can't show it at all). And mozilla programmers assume that placeholder is always important enough that user must see it even after click?! I cant believe that user can forgot it after click.

The real my questions is: If you have some code that working, why should you change it? If you have some code that working GOOD, and anyone like it, why should you change it? 

Please anybody tell me if he is personally complaining with old behaviour? Give me a reason?

Looks like this bug will not be confirmed in gnome, for the reasons i said above
https://bugzilla.gnome.org/show_bug.cgi?id=667502
Good for Gnome.
Comment 60 Mounir Lamouri (:mounir) 2012-06-18 10:10:27 PDT
(In reply to mr.troll from comment #57)
> Hixie has changed "and" to "and/or" and you started to implement it without
> thinking. How could you? It still has "and" part.
> 
> I am very disappointed. I am using firefox for years, and it always be
> consistent. Why should you change behavior of something if it just has
> changed in SomeOS ? MacOS doesn't even have such share as Windows!  

MacOS, some Windows native text fields, Android and likely iOS have that behaviour for placeholder. We should see how Windows 8 is behaving but it seems like most platforms chose that behaviour.
Comment 61 Nathan Williams 2012-08-30 19:22:44 PDT
Like mr.troll, I find this change to be counter-intuitive.  My instinct with web UIs tells me that the way to clear text from a box I want to type in is to double-click and backspace, highlight and type over, etc.  I've encountered placeholder-style text inputs before, but they've cleared the text on focus.  This implementation is close enough to a disabled control (same default text color) that that's what I thought it was when I first encountered it after upgrading to Firefox 15.  I didn't even think to try typing because this other text that I couldn't get rid of was in the way.  Even now that I know what's going on, it just doesn't feel right.

The auto-focus argument is a good one.  You could perhaps enable clear-on-focus just for user-initiated focus, but such inconsistency could cause headaches of its own.

Given that all the major browser vendors seem to have gotten in line on this one, it's probably better for Firefox to remain consistent.  I do wish that there were a CSS hack to restore the old behavior though.  WebKit, for example, has a input:focus::-webkit-input-placeholder selector.
Comment 62 Nathan Williams 2012-08-30 20:05:03 PDT
Nevermind to the last bit.  I see that there is input:focus:-moz-placeholder.

http://stackoverflow.com/questions/2610497/change-an-inputs-html5-placeholder-color-with-css
Comment 63 Alex Shilov 2012-08-31 12:14:38 PDT
Yes. Thanks Nathan, it works. I thought about it a couple weeks ago. The solution now is:
<style type="text/css">
	input:focus:-moz-placeholder {color:transparent;}
	input:focus::-webkit-input-placeholder {color:transparent;}
</style>
Note, that there should be separate css rule for chrome, because it doesn't support it if it there one. 

It looks very hacky now =)
Comment 64 MySh 2012-09-01 02:26:16 PDT
Thanks a lot. Looks like you've fixed what has never been broken.
Now we again have to use some tricks just to restore that UI experience we have got used to for about 10 years. Just because someone decided to do so in Mac OS X Lion. Not an option, just a matter of fact. Nice indeed.

Those who like me consider this annoying can use style by Infocatcher: http://userstyles.org/styles/71930/firefox-15-hide-placeholders-on-focused-nodes. Fortunately, this can be fixed with a style, no need to use another special extension this time.
Comment 65 MySh 2012-09-02 03:53:57 PDT
I think this link should be here:
Bug 758996 – placeholder should disappear when text input is clicked -> https://bugzilla.mozilla.org/show_bug.cgi?id=758996
Comment 66 =Haron= 2012-09-02 07:34:05 PDT
Fully support the view  MySh
Absolutely unnecessary innovation!
Comment 67 mjh563 2012-09-02 07:37:17 PDT
Also see bug 786630
Comment 68 Adrian-Costin Tundrea 2012-09-02 21:00:03 PDT
Already submitted a bug, thinking it was a bug. I have to express the same feeling the change seems unnatural. It feels weird for me to give explicit focus to a field and still have it full with text. Makes me wanna click again and again and hope it will go away.
Comment 69 andre.waehlisch 2012-09-04 16:48:33 PDT
(In reply to MySh from comment #64)
> Thanks a lot. Looks like you've fixed what has never been broken.


Just bumping this. The "bug fix" is very annoying indeed.
Comment 70 Cocinero 2012-09-09 15:04:38 PDT
I, too, find this "improvement" very irritating and annoying. Even after having been forced to live with this new behavior for the last week or so, I still haven't gotten used to it. Though, I have barely encountered this issue on any web page. But every time I click on Firefox' search bar or any search box in Thunderbird, and the placeholder doesn't disappear, my first impulse is: "Damn, is this search box broken? Is FF/TB crashing again??" This is even more irritating with the dark themes I'm using for both FF and TB. Next to the sticky light-grey placeholder, the black caret is barely visible on the dark-grey input box background.

This just feels broken now! Please restore the previous and intuitive behavior, or at least make it really optional (meaning without the need of a CSS hack or anything)! Just because "everyone" is jumping off a cliff, it doesn't mean Mozilla products have to be shoved down there, as well..

There's definitely some truth in what Radulescu Dragos-Valentin said in bug 758996, comment #6:

"People have generated the previous placeholder behaviour on their websites for probably tens of YEARS using onclick/onhover/onfocus and javascript. They could have all made it act like it acts now, but they didnt."
Comment 71 Robert 2012-09-13 06:40:15 PDT
I still can't believe Firefox apply this change. Every time I click on Firefox' search bar, and the placeholder doesn't disappear, it make me think this search box is broken and then I click it again and again until suddenly realize it is the new "feature" of firefox.

Please restore the previous and intuitive behavior
Comment 72 Mounir Lamouri (:mounir) 2012-11-11 03:23:18 PST
For those who do not like the feature added by this bug, bug 807613 allows to disable it by changing the following pref: "dom.placeholder.show_on_focus" to 'false' in "about:config". This is currently available on Nightly, will be available in Firefox 19.
Comment 73 Alex Shilov 2012-12-24 01:41:53 PST
to Mounir Lamouri: Could you please add this pref as an checkbox in the Options dialog? Many of my friends are really confused about this behavior, and they thought that something in their OS is broken. They are not smart enough to open about:config. Thank you.

And BTW, I still don't get, what are the reasons for fixing this bug, because there are a many counter-reasons described above?
Comment 74 Alex Shilov 2013-05-31 02:58:12 PDT
IE10 was released 25.04.2013, and placeholder in IE has it's old good behavior. 
And it is intentionally on both Win 7 and Win 8 systems.
Microsoft spec 
http://msdn.microsoft.com/en-us/library/ie/hh673544%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/ie/hh772745%28v=vs.85%29.aspx
http://ie.microsoft.com/testdrive/HTML5/Forms/
clearly says "Placeholder text is visible until focus is placed in the element".
So I still believe that this bug is Not a bug. Could you revert this bug on windows (probably bug 843284 is what you need to do).

Note You need to log in before you can comment on or make changes to this bug.