321.70 KB, image/png
Created attachment 688255 [details] Shows comparison between actual phones screen shot and original design Confirmation overlays have always the same structure Title / Line / Description If there's no title, the line stays there anyways. Never use 2 lines "closing" the message. There's only one at the top of the message. See attachment for comparison
Assignee: nobody → kaze
Whiteboard: visual design, UX P1
Pavel, do you want to steal this bug?
blocking-basecamp: --- → ?
For the bug and the image attached: If you are talking about the confirmation dialog living in system app, it should not cover fullscreen. It's an app specific dialog, which should not block the usage of status bar and utility tray. If I misunderstand something, please ignore my comment :)
You mean this dialog screens are not from system and it's just living inside each app? If so I should re-report this bug inside apps.
I think there should be a consistent look throughout the system. You may have to report one for the system and one for the apps? Perhaps I am wrong, ... it's not just about the full screen versus showing the notification. Comment 0, indicates that there should be a consistent look for all the overlays... is that correct Victoria?
Priority: -- → P4
Whiteboard: visual design, UX P1 → visual design, UX P2, [TEF_REQ]
Short story: the system app's modal confirm dialog triggered by window.confirm() has the wrong HTML structure to trigger the confirm.css styles. Specifically, they need to use a <form> element with role="dialog" and data-type="confirm". It also seems to be failing to meet the UX/VD guidelines by explicitly setting the dialog title to "" rather than a localized string for "Confirmation". Longer story / context: For e-mail bug 838139 we are using window.confirm() to prompt about opening a hyperlink found in an e-mail. In most other places we manually pop up a confirm dialog ourselves using our internal ConfirmDialog helper. It uses DOM templates from our index.html that do confirm to confirm.css's needs. The problem in bug 838139 is that because the confirm.css CSS is not in play, "word-wrap: break-word" does not get used, so our long URL goes off the edge of the screen. While we can convert this hold-out and one other in the e-mail app over to our in-app solution, it seems like we should fix the system app. It's not clear if we're trying to avoid people calling window.confirm() or what, so I'll send a message to dev-gaia referencing this bug.
Hey Fang, this is a really old bug.. but can you check that the confirm screen is correct now? If so we can close this bug.
Component: Gaia::System → Gaia::E-Mail
Those confirm screens are correct now. I think we can close this bug. Thanks!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.