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

looks like a graphic bug. Moving to Graphics.

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.

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

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?

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

(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

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

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?

Evelyn committed on doing a reduced testcase for this.

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.

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

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.

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.

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.

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.

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

This is as far as I could reasonably reduce it.

Writing a testcase

Removing 'regression' since this has been broken in cairo for a while. I wonder what the regression window is pointing to.

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.

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.

remote: https://hg.mozilla.org/integration/b2g-inbound/rev/e4f35a5947f6 remote: https://hg.mozilla.org/integration/b2g-inbound/rev/4cde2e143107

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

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.

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