Closed Bug 815752 Opened 12 years ago Closed 10 years ago

[Twitter] Composing new tweet, the "what's happening" should be grey

Categories

(Core :: Layout: Text and Fonts, defect, P3)

Product:
Core
Component:
Layout: Text and Fonts
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: zfang, Assigned: jforrester)

References

(
URL
)

Details

(Whiteboard: visual design) 

Currently the "what's happening" hint in the input field is black. Should make it grey so that it doesn't look like it's actual content.
Whiteboard: visual design
Blocks: twitter.com
Component: Gaia → Mobile
Product: Boot2Gecko → Tech Evangelism
Blocks: b2g-twitter
This works fine for me (Firefox 23 desktop) - and it doesn't seem like a TE issue, since they are using the @placeholder attribute and rely on default styling. Test case:
data:text/html,<textarea placeholder="What's happening?"></textarea>
URL: http://twitter.com/
Component: Mobile → Layout: Text
Product: Tech Evangelism → Core
Version: unspecified → Trunk
Zhenshuo Fang, which exact Gecko version were you testing in?
Flags: needinfo?(zfang)
Maybe duplicate of or related to bug 737786, which was fixed on central only a few weeks before this bug was filed.
I can confirm its happening on FxOS1.1 still.  

David: is there a chance the fix for bug 737786 will be backported to gecko 18.1 for 1.1?
Flags: needinfo?(zfang) → needinfo?(dbaron)
I don't know of any plans to, and I can't say if that's reasonable without reference to documentation of the 1.1 release schedule, though given the amount of Web compatibility testing we get on that branch, I'm inclined to say it's a bad idea to try to backport.

Do you even know that that's the issue?  As far as I can see it's just a guess that I made.
Flags: needinfo?(dbaron)
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #5)
> I don't know of any plans to, and I can't say if that's reasonable without
> reference to documentation of the 1.1 release schedule, though given the
> amount of Web compatibility testing we get on that branch, I'm inclined to
> say it's a bad idea to try to backport.
> 
> Do you even know that that's the issue?  As far as I can see it's just a
> guess that I made.

I don't know for certain its the issue (or tbh, how I'd find out either way).
If you have access to builds before and after that fix, simply try the data: URL test case in comment 1.
Assignee: nobody → hkirschner
Priority: -- → P3
Status: NEW → ASSIGNED
Could not reproduce on Keon geeksphone device using nightly build 20131028225522 v1.2

but problem still persists on v1.1
Assignee: hkirschner → jforrester
Cross-posted to Twitter's Jira
Could NOT reproduce on Keon v1.2 and Peak v1.2, but problem still persists on Inari v1.1

Do we have any updates on when this bug may be fixed?
(In reply to Jeremy from comment #9)
> Cross-posted to Twitter's Jira

Um, it's a Firefox bug though - nothing Twitter should do about this.

In reply to Nicole Fong from comment #10)
> Could NOT reproduce on Keon v1.2 and Peak v1.2, but problem still persists
> on Inari v1.1
> Do we have any updates on when this bug may be fixed?

OK, so it *is* fixed for 1.2, no? It sounds like you can just close this bug as fixed or find the master bug it is a duplicate of. Yay! :-)
Hey Hallvord, nice to see you again! 

If it's just an issue in the browser engine which has since been fixed, then more than happy to close this on the Twitter side, 

It doesn't make sense for us to enable a work around for browser quirks!
Nice seeing you again too Jeremy ;-). Yes, please close the Twitter bug - there's no point in trying to work around this, your code is perfect as-is :-D
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.