Closed Bug 918671 Opened 6 years ago Closed 6 years ago

[Buri][SMS]The recipient doesn't display after going away from the main screen

Categories

(Core :: Graphics, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla28
blocking-b2g koi+
Tracking Status
firefox26 --- wontfix
firefox27 --- wontfix
firefox28 --- fixed
b2g-v1.2 --- fixed
b2g-master --- verified

People

(Reporter: sync-1, Assigned: BenWa)

References

Details

(Whiteboard: burirun2)

Attachments

(7 files, 3 obsolete files)

Mozilla build ID:20130916041201
 Created an attachment (id=521633)
 The recipient can't display
 
 DEFECT DESCRIPTION:
  [MMS]The recipient can't display after view a picture.
 
  REPRODUCING PROCEDURES:
  1.Create new message->Select a recipient from contacts.
  2.Add a picture from Gallery->View the pictre in MMS->Press "Cancel".
  3.Check the recipient->The recipient can't display--K.O
 
  EXPECTED BEHAVIOUR:
  The recipient should display.
 
  ASSOCIATE SPECIFICATION:
  
  TEST PLAN REFERENCE:
  
  TOOLS AND PLATFORMS USED:
  
  USER IMPACT:
  Medium
  REPRODUCING RATE:
  5/5
  For FT PR, Please list reference mobile's behavior:
Clone from brother
Clone from brother
Attached file PR526392_Log
looks like a graphic bug.

Moving to Graphics.
Component: Gaia::SMS → Graphics
Product: Boot2Gecko → Core
FTR I don't see this on Unagi/1.1, but I know I've seen similar things in the past.
Just reproduced on an Unagi/master.
Duplicate of this bug: 919036
dupe bug 919036 has some additional information.
Here are quick and simple 100% reproducible steps:

* launch the sms app
* tap the "new message" button
* add a recipient box (could be anything: just type random characters then enter)
* tap the bottom left "pick attachment" button
* press cancel

=> we can see the issue that is in the attachment
blocking-b2g: --- → koi?
QA Contact: dwatson
The window for the issue appears to be between build 09/15 and 09/16. The names are displayed on 09/15, but on 09/16 they disappear.

Does not occur:
Buri Build ID: 20130915040205
Gecko: http://hg.mozilla.org/mozilla-central/rev/9366ee039645
Gaia: 3f51f302c3a0c57d8bad482ec7ee86b2819389fb
Platform Version: 26.0a1

Issue occurs:
Buri Build ID: 20130916040205
Gecko: http://hg.mozilla.org/mozilla-central/rev/c4bcef90cef9
Gaia: a0079597d510ce8ea0b9cbb02c506030510b9eeb
Platform Version: 26.0a1
The regression range is probably a red herring.  We switched back from tiling to buffer rotation in this range, with bug 916112, which means that how we draw changed.  Does forcing the preference  layers.force-tiles" to true "fix" this?
Assignee: nobody → jmuizelaar
blocking-b2g: koi? → koi+
(In reply to Julien Wajsberg [:julienw] from comment #7)
> Just reproduced on an Unagi/master.

How about Unagi 1.2?  I don't see it on that combo.
(In reply to Milan Sreckovic [:milan] from comment #13)
> 
> How about Unagi 1.2?  I don't see it on that combo.

Wait - yes, I do.  After letting the phone sleep and reopening.
Simpler STR:

1. Open the SMS app.
2. Type in random numbers into the To field.  Enter
3. Power button to turn the screen off.
4. Turn the screen back on, unlock.

Can't see the Recipient.  Click on where the recipient field would be, and it'll refresh and you can see it again.
Another STR:

1. Open the SMS app.
2. Type in the random numbers into the To field.  Enter.
3. Home button.
4. SMS app.  Don't wait too long in between the presses.

Half of the time, the "To" is not visible - half of the time, I just get a blank page.  Once in a while, it looks correct.
Changing the summary as you don't need any MMS involvement at all.
Summary: [Buri][MMS]The recipient can't display after view a picture. → [Buri][SMS]The recipient doesn't display after going away from the main screen
(In reply to Milan Sreckovic [:milan] from comment #16)
> Another STR:
> 
> 1. Open the SMS app.
> 2. Type in the random numbers into the To field.  Enter.
> 3. Home button.
> 4. SMS app.  Don't wait too long in between the presses.
> 
> Half of the time, the "To" is not visible - half of the time, I just get a
> blank page.  Once in a while, it looks correct.

I already filed bug 912961 for the blank page issue. I don't know if that's the same issue, I'd say it's not.
tried to make a reduced testcase in https://everlong.org/mozilla/testcase-recipient/ but as of now I couldn't reproduce...
(In reply to Julien Wajsberg [:julienw] from comment #18)
> (In reply to Milan Sreckovic [:milan] from comment #16)
> > Another STR:
> > 
> > 1. Open the SMS app.
> > 2. Type in the random numbers into the To field.  Enter.
> > 3. Home button.
> > 4. SMS app.  Don't wait too long in between the presses.
> > 
> > Half of the time, the "To" is not visible - half of the time, I just get a
> > blank page.  Once in a while, it looks correct.
> 
> I already filed bug 912961 for the blank page issue. I don't know if that's
> the same issue, I'd say it's not.

Perhaps not - however, repeating the 3+4 I get either blank page or the missing label, or everything normal, so perhaps they are related.  We'll find out once we have a fix.
There is some traction on the "blank page", which may or may not be related, in bug 920890
this issue blocks smoketest.

When editing Contacts screen flickers then turns off and user must exit app with homescreen or long tap power button to recover.

Gaia   1e9470b9b6df630eddf1c4c8b25b3170ee786b0e
SourceStamp 7eebf2d65429
BuildID 20130927004015
Version 26.0a2
Keywords: smoketest
(In reply to Allen Maxwell from comment #23)
> this issue blocks smoketest.
> 
> When editing Contacts screen flickers then turns off and user must exit app
> with homescreen or long tap power button to recover.

Did you mean to comment on this bug?  Because this does not sounds like the same bug at all.  It talks about editing contacts; this bug is about recipient field in the SMS/message application.  Please enter a new bug, so that we can look for a regression range.
Keywords: smoketest
Is it possible to get a regression window from before September 11 when tiling was turned on?
Milan: comment 23 was probably for bug 920890, I added "smoketest" there.
Jeff, I'm in Toronto right now, if you need a keon or a buri.
I've seen this on unagi as well.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #25)
> Is it possible to get a regression window from before September 11 when
> tiling was turned on?

Regression window:
Build ID: 20130823040202 - Does NOT Reproduce
Gecko: http://hg.mozilla.org/mozilla-central/rev/fb2318875cd4
Gaia: 72d9989f759099632c3d3b8b5335b7d12d969d2f
Platform Version: 26.0a1

Build ID: 20130823151250 - Reproduces
Gecko: http://hg.mozilla.org/mozilla-central/rev/17143a9a0d83
Gaia: d6b43217d4be63a9b0978886381b541fac7bfb02
Platform Version: 26.0a1

*test device - Buri
Nice - down to 7 hours, thanks!
BenWa - Jeff is away for a couple of weeks, can you take a look at this?
Assignee: jmuizelaar → bgirard
Whiteboard: burirun2
No longer blocks: b2g-central-dogfood
Duplicate of this bug: 924163
Evelyn committed on doing a reduced testcase for this.
Flags: needinfo?(evelyn)
I was able to create a reduced test case with minimal markup and CSS, no JS required.

*** To access the reduced test case ***

You can test it as both an installable app and maybe a URL:

Installable app branch: https://github.com/evhan55/gaia/commit/399c6235fe8ed1440365502e273f5faedbd38979
URL: https://dl.dropboxusercontent.com/u/82856/918671-test/index.html

I wasn't able to load the URL in the browser on my Inari device with recent m-c build because it gave me an error that I will post a screenshot of.  Try the URL first, otherwise, install the app located in my branch '918671-test'.

*** Steps To Reproduce on Inari ***

1) Launch app '918671-test' or visit https://dl.dropboxusercontent.com/u/82856/918671-test/index.html
2) Turn screen off with power button
3) Turn screen on with power button

Expected: 'Rick' label doesn't disappear
Actual: 'Rick' label disappears

*** About the reduced test case ***

I tried removing the markup and CSS as much as I could, including those images, but removing any one thing makes the behavior not reproduce.

Hope this helps.
Flags: needinfo?(evelyn)
Testing on other devices:

The reduced test case URL (https://dl.dropboxusercontent.com/u/82856/918671-test/index.html) works on Unagi device.

STR:

1) Visit https://dl.dropboxusercontent.com/u/82856/918671-test/index.html on Unagi
2) Turn of screen with power button
3) Turn on screen with power button

Expected: 'Rick' label doesn't disappear
Actual: 'Rick' label disappears
Attached file testcase (obsolete) —
Comment on attachment 819486 [details]
testcase

like Evelyn said, the testcase alone doesn't trigger the bug, but the testcase with the images works.

I'll try to use data urls instead of external image and see if this still reproduces.
Attachment #819486 - Attachment is obsolete: true
Attached file testcase (obsolete) —
testcase using only data URLs, so no need for external images.

Bonus: it seems to trigger the bug as soon as the page is loaded (whereas with external images we need to lock/unlock).

I'd say the external bg images force a repaint once they're loaded, whereas it does not happen with data URLs.
Also, no need to install an app, the bug is simply triggered with this testcase in the Browser app.

Thanks a lot Evelyn!
(In reply to Julien Wajsberg [:julienw] from comment #39)

> Bonus: it seems to trigger the bug as soon as the page is loaded (whereas
> with external images we need to lock/unlock).

For what it's worth, I also noticed that it was possible to trigger the bug, directly from master, with one very simple change, seemingly completely unrelated to the test case I made above:

From master:

- Remove the 'view-body' class from line 164 of apps/sms/index.html

To test:

- Launch SMS app
- Start a new message
- Type a new recipient, press 'enter'

Expected: recipient label doesn't disappear
Actual: recipient label disappears
(In reply to Evelyn Eastmond [:evhan55] from comment #41)

> From master:
> 
> - Remove the 'view-body' class from line 164 of apps/sms/index.html

Specifically, I think it was removal of this line in apps/sms/style/common.css

height: -moz-calc(100% - 5rem);
Yep, it looks like a late repaint hides the issue, and therefore maybe this one line just triggers a late repaint.
Duplicate of this bug: 924581
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fb2318875cd4&tochange=17143a9a0d83

Looking at the regression window with Matt, we're going to try to backout bug 908006 locally.
Doesn't look like it's that patch. The problem could be with ImageLayer. Ideally we would have someone perform a complete regression window.
Hey Milan,

Benoit told me he was in holiday during this week, maybe someone from your team could resume this task ? This bug is koi+, and is probably also triggering bug 918860 which is koi+, which means some pressure from managers ;-)

The next step is performing a complete regression window from the testcase we have. If everybody is busy on your side, I could try to do it, but my computer is not so fast.
Flags: needinfo?(milan)
A tighter regression window would be great - if you can start it, I'd appreciate it.  I want to make sure the others finish their koi+ before jumping on something else.
Flags: needinfo?(milan)
(In reply to Milan Sreckovic [:milan] from comment #48)
> A tighter regression window would be great - if you can start it, I'd
> appreciate it.  I want to make sure the others finish their koi+ before
> jumping on something else.

QA can't do a tighter regression window than what's already specified in comment 29. We don't have builds available to reduce it further.

Anyways, there's a 12 hour regression range + reduced test case, which should be enough to move forward here.
yep Jason, Milan was answering my proposal in comment 47: _I_ will do a tighter regression window.
Could this be caused by the introduction of enabling Azure content? The push log seems to show a lot of landings involving enabling of Azure content around the regression range timeframe.
Good idea jason. I'll check that.
Attached file Browser Draw Recording
Attached file reduced testcase
This is as far as I could reasonably reduce it.
Attachment #819492 - Attachment is obsolete: true
Blocks: GFXB2G1.2
Attached patch patch (obsolete) — Splinter Review
Writing a testcase
Attached patch gtest unittestSplinter Review
Attachment #831065 - Flags: review?(jmuizelaar)
Attachment #830962 - Flags: review?(jmuizelaar)
Removing 'regression' since this has been broken in cairo for a while. I wonder what the regression window is pointing to.
Keywords: regression
Comment on attachment 830962 [details] [diff] [review]
patch

Review of attachment 830962 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/cairo/README
@@ +208,5 @@
>  
>  dasharray-zero-gap.patch: bug 885585, ensure strokes get painted when the gaps in a dash array are all zero length
>  
> +cairo-mask-extends-bug.patch: bug 918671, sometimes when building a mask we wouldn't clear it properly
> +

Add a note that this is fixed in 1.12

::: gfx/cairo/cairo-mask-extends-bug.patch
@@ +7,5 @@
> +     int i;
> + 
> +-    if (boxes->num_boxes < 1 && clip_region == NULL)
> +-	return _cairo_image_surface_fixup_unbounded (dst, extents, NULL);
> ++    if (boxes->num_boxes < 1 && clip_region == NULL) {

Add a comment about how we clear the entire unbounded area because nothing has been drawn.
Attachment #830962 - Flags: review?(jmuizelaar) → review+
Attachment #831065 - Flags: review?(jmuizelaar) → review+
Attached patch patch v1.1Splinter Review
https://tbpl.mozilla.org/?tree=Try&rev=257225fcf39b
Attachment #830962 - Attachment is obsolete: true
Attachment #831090 - Flags: review+
Forgot to push with the gtest:
https://tbpl.mozilla.org/?tree=Try&rev=5506e65b9b60

I'll wait for the gtest to go green before landing on inbound. Likely tomorrow morning.
Just for clarity, because you may not be familiar with B2G flags, this bug is koi+ which means the patch will need to be uplifted to the mozilla-b2g26_v1_2 branch.

Thanks for your work!
Alright I'll just let this sit on nightly for a day or two since this is a bit of a scary change.
https://hg.mozilla.org/mozilla-central/rev/e4f35a5947f6
https://hg.mozilla.org/mozilla-central/rev/4cde2e143107
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Depends on: 939355
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/b6a6fc3c537e

I decided not to uplift the unit test because we don't run gtest on b2g and it would need additional work to make sure all the gtest/moz2d dependencies are in place to run it.
Thanks for your work!
(In reply to Julien Wajsberg [:julienw] from comment #66)
> Thanks for your work!

np, can you verify that it's also fixed in the non reduced test case?
see comment 10 for a STR.
Keywords: verifyme
This issue is verified fixed on Flame 2.5 and Aries. Following STR at comment 0 or comment 10, the recipient shows correctly.

Device: Flame 2.5
BuildID: 20151016030225
Gaia: 8ea9029190af2ffeb04dcd97b323738125e31a0e
Gecko: d374d16cbb251c9dac5af69f8e186e821ce82fe2
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Aries 2.5
BuildID: 20151016122951
Gaia: 8999f0ba6326d815c8366e3c1155b7e4e9763b40
Gecko: ccf288f658211b6cfab33c458aaf033baed2375b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.