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
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
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
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).
Keywords: qawanted, regressionwindow-wanted
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 768737
Reopening, this bug has tracking flags, bug 768737 doesn't.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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
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: + → -
"If the hack was known to cause problems like this bug, I'm not going to be too worried about it." OMG
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
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.
(This was raised a couple of times to the @FirefoxNightly twitter account)
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)
status-firefox17: --- → affected
status-firefox18: --- → affected
status-firefox19: --- → affected
Hardware: x86 → All
Version: 15 Branch → Trunk
Assignee: nobody → mounir
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago → 6 years ago
Resolution: --- → FIXED
status-firefox19: affected → ---
Target Milestone: --- → mozilla19
Version: Trunk → 15 Branch
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.. !
(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).
You need to log in before you can comment on or make changes to this bug.