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

(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.

NI component owner to take a look.

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?

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.

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.

(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.

Comment on attachment 8630954 [details] [gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master Hey, the patch also touches rocketbar.css so hoping you can do the review :)

Comment on attachment 8630954 [details] [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!

Comment on attachment 8630954 [details] [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.

Comment on attachment 8630954 [details] [gaia] etiennesegonzac:bug-1179040 > mozilla-b2g:master Sounds good to me, thank you.

In master: https://github.com/mozilla-b2g/gaia/commit/66638d0e65bf58b7f640bcc7bed4a0b23d1356c6

This is causing a smoke test blocker. We may need this landing backed out.

Backing out since I cannot unlock my dogfood device because of this :) master: https://github.com/mozilla-b2g/gaia/commit/c6ef08964711f461a8e6326eae911789d1ec220c

Comment on attachment 8634781 [details] [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.

Comment on attachment 8634781 [details] [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.

Landed on master again https://github.com/mozilla-b2g/gaia/commit/46b68ee1b1c4dfc26e817bac40ab16ec29901f3f

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

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

(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?

(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.