The default bug view has changed. See this FAQ.

display placeholder when focusing an empty input

RESOLVED FIXED in mozilla15

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: rik, Assigned: fryn)

Tracking

(Depends on: 1 bug)

Trunk
mozilla15
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [mentor=mounir][lang=c++], URL)

Attachments

(4 attachments, 6 obsolete attachments)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
This is also visible in the search field for Firefox. Should I file another bug for it or will it be fixed with this?
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.
No longer blocks: 636455
OS: Mac OS X → All
Summary: [10.7] placeholder should be displayed when focusing an empty input → placeholder should be displayed when focusing an empty input
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.
BTW, this is the commit that did change the requirements:
http://lists.w3.org/Archives/Public/public-html-diffs/2011Oct/0174.html
Whiteboard: [mentor=volkmar][lang=c++]
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.
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."
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?
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?
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.
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.
Keywords: student-project
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.
https://developer.mozilla.org/En/Simple_Firefox_build looks a good place to start.
Created attachment 590476 [details]
testcase 2
Duplicate of this bug: 726058
Duplicate of this bug: 726748
(Assignee)

Comment 16

5 years ago
"student-project"? I will happily be that student for this bug. :P
Assignee: nobody → fryn
Status: NEW → ASSIGNED
(Assignee)

Comment 17

5 years ago
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.
Attachment #596829 - Flags: review?(mounir)
(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 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...
Attachment #596829 - Flags: review?(mounir) → review-
(Assignee)

Comment 20

5 years ago
(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;
(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.
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?
"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?
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....
(Assignee)

Comment 25

5 years ago
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.
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.
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.
Oh, this is a good news. So Frank what about fixing that bug then working on the pseudo-element?
(Assignee)

Comment 29

5 years ago
(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.
I meant this bug, bug 673873.
(Assignee)

Comment 31

5 years ago
(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?
Target Milestone: --- → mozilla13
Version: Trunk → Other Branch
(Assignee)

Updated

5 years ago
Target Milestone: mozilla13 → ---
Version: Other Branch → Trunk
(Assignee)

Comment 32

5 years ago
(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.
(Assignee)

Comment 33

5 years ago
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.
Attachment #596829 - Attachment is obsolete: true
Attachment #626113 - Flags: review?(mounir)
(Assignee)

Updated

5 years ago
Keywords: student-project
Summary: placeholder should be displayed when focusing an empty input → display placeholder when focusing an empty input
(Assignee)

Comment 34

5 years ago
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.
Attachment #626115 - Flags: review?(mounir)
(Assignee)

Comment 35

5 years ago
Created attachment 626120 [details] [diff] [review]
part 2: update reftests (take 2)

Forgot to qref a change.
Attachment #626115 - Attachment is obsolete: true
Attachment #626115 - Flags: review?(mounir)
Attachment #626120 - Flags: review?(mounir)
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.
Attachment #626120 - Flags: review?(mounir) → review-
(Assignee)

Comment 37

5 years ago
(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.
(Assignee)

Comment 38

5 years ago
Created attachment 626142 [details] [diff] [review]
part 2: update reftests
Attachment #626120 - Attachment is obsolete: true
Attachment #626142 - Flags: review?(mounir)
(Assignee)

Comment 39

5 years ago
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
Attachment #626143 - Flags: review?(mounir)
(Assignee)

Comment 40

5 years ago
Created attachment 626146 [details] [diff] [review]
part 3: remove duplicate tests

Forgot to update reftest.list.
Attachment #626143 - Attachment is obsolete: true
Attachment #626143 - Flags: review?(mounir)
Attachment #626146 - Flags: review?(mounir)
(Assignee)

Updated

5 years ago
Attachment #626146 - Attachment is patch: true
(Assignee)

Updated

5 years ago
Depends on: 737786
(Assignee)

Comment 41

5 years ago
Created attachment 626283 [details] [diff] [review]
part 1: display placeholder when focusing empty input/textarea

Forgot to update nsTextAreaElement.cpp.
Attachment #626113 - Attachment is obsolete: true
Attachment #626113 - Flags: review?(mounir)
Attachment #626283 - Flags: review?(mounir)
(Assignee)

Comment 42

5 years ago
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.
Attachment #626142 - Attachment is obsolete: true
Attachment #626142 - Flags: review?(mounir)
Attachment #626330 - Flags: review?(mounir)
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?
Attachment #626283 - Flags: review-
(Assignee)

Comment 44

5 years ago
(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.
Attachment #626146 - Flags: review?(mounir) → review+
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.
Attachment #626330 - Flags: review?(mounir) → review+
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.
Attachment #626283 - Flags: review?(mounir) → review+
(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.
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.
> 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?
(Assignee)

Comment 50

5 years ago
(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.
(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, ...
(Assignee)

Comment 52

5 years ago
(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
Flags: in-testsuite+
Whiteboard: [mentor=volkmar][lang=c++] → [mentor=mounir][lang=c++]
Target Milestone: --- → mozilla15
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
Target Milestone: mozilla15 → ---
(Assignee)

Updated

5 years ago
Depends on: 702184
(Assignee)

Comment 54

5 years ago
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?
(Assignee)

Comment 55

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ff55c196d541
https://hg.mozilla.org/integration/mozilla-inbound/rev/35cf6a9b42f0
https://hg.mozilla.org/integration/mozilla-inbound/rev/13778c26e7ca
https://hg.mozilla.org/mozilla-central/rev/bfd3a65c0feb
https://hg.mozilla.org/mozilla-central/rev/75571af38ce5
https://hg.mozilla.org/mozilla-central/rev/0d782874abea
https://hg.mozilla.org/mozilla-central/rev/7115f9e1f76f
https://hg.mozilla.org/mozilla-central/rev/ff55c196d541
https://hg.mozilla.org/mozilla-central/rev/35cf6a9b42f0
https://hg.mozilla.org/mozilla-central/rev/13778c26e7ca
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
(Assignee)

Updated

5 years ago
Blocks: 737273

Comment 57

5 years ago
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

5 years ago
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

5 years ago
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.
Depends on: 758996
Depends on: 765646
(Assignee)

Updated

5 years ago
Blocks: 765646
No longer depends on: 765646
(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.
No longer blocks: 765646
Depends on: 765646

Updated

5 years ago
Depends on: 769405
Depends on: 786630

Updated

5 years ago

Comment 61

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
Fully support the view  MySh
Absolutely unnecessary innovation!

Comment 67

5 years ago
Also see bug 786630
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

5 years ago
(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.

Updated

5 years ago
Depends on: 789484

Comment 70

5 years ago
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

5 years ago
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
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

4 years ago
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?
Depends on: 843284

Comment 74

4 years ago
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).
You need to log in before you can comment on or make changes to this bug.