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

RESOLVED FIXED in mozilla19

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: Alice0775 White, Assigned: mounir)

Tracking

({regression})

15 Branch
mozilla19
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15- affected, firefox16- affected, firefox17 affected, firefox18 affected)

Details

(Whiteboard: [fixed-in-bug-737786])

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

5 years ago
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
(Reporter)

Updated

5 years ago
OS: Windows 7 → All
It is (just) there, with GTK at least, but very very faint.
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.
status-firefox15: --- → affected
status-firefox16: --- → affected
tracking-firefox15: ? → +
tracking-firefox16: ? → +
Keywords: qawanted, regressionwindow-wanted

Comment 3

5 years ago
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).
Blocks: 737786
Keywords: qawanted, regressionwindow-wanted
(Assignee)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 768737
(Assignee)

Updated

5 years ago
No longer blocks: 737786
Reopening, this bug has tracking flags, bug 768737 doesn't.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Updated

5 years ago
Duplicate of this bug: 768737
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.
Assignee: nobody → fryn

Comment 8

5 years ago
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.
Assignee: fryn → nobody
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.
tracking-firefox15: + → -
tracking-firefox16: + → -

Updated

5 years ago
Duplicate of this bug: 786778

Updated

5 years ago
Duplicate of this bug: 786989

Updated

5 years ago
Duplicate of this bug: 786342

Comment 13

5 years ago
"If the hack was known to cause problems like this bug, I'm not going to be too worried about it." 

OMG

Comment 14

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

5 years ago
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.
Duplicate of this bug: 789419

Updated

5 years ago
Duplicate of this bug: 789952

Comment 18

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

Comment 19

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

Comment 20

5 years ago
Bug 737786 is being worked on and should fix that issue.
Depends on: 737786
(Assignee)

Updated

5 years ago
status-firefox17: --- → affected
status-firefox18: --- → affected
status-firefox19: --- → affected
Hardware: x86 → All
Version: 15 Branch → Trunk

Updated

5 years ago
Assignee: nobody → mounir
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-bug-737786]

Updated

5 years ago
status-firefox19: affected → ---
Target Milestone: --- → mozilla19
Version: Trunk → 15 Branch

Comment 21

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

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

Updated

5 years ago
Duplicate of this bug: 838645
Duplicate of this bug: 786609
You need to log in before you can comment on or make changes to this bug.