Closed Bug 1058675 Opened 8 years ago Closed 8 years ago
[SHB] System Custom Dialogs have their buttons overlaid by the SHB
Currently all custom dialogs generated by the System have their content overlaid by the software home button. This is caused by them being injected into the body by default instead of the #screen element which contains the necessary styles for them to be adjusted to account for the SHB height. All custom dialogs in the System should be fixed so the SHB doesn't overlay its content.
+++ This bug was initially created as a clone of Bug #1054716 +++ From Tony Chung: i see the clipped buttons on the Install update screen. See screenshot. 1) install 8/25 2.1 nightly build on flame Gaia e424c85eda87a40c0fa64d6a779c3fa368bf770b Gecko https://hg.mozilla.org/mozilla-central/rev/daa84204a11a BuildID 20140825040204 Version 34.0a1 ro.build.version.incremental=110 ro.build.date=Fri Jun 27 15:57:58 CST 2014 B1TC00011230 2) enable soft home button in settings 3) settings > Device info> check for updates 4) find an update, and apply it via the status bar 5) when update is completed downloading, verify the install update screen is covered. Expected: - buttons are not covered ActuaL: - buttons covered
The patch for bug 1048593 should have resolved button clipping on dialogs when displayed with the SHB, but custom dialogs didn't inherit this fix because they were being appended to the body and not the #screen element. This patch changes custom dialogs to be appended to the #screen element, thereby inheriting the correct styles.
Attachment #8479181 - Flags: review?(etienne)
Comment on attachment 8479181 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/23324 This shared lib is used by a bunch of apps (camera, dialer...) so I'm not comfortable with adding system-only stuffs to it. Also we have z-index-levels for dialogs already, we should not piggy back on the system-notification-banner level. (and maybe we don't need any change here since there's no transitions on those dialogs) Is there something preventing us from target #dialog-screen with a system css rule?
Attachment #8479181 - Flags: review?(etienne) → review-
Summary: [SHB] Install Update dialog buttons are clipped by the SHB → [SHB] System Custom Dialogs have their buttons overlaid by the SHB
No longer blocks: 1048611
Duplicate of this bug: 1048611
No longer blocks: 1048609
Duplicate of this bug: 1048609
Attachment #8479914 - Flags: review?(etienne) → review+
Comment on attachment 8479914 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/23375 Requesting uplift as the UI will be unusable for users of these dialogs if using the software home button. Functional polish. [Bug caused by] (feature/regressing bug #): bug 1036339 [User impact] if declined: dialogs unusable with software home button enabled [Testing completed]: yes, manual and automated [Risk to taking this patch] (and alternatives if risky): low, should only impact system-level "custom" dialogs [String changes made]: n/a
Attachment #8479914 - Flags: approval-gaia-v2.1?
Attachment #8479914 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
This issue is verified fixed on Flame 2.1 & Flame 2.2: Flame 2.1 (full flash) Environmental Variables: Device: Flame 2.1 BuildID: 20141008000201 Gaia: d71f8804d7229f4b354259d5d8543c25b4796064 Gecko: 7fa82c9acdf2 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Flame 2.2 (full flash) Environmental Variables: Device: Flame 2.2 Master BuildID: 20141007040205 Gaia: 83de447d9ae9a59459d7a445f9348a254c661850 Gecko: 9ee9e193fc48 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 The dialog buttons are NOT overlaid by SHB, and everything on the screen is displayed properly.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
I don't join the bug before. But the patch makes regression about no device name while confirming Bluetooth file transfer.(bug 1082935) The device name which we get from a async call(https://github.com/mozilla-b2g/gaia/pull/23375/files#diff-171571dcd7d2b8608173bb1b312b6e4eL184). The modification patch assigned an empty 'deviceName' before we get paired device from async all.
Ian, you are correct, this would have caused a problem, but it was resolved again  through bug 1043556 which would put device name back in the correct position.  https://github.com/mozilla-b2g/gaia/commit/4f24d93fdd8374347d96af07e75cd3e50705fbb7#diff-171571dcd7d2b8608173bb1b312b6e4eR187
Yes, thanks for your point out. But the patch  is not uplifted to Gaia/v2.1. I have comment in bug 1043556.(https://bugzilla.mozilla.org/show_bug.cgi?id=1043556#c17) Let's track the regression via bug 1082935, bug 1043556.
You need to log in before you can comment on or make changes to this bug.