Closed
Bug 1011071
Opened 11 years ago
Closed 11 years ago
[B2G] Dialer screen is shown cut off when Dialer runs in background and the user receives missed call on the locked screen
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)
Tracking
(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 fixed)
Tracking | Status | |
---|---|---|
b2g-v1.4 | --- | unaffected |
b2g-v2.0 | --- | fixed |
People
(Reporter: nkot, Assigned: etienne)
References
Details
(Keywords: regression)
Attachments
(5 files)
Description:
When the user receives missed call while having their device locked and the Dialer app running in the background, the Dialer screen will be displayed cut off after unlocking device.
Repro Steps:
1) Updated Open_C to BuildID: 20140515040207
2) Open Dialer app
3) Press Power button to lock the screen
4) Receive missed call on your Test device
5) Unlock the screen
Actual:
Dialer screen is shown cut off
Expected:
Dialer screen appears normally
Environmental Variables:
Device: Open_C master m-c
BuildID: 20140515040207
Gaia: 3a1d67246a79e3632c3b3f2460a25291e7e2714c
Gecko: e4843f4f08a7
Version: 32.0a1
Firmware Version: P821A10V1.0.0B06_LOG_DL
Notes:
Repro frequency: 100%, 2/2 devices
See attached screenshot
Reporter | ||
Comment 1•11 years ago
|
||
the issue does NOT reproduce on today's 1.4 Open_C
Device: Open_C 1.4 MOZ
BuildID: 20140515000202
Gaia: 2e97bee6bb79d3577dba1bf2a1bbfcba64ee99ab
Gecko: 0cb91945f404
Version: 30.0
P821A10v1.0.0B06_LOG_DL
Reporter | ||
Comment 2•11 years ago
|
||
Reporter | ||
Comment 3•11 years ago
|
||
More details:
- repros on Buri trunk
- have checked with 'edge gestures' On and Off and repro in both scenarios
Comment 4•11 years ago
|
||
We need a video.
Component: Gaia::System::Lockscreen → Gaia::System::Window Mgmt
Keywords: qawanted
Comment 5•11 years ago
|
||
Please see this video:
https://www.youtube.com/watch?v=54R-T8WUseA&edit=vd
Keywords: qawanted
QA Contact: jmercado
Updated•11 years ago
|
blocking-b2g: --- → 2.0?
Keywords: regressionwindow-wanted
Comment 6•11 years ago
|
||
Comment 7•11 years ago
|
||
Comment 8•11 years ago
|
||
The same issue affects calendar and clock (for example). I think that the all apps with fix height (without scroll) are affected by this issue.
I attached two screenhot for calendar and clock.
Comment 9•11 years ago
|
||
B2g Inbound Regression Window:
Last Working Environmental Variables:
Device: Buri
BuildID: 20140513133215
Gaia: b7fb829150e5e4b5310c71286c173eebb495bf4e
Gecko: 75d37393c2d3
Version: 32.0a1
First Broken Environmental Variables:
Device: Buri
BuildID: 20140513135708
Gaia: a13d42ab5240008e042d0c61bf9c9d05174e70e4
Gecko: 4bf31b954518
Version: 32.0a1
Last Working gaia / First Broken gekko - Issue does not reproduce
Gaia: b7fb829150e5e4b5310c71286c173eebb495bf4e
Gecko: 4bf31b954518
First Broken gaia / Last Working gekko - Issue reproduces
Gaia: a13d42ab5240008e042d0c61bf9c9d05174e70e4
Gecko: 75d37393c2d3
B2g-Inbound Pushlog: https://github.com/mozilla-b2g/gaia/compare/b7fb829150e5e4b5310c71286c173eebb495bf4e...a13d42ab5240008e042d0c61bf9c9d05174e70e4
Keywords: regressionwindow-wanted
Comment 10•11 years ago
|
||
Caused by bug 1003870.
Alive - Can you take a look?
Blocks: 1003870
Flags: needinfo?(alive)
Updated•11 years ago
|
Assignee: nobody → alive
Flags: needinfo?(alive)
Comment 11•11 years ago
|
||
This should be gone due to bug 1011262, but bug 1012544 may recover that. Awaiting the bug is fixed to see next step.
Depends on: 1012544
Updated•11 years ago
|
blocking-b2g: 2.0? → 2.0+
Assignee | ||
Comment 12•11 years ago
|
||
Since bug 1003870, the layoutManager gives false information when the lockscreen is locked (always giving the full screen dimensions) to prevent bug 1009409 from happening.
We knew this was fragile, and it means that any app dutifully resizing while the screen is locked will resize to the wrong dimensions.
I think the layoutManager should not contain the lockscreen special case, and instead let the LockScreenWindow resize to a height including the status bar.
Am I missing anything?
Attachment #8429385 -
Flags: feedback?(alive)
Updated•11 years ago
|
Assignee: alive → etienne
Comment 13•11 years ago
|
||
Comment on attachment 8429385 [details] [review]
Proposal
Good catch, will revisit it in bug 992085.
Attachment #8429385 -
Flags: feedback?(alive) → feedback+
Assignee | ||
Comment 14•11 years ago
|
||
Comment on attachment 8429385 [details] [review]
Proposal
Actually already have tests and all so moving to review :)
(same patch)
Attachment #8429385 -
Flags: review?(alive)
Comment 15•11 years ago
|
||
Comment on attachment 8429385 [details] [review]
Proposal
Etienne, I recalled that I found this bug before and what's interesting is,
I think lockscreenWindow shouldn't be fullscreen.(because statusbar is there.)
But if I change the fake manifest inside lockscreen_window.js to remove the fullscreen property, https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/lockscreen_window.js#L21,
lots of statusbar's test will fail. I think it's statusbar's design problem, but I decided to hack layout manager then. https://github.com/mozilla-b2g/gaia/commit/7dd0d0cf2ecdbc5733707f8dba5356acec7d6945
And at the same time I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1009687 to track. I hope we have time to revisit it and thus we don't need the special hack in lockscreen_window.js
Attachment #8429385 -
Flags: review?(alive) → review+
Assignee | ||
Comment 16•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Target Milestone: --- → 2.0 S3 (6june)
You need to log in
before you can comment on or make changes to this bug.
Description
•