Last Comment Bug 758996 - placeholder should disappear when text input is clicked
: placeholder should disappear when text input is clicked
Status: RESOLVED DUPLICATE of bug 807613
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: 19 Branch
: All All
: -- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 789484 824434 830165 (view as bug list)
Depends on: 807613
Blocks: 843284 673873
  Show dependency treegraph
 
Reported: 2012-05-27 16:55 PDT by Dragoș Valentin, Rădulescu
Modified: 2013-11-07 09:01 PST (History)
24 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments

Description Dragoș Valentin, Rădulescu 2012-05-27 16:55:47 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1
Build ID: 20120527030515

Steps to reproduce:

It seems that in the the Nightly version of Firefox/15.0a1, the placeholder is not well interpreted anymore. In FF 12 it works right.

The text is there, but if you click the area, it doesnt disappear. 
Have as example the search form from FF:
http://www.mozilla.org/contact/
Comment 1 Dragoș Valentin, Rădulescu 2012-05-27 19:58:30 PDT
The bug is in the (google)search and address bar, in the browser. 
In the address bar you will see the "Go to Website" placeholder.
Comment 2 Byron Jones ‹:glob› [PTO until 2016-10-10] 2012-05-28 22:02:01 PDT
i believe this is intentional, caused by bug 673873.
Comment 3 Karl Tomlinson (:karlt) 2012-06-17 19:03:23 PDT
Bug 673873 comment 9 points out that the placeholder should disappear when the input is clicked.
Comment 4 Keith "SuPeR K!" Kocienski 2012-06-17 19:10:16 PDT
The new behavior is consistent with what other major browsers have implemented. I believe this should be marked as WONTFIX.
Comment 5 N. Kasabov 2012-08-30 11:46:46 PDT
To change to this new behavior was i terrible decision. Is there any way to return the old one?
Comment 6 Dragoș Valentin, Rădulescu 2012-08-31 03:40:02 PDT
(In reply to Keith "SuPeR K!" Kocienski from comment #4)
> The new behavior is consistent with what other major browsers have
> implemented. I believe this should be marked as WONTFIX.

As FF15 was officially released, i saw it is still in there, and i come to check.

Which major browsers do you mean more exactly....?
I see that only Chrome has this same silly behaviour. 
Opera has it too, but at least they make the colour writing "weaker" when you click the area.
Safari has the previous behaviour, which i like.


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. The old/previous behaviour is better and  should be restated.
 
The way you made it now is extremely stupid and annoying. 

Why would you ever want to see the comment when you click the area !?
When you click the area, the message should disspear instantly so that you may write what you want to. 
NOT To make it disappear as you are typing....... No one looks at the screen to see what they type. They look at the keyboard. 
So if you start typing. You it doesnt make a difference if it disappears or not. 

This really disturbs me. Please switch back, or allow us a way on doing so.
Comment 7 Dragoș Valentin, Rădulescu 2012-08-31 15:18:17 PDT
Even the search box from the start menu, in win7 makes the placeholder text disappear when you click the area. If you get ready to type, it should disappear, not stay there and disappear as you type watching the keyboard. You dont give a damn what happens when you are not looking. 

I cannot understand who would consider this change good.
I wonder how come that the people that work on FF could ever have allowed this dumb change. 

I hope that what i wrote above will make you reconsider to reinstate the previous functionality.
Comment 8 Nathan Williams 2012-08-31 16:14:02 PDT
Preserving the text on focus does not feel intuitive to me either.  The example of the Win7 start menu search box is a good one.  The "Search all add-ons" field in Firefox itself behaves this way as well.  I'm sure there are many other examples.  Unfortunately, at this point, all the major browsers seem to be aligned on doing it this way, and the spec was changed to allow it.

http://lists.w3.org/Archives/Public/public-html-bugzilla/2012Feb/0254.html
http://html5.org/r/6782
https://bugs.webkit.org/show_bug.cgi?id=73629
http://code.google.com/p/chromium/issues/detail?id=103025
http://stackoverflow.com/questions/2610497/change-an-inputs-html5-placeholder-color-with-css

The last link shows how to restore the prior behavior with CSS.  If you have the Stylish plugin, you can do so globally with a user stylesheet:

input:focus:-moz-placeholder { color: transparent !important; }
Comment 9 Dragoș Valentin, Rădulescu 2012-09-01 12:49:30 PDT
So what if all major browsers have it. That doesnt mean they are any better.
Firefox disappoints me with each update. I find this "improvement" quite retarded. 

Its sad that we have to use hacks to bring back the previous functionality. 
Did anyome read my explications on why this is wrong ?
Comment 10 Mike Kaply [:mkaply] 2012-09-07 10:39:08 PDT
*** Bug 789484 has been marked as a duplicate of this bug. ***
Comment 11 Cocinero 2012-09-09 15:18:24 PDT
To get back the pre-15 behavior, see bug 786630 comments #6 and/or #13. You don't need another extension, it's only two files inside your profile/chrome/ directory, and works with both Firefox and Thunderbird (this new behavior was driving me nuts in the search boxes in both applications).

Thank you, as well, for fighting back! :)
Comment 12 Mardeg 2012-12-23 23:59:54 PST
*** Bug 824434 has been marked as a duplicate of this bug. ***
Comment 13 Dragoș Valentin, Rădulescu 2012-12-24 01:12:38 PST
Recently, my uncle bought a laptop and i put FF on it.
That was the first time he used with a computer.

I was teaching him how to Google for stuff, from the top right input area, in ff, and he asked me; why doesnt the writing go away when i click ?
His reaction was to delete the placeholder writing. He couldn't and it confused him.

Please, really do be rational. Do you people really see this as a good change?

When the person clicks the area, the bloody text SHOULD DISAPPEAR!
Why show the blinking text line BEFORE a background text?
It is really Retarded. Please revert to the old functionality.
Comment 14 brunoais 2012-12-24 03:26:22 PST
@Radulescu Dragos-Valentin
Check here:
https://bugzilla.mozilla.org/show_bug.cgi?id=807613

When this is implemented in a stable version of firefox you can change that using the about:config.
Comment 15 Sebastian 2012-12-24 07:54:48 PST
You also see grey text in the field while being on Facebook still even though selected. And other websites have this issue with Firefox. It's not just The URL bar and the Google search. It messes up Facebook and other websites text boxes sometimes or a great majority of the time.
Comment 16 Dragoș Valentin, Rădulescu 2012-12-24 13:19:59 PST
I know Sebastian. It affects the way the placeholder element is interpreted by firefox.

It is extremely annoying. I dont see any rational reason on why on earth they think this change as a good one, as it isnt !!! 

EVERYONE expects the text to disappear when they select the area. 
If not, they just tend to try and delete the text so that they may type what they want.

I explained that even a brand new PC User expected it to work that way.

@Brunoaiss,
That patch looks great to me ! 
You have my sincere congratulations and thanks. :)

But, please fight to make the old way(2) the default of firefox.
The 2nd option is what it should be like everywhere.
Comment 17 Mardeg 2012-12-24 15:04:48 PST
Added "(make dom.placeholder.show_on_focus default to false)" to the summary and adjusted the version to 19 since that's when the pref landed. Current testing for this is in http://aurora.mozilla.org/
The decision to WONTFIX this bug probably still stands and reopening it with a derogatory remark is against bugzilla ettiquette, but I'll leave it to drivers/module owners now that the decision is down to a default pref value.
Comment 18 Alex Shilov 2012-12-24 17:06:09 PST
Thank you Mardeg. 
I think that only few people actually know that this pref is exists, can you describe, which testing for this in Aurora channel? Is there such testing in Nightly channel? Is there any chance that placeholder.show_on_focus value will be default to false?
Comment 19 Karl Tomlinson (:karlt) 2012-12-26 15:12:44 PST
(In reply to Keith "SuPeR K!" Kocienski from comment #4)
> The new behavior is consistent with what other major browsers have
> implemented. I believe this should be marked as WONTFIX.

Having other browsers with the same quirks is not a good reason to not fix this.
Following OS behaviour would make more sense.

Having the placeholder disappear on click seems a good way to still show the hint when the input has default focus, but to remove the confusion when people are confused by it.
Comment 20 Alex Keybl [:akeybl] 2013-01-03 15:27:17 PST
This is not an issue specific to Firefox 19. A module owner (possibly with input from the product team) will need to make the final decision here.
Comment 21 Dragoș Valentin, Rădulescu 2013-01-04 08:43:53 PST
Right. Notice how bothered i am of this even if i am not affected by it, as i use stylish to enable the old behaviour. It is just bothering me knowing that the browser i like has such silly default settings which you cant even decide to change them from its settings. It makes no sense to keep the text there till you start typing.
Comment 22 Alex Shilov 2013-01-04 10:38:17 PST
to Dragos Valentin: Thats right. Many people bothered. Since the decision was very unexpected. We all heard about it when it was too late. When bug 673873 was fixed i wrote tons of text and usability argue (see comments since 673873#57). 

I briefly repeat (for the module owner who make decision), that the main problem of this behavior is that it confuses users:
When the user clicks on input and placeholder disappear, he thinks: "Oh. There was placeholder".
When the user clicks on input and placeholder stays visible, he thinks: "What is it? Is it placeholder or value?". 

I think that IS an usability issue.

That authors of the bug (bug 673873) said, is what when user clicks on the input and placeholder disappear he just could totally forgot what the placeholder was a second ago. 

IMHO that IS NOT an issue.
Comment 23 Mounir Lamouri (:mounir) 2013-01-04 11:59:40 PST
In my opinion, there is no point in trying to go against the platform conventions. On Mobile, AFAIK, it is common to keep the placeholder after you clicked on a text field (I haven't checked recently on iOS). On MacOS X, last I checked, keeping the placeholder was the system behaviour too. On Windows 7, I think it was very inconsistent (some system textfields were keeping the placeholder, some were not). I wonder what Windows 8 does. On GTK, keeping the placeholder isn't the default behaviour.

What I think we could do is try to match the system's behaviour so we could flip the preference on GTK and see what we do on Windows. Other platform would stay as-is.
Comment 24 N. Kasabov 2013-01-04 13:22:45 PST
Isn't it better to have config option (whatever be the default) and all live happily?
Comment 25 brunoais 2013-01-04 13:49:50 PST
(In reply to N. Kasabov from comment #24)
> Isn't it better to have config option (whatever be the default) and all live
> happily?

#807613
Comment 26 Karl Tomlinson (:karlt) 2013-01-07 14:19:11 PST
(In reply to Mounir Lamouri (:mounir) from comment #23)
> In my opinion, there is no point in trying to go against the platform
> conventions.

Sounds reasonable, though I do fear that the persistence of the placeholder on some platforms might lead designers to assume that it is persistent on all platforms.

> On Windows 7, I think it was very inconsistent (some system textfields were
> keeping the placeholder, some were not). 

Interesting that on Win 7 "Search computer" doesn't seem to follow behavior of
"Search programs and files" and "Search control panel".  I guess that is because
"Search computer" isn't the initial focus of the window, but it is odd that
the behavior difference continues after initial focus is no longer relevant.

Following the behaviour of the Win 7 initial focus textfield (placeholder shown on focus, but not after click) for all textfields seems a consistent and sensible compromise to me.

> On GTK, keeping the placeholder isn't the default behaviour.

No, but following the Win 7 initial focus textfield behaviour would also seem a sensible compromise for GTK without being such a major change as reverting to not showing the placeholder at all in some situations.

Reverting summary because dom.placeholder.show_on_focus is not the only way to fix this.
Comment 27 Mark D. 2013-01-07 20:18:30 PST
I appreciate the current behaviour of Firefox (keeping the placeholder) because it gives us more flexibility with designing and building web apps. For example, now we can have a very simple login screen with 2 text inputs with the field name (username and password) as the placeholder text.

We also auto focus the username field for mobile/desktop users so they can start typing right away (usability plus) so if the placeholder went away, the user would have to guess the first field is the username field. Just my 2 cents.
Comment 28 brunoais 2013-01-08 00:49:06 PST
(In reply to Mark D. from comment #27)
> We also auto focus the username field for mobile/desktop users so they can
> start typing right away (usability plus) so if the placeholder went away,
> the user would have to guess the first field is the username field. Just my
> 2 cents.
That's not how @placeholder is supposed to be used. The @placeholder is supposed to be used as extra information, not as the only information.

Anyway, I still prefer the option that, if the user focuses the form element, text should disappear.
If the element is autofocused, then the text should act according to an option: Disappear right away or wait x seconds to disappear or stay until, at least, one character is typed.
In the: the element is not focused situation. Seems like we have an agreement.
Comment 29 Dão Gottwald [:dao] 2013-01-15 13:52:04 PST
*** Bug 830165 has been marked as a duplicate of this bug. ***
Comment 30 keepitsimplestupid 2013-01-15 14:22:13 PST
As I said earlier, not having the text go away indicates that my trackpad has accidentally been turned off or the LEFT-CLICK key is broken.

BTW, website behavior is all over the map.  I can find examples where when you click on the box it goes away and places where it doesn't.  So maybe it's time to define the behavior in html5?

So, maybe it's time for a document Entitled "internet Guidelines".

Mozilla decided that it must follow the strictness of Java variables be initialized first even though it breaks some websites and it doesn't follow other browsers conventions.  The argument for "other browsers" act like the search bar does now is now not a valid argument.
Comment 31 Dragoș Valentin, Rădulescu 2013-02-20 06:48:01 PST
Ticket 807613 was fixed, and we have the option to re enable this old behaviour. I will mark it Resolved. Thank you.

*** This bug has been marked as a duplicate of bug 807613 ***

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