980041 - [B2G] Taking the phone in and out of standby with the keyboard up will hide messages

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Harvey]

Description:
The messages in the Message app will be cut off after unlocking the phone.

Repro Steps:
1) Updated Buri 1.4 to BuildID: 20140304040200
2) Select the Message app.
3) Select a message thread with multiple messages.
4) Tap the text field to open up the keyboard.
5) Press the power button to put the phone to sleep.
6) Press the power button again and unlock the phone.

Actual:
Some of the messages in the app are cut off and cannot be seen.

Expected:
No messages are cut off.

Environmental Variables:
Device: Buri 1.4 Mozilla
BuildID: 20140304040200
Gaia: 6df4533f14ec2645bb13d8a803a5151583ca13a8
Gecko: 529b86b92b1d
Version: 30.0a1
Firmware Version: v1.2-device.cfg

Notes:

Repro frequency: 100%

Comment 1

[Harvey]

Adding video: http://youtu.be/Z5E0aoYWhuw

Comment 2

[Jason Smith [:jsmith]]

Can we confirm this doesn't reproduce on 1.3?

Comment 3

[Brogan Zumwalt [Inactive]]

Issue DOES occur in 1.3

Result: Some of the messages in the app are cut off and cannot be seen.

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140305004003
Gaia: 9b29f80309212bd80fbdcf2882458b1ae8b30093
Gecko: b3478af0151e
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 4

[Jason Smith [:jsmith]]

What about 1.1?

Comment 5

[Julien Wajsberg [:julienw]]

Ok, this could be what Al Tsai saw in bug 972254.

Looks like a reflow/painting issue to me, as the window seems to be resized properly.

Brogan, can we also test 1.3 but disabling APZC?

Comment 6

[Brogan Zumwalt [Inactive]]

Issue does NOT occur in 1.1

Issue does NOT occur on 1.3 with APZC DISABLED

1.1 Environmental Variables:
Device: Buri v1.1 Mozilla RIL
BuildID: 20140306041201
Gaia: 44a2ddf63373f8e95c784faf4ed4d60081699c61
Gecko: 1421a6b7fc51
Version: 18.0
Firmware Version: v1.2-device.cfg

1.3 Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140306004002
Gaia: 8aed4fafbaeb86d6884d31ce7d3cbeb87bcbf837
Gecko: 3d2d84d52141
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 7

[Julien Wajsberg [:julienw]]

Milan, this looks APZC related.
(not sure if you're already in PTO)

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Thanks for the regression range.  Kats, is it one of our recent changes to 1.3 that could have caused this?  Do we have the b2g-inbound builds to pinpoint an actual change that caused it?

Comment 9

[Kartikaya Gupta (email:[e-mail])]

This sounds exactly like bug 973980 which was not determined to be nonblocking for 1.3 and was not reproducible on 1.4. Since this wasn't happening on 1.4 build 20140220040203 (according to bug 973980 comment 11) I'd like to get a regression range on 1.4 builds if possible.

Comment 11

[Jason Smith [:jsmith]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #9)
> This sounds exactly like bug 973980 which was not determined to be
> nonblocking for 1.3 and was not reproducible on 1.4. Since this wasn't
> happening on 1.4 build 20140220040203 (according to bug 973980 comment 11)
> I'd like to get a regression range on 1.4 builds if possible.

Note - it was deemed as non-blocking because we only knew of it reproducing in one location. The dupe shows that it's happening all over the place, which changes the probability of reproduction here to a far higher level.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

That's fair. Note that I still can't reproduce this on 1.4 (although I didn't try too hard). Getting a regression window and/or steps that I can reproduce with would help.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #12)
> That's fair. Note that I still can't reproduce this on 1.4 (although I
> didn't try too hard). Getting a regression window and/or steps that I can
> reproduce with would help.

Have you tried reproducing this on 1.3?

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Not since this bug was filed, no. I'd rather fix it on 1.4 if possible since that's where the patch has to land first anyway, and it's time-consuming to keep switching development around on different branches.

Comment 16

[Jason Smith [:jsmith]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #14)
> Not since this bug was filed, no. I'd rather fix it on 1.4 if possible since
> that's where the patch has to land first anyway, and it's time-consuming to
> keep switching development around on different branches.

Apparently the dupe shows this is reproducing on trunk, but at a low reproduction rate. The 1.3 reproduction rate appears to be far higher though.

Comment 17

[Preeti Raghunath(:Preeti)]

Kats,

Please review and own.

Comment 18

[Brogan Zumwalt [Inactive]]

Results 1.4 Regression window and 1.3 regression window


Issue occurs on first 1.4 build available, unable to provide regression window for 1.4

1.4 Environmental Variables:
Device: Buri v1.4 Master Mozilla RIL
BuildID: 20131218040201
Gaia: e2f0e09e980b1cb3275a0bb033931cb48f9d521c
Gecko: 862cb6a1cc88
Version: 29.0a1
Firmware Version: v1.2-device.cfg



1.3  Regression Window:

Last Working Build:
Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20131209053402
Gaia: 1d45d1dc3201059d5c8f2efdeb92c04576d8e161
Gecko: 9f12a9fab080
Version: 28.0a1
Firmware Version: v1.2-device.cfg

First Broken Build:
Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20131210004003
Gaia: 3452fbdb5e1bed0cd27cc6173136537a03e8072f
Gecko: e0c328d99742
Version: 28.0a2
Firmware Version: v1.2-device.cfg


Last Working Gaia/First Broken Gecko: Issue DOES Reproduce
Gaia: 1d45d1dc3201059d5c8f2efdeb92c04576d8e161
Gecko: e0c328d99742

First Broken Gaia/Last Working Gecko: Issue Does DOES Reproduce
Gaia: 3452fbdb5e1bed0cd27cc6173136537a03e8072f
Gecko: 9f12a9fab080

Unable to determine if issue is Gecko or Gaia related.

No tinderbox or inbound builds available for these dates.

Comment 19

[Jason Smith [:jsmith]]

Are we absolutely sure this bug doesn't repro with APZC disabled? The dupe here seems to indicate that's not true.

Comment 20

[Brogan Zumwalt [Inactive]]

Tried with APZC disabled on latest 1.3 and could NOT get issue to reproduce

v1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140311004003
Gaia: 6b1180917fa4af4e4b7e31b51fc06a4bbaa2ad0f
Gecko: 8976860941f2
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 21

[Jason Smith [:jsmith]]

The window isn't right here. The above testing includes builds that don't have APZC enabled, but comment 20 says this isn't reproducing with APZC disabled.

Comment 22

[Brogan Zumwalt [Inactive]]

APZC has been a developer option in 1.3 since 10-25-13. What I did was manually enable APZC in the developer options.

Comment 23

[Jason Smith [:jsmith]]

(In reply to Brogan Zumwalt from comment #22)
> APZC has been a developer option in 1.3 since 10-25-13. What I did was
> manually enable APZC in the developer options.

That probably should have been clarified when the window was written up originally...

Comment 24

[Kartikaya Gupta (email:[e-mail])]

I was unable to reproduce using the STR in comment 0 in either 1.4 or 1.3. I was also unable to reproduce bug 973980 comment 0 in 1.4, but I WAS able to reproduce bug 973980 comment 0 on 1.3, so I debugged it there.

My investigation showed that the problem happened because the scroll offset changes when you go the lock screen, but the APZCs for the messages app are destroyed at that point, so they don't get the scroll offset update. When you unlock and go back to the messages app, the APZCs are recreated but have already missed the scroll offset update and so never recalculate the displayport. This leads to the blank space, because the displayport remains incorrect.

I also verified that the part1 patch from bug 963278 fixes this issue, as I expected once I figured out what was going on. With that patch, layout continues sending the scroll offset update until it is acknowledged, so once the APZCs come back to life they receive it and recalculate the displayport.

The fact that bug 963278 was never uplifted to 1.3 explains why I see this on 1.3 only, and don't see it on 1.4. There may be other issues here because QA seems to be able to reproduce this on 1.4, but I cannot so I cannot diagnose the problem. I can request uplift of the "part 1" patch from bug 963278 which should at least help, but it's a large patch and is potentially risky. I was able to make the patch apply without too much trouble when I did it locally.

Comment 25

[Kartikaya Gupta (email:[e-mail])]

Attachment: b2g28 backport of various things

This is a backport of selected from patches from bug 963278, bug 969455, and bug 970070.

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): various older apzc code, most relevantly bug 949132
User impact if declined: In some cases when locking the device while the keyboard is up, content is not painted fully after unlocking. This is a transient state only and fixes it self as soon as you touch the area or do anything.
Testing completed: locally only
Risk to taking this patch (and alternatives if risky): medium-high risk. the patch from bug 963278 was the main fix, but introduced two regressions (bug 969455 and bug 970070) whose fixes I have also rolled up into this patch. if we take this uplift it'll also make it easier to eventually uplift my suggested fix for bug 980679, which is related to these patches. this code has been on central for a while and seems relatively stable now but it's not a trivial patch to be uplifting this late, and may cause regressions. I think just WONTFIXing bug 980041 in 1.3 is a reasonable alternative as it is only a transient issue with unreliable STR.
String or UUID changes made by this patch: none

Comment 26

[Kartikaya Gupta (email:[e-mail])]

I also just discovered that in the email app at least the textarea is pretty short and cuts off the visible text. I filed bug 983181 for this issue but am mentioning it here because this causes the symptoms described in this bug using the same STR but is really just expected behaviour.

Comment 27

[Kartikaya Gupta (email:[e-mail])]

Since this uplift will fix the issue I see on 1.3, I'm going to repurpose this bug to just be about that. If there are additional issues that are still reproducible on 1.4 or 1.3 after the uplift, I'll ask that you file a separate bug for those issues. If I can reproduce them I'll be happy to diagnose them too, but please don't reopen this bug or things will get even more confusing than they already are.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/46bb232303b8

Comment 29

[Julien Wajsberg [:julienw]]

I _think_ I had this patch in my build during my holidays and I could still see the problem.

I'll update with a more current version.

Comment 30

[Julien Wajsberg [:julienw]]

I just tried with the latest 1.3 build for Peak, and it does not seem to be fixed, at least on Peak :(

The exact issue described in comment 0 is happening on my Peak.

Comment 31

[Kartikaya Gupta (email:[e-mail])]

Julien, can you file a separate bug for the issue you're seeing? (Feel free to just clone this one, but make sure to set all the status flags appropriately). Also if you have a Hamachi/Buri can you check to see if it happens there? My Peak is in a non-working state at the moment so I can't test on that.

Comment 32

[Julien Wajsberg [:julienw]]

Kats, I just filed bug 987771. I don't have a Buri here right now, I'll be able to check only tomorrow, but I asked QAWanted on the new bug.

Comment 33

[Roland Kunkel [:RolandK]]

This issue still reproduces on the latest v1.3 Buri build. Re-opening and updating tracking-flags.

3/25 Environmental Variables:
Device: Buri 1.3 MOZ RIL
BuildID: 20140325004002
Gaia: b789780c53adaac199787f51615375f721edfef4
Gecko: 37917eb0dfeb
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 34

[Jason Smith [:jsmith]]

Please read the above comments - bug 987771 is already filed for this purpose.