Last Comment Bug 769405 - No caret appears in an empty <input> if placeholder is defined
: No caret appears in an empty <input> if placeholder is defined
Status: RESOLVED FIXED
[fixed-in-bug-737786]
: regression
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: 15 Branch
: All All
: -- normal with 7 votes (vote)
: mozilla19
Assigned To: Mounir Lamouri (:mounir)
:
Mentors:
: 768737 786342 786609 786778 786989 789419 789952 838645 (view as bug list)
Depends on: 737786
Blocks: 673873
  Show dependency treegraph
 
Reported: 2012-06-28 12:07 PDT by Alice0775 White
Modified: 2014-10-07 01:04 PDT (History)
27 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
affected
-
affected
affected
affected


Attachments
testcase (223 bytes, text/html)
2012-06-28 12:07 PDT, Alice0775 White
no flags Details

Description Alice0775 White 2012-06-28 12:07:08 PDT
Created attachment 637624 [details]
testcase

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/9bf5e71c5746
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120628065213

No caret appears in an empty <input> if placeholder is defined

Steps to Reproduce:
1. Stat Firefox with New profile
2. Open testcase
3. Click inpit area to focus

Actual Results:
 No caret appears

Expected Results:
 The caret should appear at the top of the placeholder
Comment 1 Karl Tomlinson (ni?:karlt) 2012-06-28 14:18:28 PDT
It is (just) there, with GTK at least, but very very faint.
Comment 2 Lukas Blakk [:lsblakk] use ?needinfo 2012-07-02 15:29:01 PDT
I can reproduce this on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120702 Firefox/15.0a2 - tracking and setting flag for a regression window.
Comment 3 Frank Yan (:fryn) 2012-07-02 16:17:50 PDT
We know the regression window.
The reason for this bug is the decision (with which I disagreed) made in bug 673873 to continue to allow styles being applied to an <input/> element to be inherited down to its placeholder and caret anonymous nodes, while we wait for :-moz-placeholder to be re-implemented as a pseudo-element (::-moz-placeholder).
Comment 4 Mounir Lamouri (:mounir) 2012-07-09 08:08:06 PDT

*** This bug has been marked as a duplicate of bug 768737 ***
Comment 5 Dão Gottwald [:dao] 2012-07-09 08:13:12 PDT
Reopening, this bug has tracking flags, bug 768737 doesn't.
Comment 6 Dão Gottwald [:dao] 2012-07-09 08:13:22 PDT
*** Bug 768737 has been marked as a duplicate of this bug. ***
Comment 7 Lukas Blakk [:lsblakk] use ?needinfo 2012-07-18 16:45:50 PDT
Assigning to Frank for now, unless there is someone else who can drive this, as we haven't shipped this regression yet so it can still be fixed in beta.
Comment 8 Frank Yan (:fryn) 2012-07-18 23:38:39 PDT
This is what happened so far:

I fixed bug 673873, and I suggested that we hard-code the placeholder as DarkGray (#a9a9a9) and disable support for :-moz-placeholder (a pseudo-class) until we can properly implement it as ::-moz-placeholder (a pseudo-element), especially it's the only way to we can fix bug 673873 quickly without causing problems like this bug (bug 769405). We should be okay with removing support for vendor-prefixed CSS, especially since this one doesn't have a standards proposal.

mounir and bz were not okay with breaking :-moz-placeholder, so they suggested a hack that styles the caret as -moz-Field, which usually resolves to black. I implemented the hack, and they approved it, and I landed that. Of course, the hack was known to cause problems like this bug.

I suggest that we go with my proposal while keeping bug 673873 fixed. I'll work on bug 737786 and get that fixed as soon as I can. I can write a patch for that if drivers approve. If that's not okay, someone can back out the fix for bug 673873.
Comment 9 Lukas Blakk [:lsblakk] use ?needinfo 2012-07-24 16:50:23 PDT
If the hack was known to cause problems like this bug, I'm not going to be too worried about it. It's the best decision (for now) and I'll untrack and so you can continue to work on bug 737786 without the pressure of release tracking.  Unless this starts to show up in a lot of SUMO user feedback, we can ship with this regression until it's completely resolved.
Comment 10 Loic 2012-08-29 16:46:21 PDT
*** Bug 786778 has been marked as a duplicate of this bug. ***
Comment 11 Loic 2012-08-30 05:40:00 PDT
*** Bug 786989 has been marked as a duplicate of this bug. ***
Comment 12 Dão Gottwald [:dao] 2012-09-04 12:37:51 PDT
*** Bug 786342 has been marked as a duplicate of this bug. ***
Comment 13 mizuapo 2012-09-05 01:17:27 PDT
"If the hack was known to cause problems like this bug, I'm not going to be too worried about it." 

OMG
Comment 14 Jefferson 2012-09-05 15:27:03 PDT
The I-bar cursor appears to take on the color of the placeholder text, and therefore may be nearly invisible until the user types a character to clear that text. This was raised on SuMo in relation to a site with a search box that uses a #a2a2a4-on-rgba(0,0,2,0.2) color scheme. https://support.mozilla.org/questions/936421
Comment 15 brian.g.gates 2012-09-05 16:44:31 PDT
This bug has huge implications of (un)usability for dark-themed sites using placeholders.

When a user clicks into an input, the caret is invisible, giving the user a false sense of having failed to achieve focus.

I've had to override the native placeholder support to avoid this.
Comment 16 XtC4UaLL [:xtc4uall] 2012-09-10 03:49:53 PDT
*** Bug 789419 has been marked as a duplicate of this bug. ***
Comment 17 Loic 2012-09-10 10:23:09 PDT
*** Bug 789952 has been marked as a duplicate of this bug. ***
Comment 18 Paul Rouget [:paul] 2012-09-26 03:28:41 PDT
(This was raised a couple of times to the @FirefoxNightly twitter account)
Comment 19 mbulman 2012-10-17 12:22:49 PDT
So as of right now there is no workaround for this while using the native placeholder, correct?  (Since the caret is hardcoded to moz-field)
Comment 20 Mounir Lamouri (:mounir) 2012-10-18 03:13:44 PDT
Bug 737786 is being worked on and should fix that issue.
Comment 21 Oskar 2012-12-25 06:33:23 PST
I have firefox 17.0.1 win7 and it appears here as if this bug should already be fixed and only apply to firefox 15?? This is not true unless I'm misunderstanding this info.. !
Comment 22 Scoobidiver (away) 2013-01-06 05:24:46 PST
(In reply to Oskar from comment #21)
> I have firefox 17.0.1 win7 and it appears here as if this bug should already
> be fixed and only apply to firefox 15?? This is not true unless I'm
> misunderstanding this info.. !
The bug appeared in version 15 (Version field) and is fixed in version 19 (Target Milestone field).
Comment 23 Mounir Lamouri (:mounir) 2013-02-06 10:26:41 PST
*** Bug 838645 has been marked as a duplicate of this bug. ***
Comment 24 Stefan Weiss [:sir_none] 2014-10-07 01:04:09 PDT
*** Bug 786609 has been marked as a duplicate of this bug. ***

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