Closed Bug 980041 Opened 7 years ago Closed 7 years ago
[B2G] Taking the phone in and out of standby with the keyboard up will hide messages
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%
Can we confirm this doesn't reproduce on 1.3?
Component: General → Gaia::SMS
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
What about 1.1?
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?
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
Milan, this looks APZC related. (not sure if you're already in PTO)
blocking-b2g: --- → 1.3?
Component: Gaia::SMS → Panning and Zooming
Product: Firefox OS → Core
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?
Flags: needinfo?(milan) → needinfo?(bugmail.mozilla)
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.
7 years ago
See Also: → 973980
(In reply to Kartikaya Gupta (email:email@example.com) 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.
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.
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) 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?
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.
(In reply to Kartikaya Gupta (email:email@example.com) 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.
Kats, Please review and own.
blocking-b2g: 1.3? → 1.3+
7 years ago
Assignee: nobody → bugmail.mozilla
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.
Are we absolutely sure this bug doesn't repro with APZC disabled? The dupe here seems to indicate that's not true.
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
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.
APZC has been a developer option in 1.3 since 10-25-13. What I did was manually enable APZC in the developer options.
(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...
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.
Depends on: 963278
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
Attachment #8390521 - Flags: approval-mozilla-b2g28?
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.
Attachment #8390521 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
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.
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.
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.
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.
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.
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
Please read the above comments - bug 987771 is already filed for this purpose.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.