Closed Bug 1023794 Opened 10 years ago Closed 10 years ago

Dialer][Call Screen] UI moved up when entering another apps and back to call screen

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed)

VERIFIED FIXED
2.0 S5 (4july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: ericcc, Assigned: vingtetun)

References

Details

(Keywords: regression, Whiteboard: ft:loop)

Attachments

(1 file)

### STR
1. Make call to another phone.
2. Tap home button to enter home screen.
3. Tap the call bar with timer on top of the screen.
4. UI moved up..
5. Happened either the number is stored in Contacts or not.
https://www.youtube.com/watch?v=psPIWf2Df5g

### Reproduce rate
100%


### Flame aurora v2.0 (same on master v2.1)
Gaia      8d865839d932bfbd5e157f376f74d8cb12bfdd51
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/1d4046a8cb6c
BuildID   20140610000223
Version   32.0a2
ro.build.version.incremental=104
ro.build.date=Fri Jun  6 17:35:09 CST 2014
t2m.sw.version=B1TC400110H0

### Buri master v2.1 also has that issue
Gaia      e0c637f14265291ed81934058ec1cc019612127c
Gecko     https://hg.mozilla.org/mozilla-central/rev/13be61241671
BuildID   20140610160204
Version   33.0a1
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013
This is window management issue I believe. We may even have a duplicate already but I can't find it.
Component: Gaia::Dialer → Gaia::System::Window Mgmt
blocking-b2g: --- → 2.0?
NI Stehany to comment here from UX perspective, if this would block.
Flags: needinfo?(swilkes)
This is not a blocker. Obviously, when the user returns to the call screen, it should look the same as it did before. Instead, it's a little off, but not in an egregious way, so UX will cave on this one. ;)
Flags: needinfo?(swilkes)
We already have two duplicates and one of them was consider a blocker. So I think this should block.
blocking-b2g: 2.0? → 2.0+
QA Contact: jharvey
B2G Inbound Regression Window

Last Working
Environmental Variables:
Device: Flame 2.0
Build ID: 20140606061657
Gaia: 3b43bc39a5d3b3a078774c72d8f772617a481835
Gecko: 43f8349a1140
Version: 32.0a1 (2.0) 
Firmware Version: v121-2

First Broken
Environmental Variables:
Device: Flame 2.0
Build ID: 20140606065657
Gaia: 487af01e7a373b77da231dcf5e96c59efa5f1904
Gecko: 583fafa30638
Version: 32.0a1 (2.0) 
Firmware Version: v121-2

Last Working Gaia First Broken Gecko: Issue does NOT reproduce
Gaia: 3b43bc39a5d3b3a078774c72d8f772617a481835
Gecko: 583fafa30638

First Broken Gaia Last Working Gecko: Issue DOES reproduce
Gaia: 487af01e7a373b77da231dcf5e96c59efa5f1904
Gecko: 43f8349a1140

Gaia Pushlog: 
https://github.com/mozilla-b2g/gaia/compare/3b43bc39a5d3b3a078774c72d8f772617a481835...487af01e7a373b77da231dcf5e96c59efa5f1904
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Broken by bug 988212.

Vivien - Do you cycles to take this?
Blocks: 988212
Flags: needinfo?(21)
Whiteboard: ft:loop
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(In reply to Jason Smith [:jsmith] from comment #8)
> Broken by bug 988212.
> 
> Vivien - Do you cycles to take this?

What is the issue exactly ? The fact that the underlying app moves up ?

If yes, this is an issue of the minimize call screen since it has been created (it resize the underlying app). Not sure why it is more visible with my change thought.
Flags: needinfo?(21)
(In reply to Stephany Wilkes from comment #3)
> This is not a blocker. Obviously, when the user returns to the call screen,
> it should look the same as it did before. Instead, it's a little off, but
> not in an egregious way, so UX will cave on this one. ;)

Bhavana, could you share with us the reason this bug is a blocker after Stephany's comment? Thank you.
Flags: needinfo?(bbajaj)
(In reply to Kevin Hu [:khu] from comment #10)
> (In reply to Stephany Wilkes from comment #3)
> > This is not a blocker. Obviously, when the user returns to the call screen,
> > it should look the same as it did before. Instead, it's a little off, but
> > not in an egregious way, so UX will cave on this one. ;)
> 
> Bhavana, could you share with us the reason this bug is a blocker after
> Stephany's comment? Thank you.

TEF didn't agree with Stephany's assessment to my understanding due to what was seen in the dupe - https://bugzilla.mozilla.org/show_bug.cgi?id=1024456.
Flags: needinfo?(bbajaj)
As far as I know, this is not a regression from the recent changes in the attention screen. So removing the regression flag here, until someone can really confirms it was not happening before...
No longer blocks: 988212
Keywords: regression
(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #12)
> As far as I know, this is not a regression from the recent changes in the
> attention screen. So removing the regression flag here, until someone can
> really confirms it was not happening before...

The window in comment 7 already disproved this with firm evidence.
Blocks: 988212
Keywords: regression
Vivien, do you have cycles to address this regression?
Flags: needinfo?(21)
I'll take a look at this one today, will assign myself if I can reproduce.
Flags: needinfo?(21)
Attached patch bug1023794.patchSplinter Review
Sigh.
Assignee: nobody → 21
Status: NEW → ASSIGNED
Attachment #8448657 - Flags: review?(etienne)
Attachment #8448657 - Flags: review?(etienne) → review+
(In reply to Jason Smith [:jsmith] from comment #13)
> (In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails,
> needinfo? please) from comment #12)
> > As far as I know, this is not a regression from the recent changes in the
> > attention screen. So removing the regression flag here, until someone can
> > really confirms it was not happening before...
> 
> The window in comment 7 already disproved this with firm evidence.

I should have looked at video before. The description of the bug has made me thought of an other resizing issue which is here since the beginning. Sorry about the confusion.
Verified okay with these 2 builds.
Flame - aurora - v2.0 
Gaia      e935f4ff190b76c70d9b2af8856c542a6e4a7546
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/3f9d7a3a0b7b
BuildID   20140707160206
Version   32.0a2
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
B1TC00011220

Flame - master - v2.1 
Gaia      1dc9e53393ae4680a174dffa44a958ec564ebbe8
Gecko     https://hg.mozilla.org/mozilla-central/rev/dfef245594b6
BuildID   20140707160202
Version   33.0a1
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
B1TC00011220
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: