[Aries] [Window Mgmt] Flicker occurs when transitioning from the No contacts in your contacts list screen to dialer

VERIFIED FIXED

Status

Firefox OS
Gaia::System::Window Mgmt
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: KTucker, Assigned: etienne)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(b2g-master verified)

Details

(Whiteboard: [2.5-Daily-Testing] [Spark] [backout-asap], URL)

Attachments

(4 attachments)

If the user puts in a number on Dialer, taps "Add to existing contacts" when no contacts are present, a flicker will occur when going back to the Dialer. 

Prerequisite:
No contacts are saved on the dut.

Repro Steps:
1) Update a Aries to 20150630220033
2) Tap on the "Dialer" icon.
3) Type in a number and then tap on the "Add to Contacts" icon.
4) Tap "Add to existing contact".
5) Quickly tap "OK" when prompted that "No contacts in your Contacts list. 

Actual:
A flicker occurs on the dialer screen when trying to add a number to an existing contact when no contacts are present on the device.

Expected:
No flickering occurs when transitioning back to Dialer.

Environmental Variables:
Device: Aries 2.5
Build ID: 20150630220033
Gaia: 5997b406e77ea726fbd9047057a1c3504f6cd6d4
Gecko: 79800010be78
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Repro frequency: 5/5 100%
See attached: video, logcat
This issue does not occur on the Flame 2.5

No flickering is observed when transitioning from the "No contacts in your contacts list" screen to dialer.

Device: Flame 2.5 (Full Flash)(KK)(319mb)
Build ID: 20150630120106
Gaia: 5997b406e77ea726fbd9047057a1c3504f6cd6d4
Gecko: 291614a686f1
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
status-b2g-master: --- → affected
Whiteboard: [2.5-Daily-Testing] [Spark]
(Reporter)

Updated

3 years ago
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
(Reporter)

Updated

3 years ago
Blocks: 1179056
(Reporter)

Updated

3 years ago
No longer blocks: 1179056
Created attachment 8628032 [details]
BlackFlickeringlinelogcat.txt
(Assignee)

Comment 3

3 years ago
(In reply to KTucker [:KTucker] from comment #1)
> This issue does not occur on the Flame 2.5
> 
> No flickering is observed when transitioning from the "No contacts in your
> contacts list" screen to dialer.

If the issue is device specific then it's probably a gfx issue and not a Gaia issue.
(Reporter)

Updated

3 years ago
Summary: [Spark] [Window Mgmt] Flicker occurs when transitioning from the No contacts in your contacts list screen to dialer → [Aries] [Window Mgmt] Flicker occurs when transitioning from the No contacts in your contacts list screen to dialer
NI component owner to take a look.
Blocks: 1171119
Flags: needinfo?(pbylenga) → needinfo?(npark)
Actually, I don't have to tap 'quickly.' just tapping 'OK' in the end is sufficient for the dialer screen to flicker once. kats, this does not reproduce in flame device.  Do you think it's a graphics issue?
Flags: needinfo?(npark) → needinfo?(bugmail.mozilla)
The linked video and attached logcat appears to be for some other issue. I can repro this on Aries but it's not obviously a graphics issue. To me the flicker just looks it's going back to the "select contact" search, then dismissing that to go back to contacts app's "search" screen, and then quickly dismissing that to go back to the dialer. From the gaia side it might be easier to make some of those screens display:none just to see if that resolves the problem. If it doesn't then I can find somebody to look at it from the graphics side.
Flags: needinfo?(bugmail.mozilla)
Not sure whether this helps, but in debug build, during the transition to the phone app from the contacts app, following assertion fault is shown:

I/Gecko   ( 1744): [Child 1744] ###!!! ASSERTION: destroying style context from old rule tree too late: 'styleSet->GetRuleTree() == mRuleNode->RuleTree() || styleSet->IsInRuleTreeReconstruct()', file /builds/slave/b2g_m-cen_flm-kk_eng-d_dep-000/build/gecko/layout/style/nsStyleContext.cpp, line 134

and perhaps because the debug build is much slower, the flickering is not shown.
(Assignee)

Comment 8

3 years ago
(In reply to Etienne Segonzac (:etienne) from comment #3)
> (In reply to KTucker [:KTucker] from comment #1)
> > This issue does not occur on the Flame 2.5
> > 
> > No flickering is observed when transitioning from the "No contacts in your
> > contacts list" screen to dialer.
> 
> If the issue is device specific then it's probably a gfx issue and not a
> Gaia issue.

I'm revising my judgment to: this might very well be a setVisible race on the gaia side.
(Assignee)

Updated

3 years ago
See Also: → bug 1154231
(Assignee)

Updated

3 years ago
QA Contact: etienne
(Assignee)

Updated

3 years ago
Assignee: nobody → etienne
QA Contact: etienne
Created attachment 8630954 [details] [review]
[gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master
(Assignee)

Comment 10

3 years ago
Comment on attachment 8630954 [details] [review]
[gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master

Hey, the patch also touches rocketbar.css so hoping you can do the review :)
Attachment #8630954 - Flags: review?(kgrandon)
(Assignee)

Updated

3 years ago
Blocks: 1180690
Comment on attachment 8630954 [details] [review]
[gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master

It looks like there might be some related test failures here. Can you address and re-flag me? Thanks!
Flags: needinfo?(etienne)
Attachment #8630954 - Flags: review?(kgrandon)
(Assignee)

Comment 12

3 years ago
Comment on attachment 8630954 [details] [review]
[gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master

All green now :) Let me know what you think!
And if you have any suggestion for the aria checks in marionette tests I'm all ears.
Flags: needinfo?(etienne)
Attachment #8630954 - Flags: review?(kgrandon)
Comment on attachment 8630954 [details] [review]
[gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master

Sounds good to me, thank you.
Attachment #8630954 - Flags: review?(kgrandon) → review+
In master: https://github.com/mozilla-b2g/gaia/commit/66638d0e65bf58b7f640bcc7bed4a0b23d1356c6
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
This is causing a smoke test blocker. We may need this landing backed out.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Whiteboard: [2.5-Daily-Testing] [Spark] → [2.5-Daily-Testing] [Spark] [backout-asap]
Backing out since I cannot unlock my dogfood device because of this :)

master: https://github.com/mozilla-b2g/gaia/commit/c6ef08964711f461a8e6326eae911789d1ec220c
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 8634781 [details] [review]
[gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master
(Assignee)

Comment 18

3 years ago
Comment on attachment 8634781 [details] [review]
[gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master

Hey Greg, the diff between the 2 versions of the patch is lockscreen only (lock_screen_window_manager.js
and lockscreen_window_manager_test.js) so flagging you for review.

Basically the AppWindowManager setVisible(true) the basic AppWindows, the InputWindowManager setVisible(true) the InputWindows but nobody setVisible(true) the LockScreenInputWindow (which is still being setVisible(false) by it's appTransitionController like every other window).

So I made it part of the LockScreenWindowManager, let me know what you think.
Attachment #8634781 - Flags: review?(gweng)
Comment on attachment 8634781 [details] [review]
[gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master

Okay. From the code I don't see any improper changes. Let's land it and solve the issue, thanks.
Attachment #8634781 - Flags: review?(gweng) → review+
(Assignee)

Comment 20

3 years ago
Landed on master again
https://github.com/mozilla-b2g/gaia/commit/46b68ee1b1c4dfc26e817bac40ab16ec29901f3f
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
Depends on: 1185160
Created attachment 8644812 [details]
Verified_Aries v2.5.3gp

This bug has been verified as pass on latest build of Aries v2.5 by the STR in Comment 0. 

Results:
No flickering is observed when transitioning from the "No contacts in your contacts list" screen to dialer.

See attachment: Verified_Aries v2.5.3gp
Reproduce rate: 0/10

Device: Aries v2.5(Pass)
Build ID               20150806203229
Gaia Revision          7f387f859d48f9ad0761637c78447dc524747738
Gaia Date              2015-08-06 15:21:13
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/03e3d77d1b6b
Gecko Version          42.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150806.195600
Firmware Date          Thu Aug  6 19:56:08 UTC 2015
Bootloader             s1
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
status-b2g-master: affected → verified
(Assignee)

Updated

3 years ago
Blocks: 1190775
Depends on: 1188165
Etienne,

IMHO, we shouldn't remove the `visibility: hidden` part of iframe[1]. The more DOM elements are visible, the more memory consumption. At previous version, we had set the DIV.appWindow to invisible. But for some reason, we change DIV.appWindow to visible and still keep iframe as invisible. We should also keep that.


[1] https://github.com/mozilla-b2g/gaia/pull/31008/files#diff-46b349b14289333755febebd351e16ccL425
Flags: needinfo?(etienne)
(Assignee)

Comment 23

3 years ago
(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #22)
> Etienne,
> 
> IMHO, we shouldn't remove the `visibility: hidden` part of iframe[1]. The
> more DOM elements are visible, the more memory consumption. At previous
> version, we had set the DIV.appWindow to invisible. But for some reason, we
> change DIV.appWindow to visible and still keep iframe as invisible. We
> should also keep that.
> 

Do you mean setting `visibility:hidden` on the iframe once the opening/closing transition is over?
Flags: needinfo?(etienne)
(In reply to Etienne Segonzac (:etienne) (PTO -> 08/24) from comment #23)
> (In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #22)
> > Etienne,
> > 
> > IMHO, we shouldn't remove the `visibility: hidden` part of iframe[1]. The
> > more DOM elements are visible, the more memory consumption. At previous
> > version, we had set the DIV.appWindow to invisible. But for some reason, we
> > change DIV.appWindow to visible and still keep iframe as invisible. We
> > should also keep that.
> > 
> 
> Do you mean setting `visibility:hidden` on the iframe once the
> opening/closing transition is over?

Yes, I mean that but only `visibility: hidden` at the end of closing transition. At previous version, we make it hidden by default. Once we add .active to .appWindow, the iframe becomes visible.
(Reporter)

Updated

3 years ago
Depends on: 1198024
Duplicate of this bug: 1199599
(Assignee)

Updated

3 years ago
Blocks: 1201099
Depends on: 1201291
You need to log in before you can comment on or make changes to this bug.