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

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Alice0775 White]

Attachment: 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 (:karlt)]

It is (just) there, with GTK at least, but very very faint.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

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)]

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 5

[Dão Gottwald [:dao]]

Reopening, this bug has tracking flags, bug 768737 doesn't.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

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)]

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]

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 13

[mizuapo]

"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]

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]

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 18

[Paul Rouget [:paul]]

(This was raised a couple of times to the @FirefoxNightly twitter account)

Comment 19

[mbulman]

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)]

Bug 737786 is being worked on and should fix that issue.

Comment 21

[Oskar]

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)]

(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).