Closed
Bug 1198324
Opened 9 years ago
Closed 9 years ago
Text on lock-screen is unreadable if you have a light background
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(blocking-b2g:2.5+)
RESOLVED
FIXED
blocking-b2g | 2.5+ |
People
(Reporter: cwiiis, Assigned: gweng)
References
Details
(Keywords: regression)
Attachments
(8 files)
[Blocking Requested - why for this release]: Time is unreadable on the lock-screen for light backgrounds.
In some previous button, we used to have a text-shadow on the text on the lock screen and this disappeared (somewhere around 2.0 I think?)
I've been meaning to file this for ages...
Comment 1•9 years ago
|
||
Patryk, is this by design, or is this a regression?
Flags: needinfo?(padamczyk)
Flags: needinfo?(gweng)
Updated•9 years ago
|
QA Whiteboard: [foxfood-triage]
Comment 2•9 years ago
|
||
Appears to be a regression, there should be a 5% black underlay.
Flags: needinfo?(padamczyk)
Assignee | ||
Comment 3•9 years ago
|
||
I've found this one is tricky: on master, if you reboot it, the shadow exists; however, don't reboot but only re-lock it, the shadow looks disappeared. Anyway I will check it.
Flags: needinfo?(gweng)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → gweng
Comment 5•9 years ago
|
||
Assignee | ||
Comment 6•9 years ago
|
||
Assignee | ||
Comment 7•9 years ago
|
||
Assignee | ||
Comment 8•9 years ago
|
||
Comment on attachment 8657644 [details]
[gaia] snowmantw:bug1198324 > mozilla-b2g:master
I've found this is because LockScreenNotification will add a transparent inline style to the background element when there is no notifications. It looks wrong because this causes that the words on a pure white, or a nearly pure white, background be unreadable. Now I remove that and verified the original notifications with masked color still works well according to what the WebIDE shows me (the HSL color still sticks on the masked background and is not affected by this patch), which should show the shadow as the last time we've done at Bug 1050052.
For UX: the result of this patch can be seen at the following two images: the 'before' is I set a pure white background behind the words, and you can see the words are totally unreadable; on the contrary, on the second image which shows the result after patching it, the words are readable and followed the last patch at Bug 1050052.
Attachment #8657644 -
Flags: ui-review?(firefoxos-ux-bugzilla)
Attachment #8657644 -
Flags: review?(timdream)
Updated•9 years ago
|
Attachment #8657644 -
Flags: review?(timdream) → review+
Updated•9 years ago
|
blocking-b2g: 2.5? → 2.5+
Keywords: polish → regression
Comment 10•9 years ago
|
||
Hi, do you think we really need a ui-reivew if this is just about fixing a regression of previously approved UX? Try to make sure we are addressing the bugs fast enough... thanks.
Flags: needinfo?(gweng)
Assignee | ||
Comment 11•9 years ago
|
||
I wouldn't bet on that: you know sometimes they even like to change the UI factors in spec in the progress of fixing things, even after we implemented their requests specifically. The notification opacity in v2.0, and the shrinking UI bouncing in v1.4 to v2.0 are the latest examples. So it's better to me to make sure things affect UX changes be reviewed by them.
And I don't feel I did it wrong to set an UI review with such long responding time: it's a reviewing performance failure that never been fixed, which is not my fault to make it not "fast enough".
However since you mentioned that, I don't mind just merge it and close the bug. But if anyone complain the change, I will refer to here to explain that.
Flags: needinfo?(gweng)
Assignee | ||
Comment 12•9 years ago
|
||
Comment on attachment 8657644 [details]
[gaia] snowmantw:bug1198324 > mozilla-b2g:master
Cancel UI review. See the comment above.
Attachment #8657644 -
Flags: ui-review?(firefoxos-ux-bugzilla)
Assignee | ||
Comment 13•9 years ago
|
||
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 14•9 years ago
|
||
Looks like this has broken again quite recently. Adding regressionwindow-wanted.
I wonder if we can add some automated testing to guarantee this doesn't break again? (perhaps a marionette test that actually checks pixel values?)
Comment 15•9 years ago
|
||
Hi Chris,
Could you provide the Environmental Variables for the build you are seeing this issue occur on? I am currently unable to repro this issue using today's central Flame.
Environmental Variables:
Device: Flame 2.5
BuildID: 20151027123532
Gaia: b6ede3d0fdec5fc922e9ca3401e60db461bf705c
Gecko: 4e164269cf888c03a18d1c4ea057bca68fb0ed32
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
QA Whiteboard: [foxfood-triage] → [QAnalyst-Triage?][foxfood-triage]
Flags: needinfo?(jmercado)
Updated•9 years ago
|
Flags: needinfo?(chrislord.net)
Updated•9 years ago
|
Flags: needinfo?(jmercado)
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?][foxfood-triage] → [foxfood-triage]
Comment 16•9 years ago
|
||
Still not seeing this on the following Flame 2.5 build.
Environmental Variables:
Device: Flame 2.5 Kk Fullflash (512mb)
BuildID: 20151028030421
Gaia: 2e89362de40a6c9c36525d36317fa1ae8e67e143
Gecko: fc706d376f0658e560a59c3dd520437b18e8c4a4
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Comment 17•9 years ago
|
||
Can we use something like what soundcloud does with song info. A compulsory black background on all text. This will not only make the lock screen look beautiful but it will solve this problem as well.
Flags: needinfo?(gweng)
Assignee | ||
Comment 18•9 years ago
|
||
I really don't know if this is a "good solution" to UX...So maybe you should ask them (firefoxos-ux-bugzilla@mozilla.com). And I think the unclear bug status also bothers me, so just wait to see if Chris Lord could report a valid environment and build number as Comment 15 said.
Flags: needinfo?(gweng)
Reporter | ||
Comment 19•9 years ago
|
||
I'll have to double check when I'm in the office, but this is just a master build, any within the last 3 days at least, without DEVICE_DEBUG (so you actually get the lock-screen) and with FTU disabled. You need to not have any notifications when you start up - as soon as you get a notification on the lock-screen, even once it's dismissed, the problem is fixed.
You can see this easily on startup if you have no notifications.
Flags: needinfo?(chrislord.net)
Comment 20•9 years ago
|
||
I cannot reproduce this bug. See attached screenshot. Rebooted several times without notifications and still can't see the issue.
NOT seeing the issue on:
Device: Flame 2.5
BuildID: 20151028030421
Gaia: 2e89362de40a6c9c36525d36317fa1ae8e67e143
Gecko: fc706d376f0658e560a59c3dd520437b18e8c4a4
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a1 (2.5)
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Device: Aries 2.5
BuildID: 20151028104739
Gaia: 2e89362de40a6c9c36525d36317fa1ae8e67e143
Gecko: fc706d376f0658e560a59c3dd520437b18e8c4a4
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Comment 21•9 years ago
|
||
I was also unable to reproduce this issue on the latest Aries build. We are going to need your environmental variables Chris, and maybe a new screenshot of the issue still occurring.
Comment 22•9 years ago
|
||
Here are my environmental variables for the previous comment
Environmental Variables:
Device: Aries 2.5
BuildID: 20151029124810
Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gecko: acb3f4ac5424181d3d4d73283668162137918cf1
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 45.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
Flags: needinfo?(ktucker)
Reporter | ||
Comment 23•9 years ago
|
||
So, this isn't happening quite how I expected - there background is rgba(0, 0, 0, 0.1), and I can confirm that in the WebIDE - but that's markedly different from how it looks after a dismissed notification. I'll attach screenshots.
Reporter | ||
Comment 24•9 years ago
|
||
Or not? I think maybe I was reproducing this and it's just fixed now? I'm going to flash the dogfood device that I'm seeing this on more regularly and see if it changes.
Reporter | ||
Comment 25•9 years ago
|
||
Reporter | ||
Comment 26•9 years ago
|
||
Reporter | ||
Comment 27•9 years ago
|
||
Confirmed I was mistaken - text is still pretty unreadable at rgba(0, 0, 0, 0.1), but not completely, so we should keep this as fixed and let UX decide sometime if that's enough of a tint. I think text shadow in addition, as we have on the home screen, would make text a lot more readable.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Flags: needinfo?(jmercado)
Keywords: regressionwindow-wanted
Updated•9 years ago
|
Flags: needinfo?(jmercado)
Updated•9 years ago
|
QA Whiteboard: [foxfood-triage] → [foxfood-triage][QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•