1108672 - Unable to view SMS messages with tiling disabled

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[u3woallizom]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20141208030202

Steps to reproduce:

In the Messages application, select an SMS message thread.

Boot2Gecko 2.2.0.0-prerelease nightly updates.
This issue has existed for at least the past two nightly updates, possibly longer than that.


Actual results:

Below the application header and "Mobile, <sender's mobile number>" the screen is completely black, and the messages cannot be viewed.  At times rather than being black, the screen area will instead be grey with intermittent color dots (almost like "snow" on an old TV set).

If you pull down the notification panel on this screen, you can partially view the messages.

If you select the menu icon in the top right of the screen and select "Select Messages", you can view the messages (with check boxes in the "Delete messages" screen)


Expected results:

Should display the selected message thread.

Comment 1

[Julien Wajsberg [:julienw]]

Mike, can you please share the device you use, and how you flash it?

Thanks!

Comment 2

[u3woallizom]

My device is the reference Flame.

I originally flashed as described at https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame and since have been receiving nightly OTA updates.

Comment 3

[Julien Wajsberg [:julienw]]

qawanted for branch checks

Comment 4

[Cody Roesch [:croesch]]

I'm looking at the nightly and engineering builds on my Flame device and I see a lot of brief black flickering on the screen when going in and backing out of messages and threads. However I cannot get the sms/mms to just appear constant black so the user cannot see the messages.

I've tested on 319mb and 512mb, with and without SHB enabled, Long text messages with music or images attached as well as multiple sending device types.

Some questions to get more info:

1. Does this happen every time you completely shut down the messages app then reopen? how about Device restart?

2. Have you seen this bug without getting builds through OTA?

3. Does this bug repro for you on the latest build?

Finally, Are there any special circumstances that you can think of that may be a factor? (High memory usage at the time?)

Also if you can provide a screenshot that would give us a better idea what it looks like.

Thank you,
QA

Comment 5

[u3woallizom]

Hi Cody, what I am experiencing is a lot more severe that what you are seeing.  I am getting flickering in the Settings menu when I scroll to the top or bottom of the screen.  But in the Messages app I am getting (usually) a black screen (after a very brief, <1 second interval) or (less often, perhaps <10% of the time) the grey "snowy" screen also described in my bug report.  The only way I've found to view any message thread is to go into the "Select Messages" menu, when, after brief flickering, the message thread can be viewed normally (aside from the check boxes and Delete menu).

I have not altered the memory settings at all.  Sorry, I am not sure what SHB is, or how to check whether this is enabled (hint?).

WRT your questions:
     1.  Yes, this happens every time I completely shut down the messages app and then reopen.  It also happens after every device restart.  I have found no workaround that allows me to view a message thread aside from going into the Select Messages (ie, delete messages) menu. as described.
     2.  No, I have NOT seen this build without going through OTA.  I have been updating every night via OTA, but this issue only appeared about 2 days ago (could be as many as 4, sorry can't be more precise).
     3. This bug reproduces on the latest build AS OF LAST NIGHT (European time).  I have been trying to OTA update for the past hour or so but I am getting "There was an error when checking for updates."  I definitely have a good WiFi connection as I can browse, etc.

I have been wracking my brain and I cannot think of any special circumstances that could be triggering this issue.  Even after a reboot in airplane mode and the first app I open is Messages, I get the same behavior.

It is quite late here (again, I'm in Europe) so I will not get you a screen shot tonight.  I hope to post a video (which will better showcase the bug, I think) to this bug report by morning New York time tomorrow.

If you think of anything else that would be helpful in the meantime, let me know.

Comment 6

[Julien Wajsberg [:julienw]]

The black flickering is bug 1106641. It _could_ be the same underlying bug. It could also be the same than bug 1106611.

Mike, can you please check your base build using "adb shell getprop ro.bootloader"?

Comment 7

[u3woallizom]

(In reply to Julien Wajsberg [:julienw] from comment #6)
> The black flickering is bug 1106641. It _could_ be the same underlying bug.
> It could also be the same than bug 1106611.
> 
> Mike, can you please check your base build using "adb shell getprop
> ro.bootloader"?

"adb shell getprop ro.bootloder" yields L1TC00011880

Comment 8

[Julien Wajsberg [:julienw]]

Thanks, this looks good :) I wanted to be sure we were on the same page.

NI myself, I want to try to reproduce locally, with my own set of data. (I use a version from 2 weeks ago currently)

Comment 9

[u3woallizom]

Attachment: FirefoxOS black message2.mp4

Here is a video demonstrating the bug.

Comment 10

[Julien Wajsberg [:julienw]]

I don't reproduce on my data or a simpler set of data :(

Still this looks like a Graphics issue.

Hey Milan, does the video in comment 9 remind you of something?

Comment 11

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

Possibly graphics, lets find out when this regressed.

Comment 12

[Julien Wajsberg [:julienw]]

Since QA can't reproduce (and neither do I) I think they won't be able to find a window :/

Mike, maybe it would help to know which options are enabled/disabled in the Graphics part of the "Settings > Developer" menu.

Comment 13

[u3woallizom]

Regarding Graphics section of Settings > Developer, I have not (as far as I know) changed any of the default settings in the Developer section aside from "Debugging via USB".  Of course, it is possible that I unintentionally altered one or more settings further down the page.

In the Graphics section (+ indicates selected, - unselected) I have:
Flash repainted area  -
Overscrolling  +
Tiling  -
Low-precision painting  +
Low-precision transparency  +
Hardware composer  +
Draw tile borders  -
Draw layer borders  -
Dump layers tree  -
Dump layerscope  -
Cards View:  Screenshots  +

Let me know if you'd like me to try toggling any or all of the settings, or if there are any other steps you suggest to isolate the source of the problem and make it replicable.

Comment 14

[Julien Wajsberg [:julienw]]

On my phone "tiling" is enabled, but I don't see a difference by disabling it. You can try enabling it and see if it changes anything.

I also don't know how we enable/disable them with OTA...

Comment 15

[u3woallizom]

That appears to have resolved the issue!

Note that restart seems to be required for the change to take effect.  Did you restart after disabling Tiling?  If not, that may be why you don't see a change.

I can reliably replicate the black screen and resolve it by toggling the Tiling option, but only if I restart after enabling or disabling it.

Comment 16

[Julien Wajsberg [:julienw]]

QA, can you do branch checks by adding these steps at the start:

* open Settings app
* if no "Developer Menu" entry is available, go to "Device Information > More Information", and enable "Developer Menu", then go back to main panel
* enter "Developer menu" panel
* if Tiling option is enabled, disable Tiling, then reboot

Thanks!

Comment 17

[Cody Roesch [:croesch]]

Tested with Shallow Flash on 319mb using Engineering builds.

This bug repro's on Flame KK builds: Flame 2.2 KK

Actual Results: Getting black screens in the Messages app when viewing message threads. This only happens when Tiling is disabled.

Repro Rate: 2/2

Environmental Variables:
Device: Flame 2.2 KK
BuildID: 20141209040946
Gaia: 9e0b96c7b61c7ff943876ca93e2596d972437b80
Gecko: 47f0671e2c65
Version: 37.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

-----------------------------------------------------------------
-----------------------------------------------------------------

This bug does NOT repro on Flame kk build: Flame 2.1 KK, Flame 2.0 KK, Flame v188-1 Base

Actual Result: No black screen seen when viewing message theads in the messages app with the Tiling setting turned OFF in settings.

Repro Rate: 0/6

Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141209014645
Gaia: 89421df25ca321f2f4c152dd6e2146cf18b00f06
Gecko: 74fd011aacbf
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141208061237
Gaia: 856863962362030174bae4e03d59c3ebbc182473
Gecko: 2d0860bd0225
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame v188-1 Base
BuildID: 20141021162107
Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 18

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

If this is just with tiling off, we don't really care for the release version, so removing 2.2+.

Comment 19

[Benoit Girard (:BenWa)]

Keep in mind that with tiling off we exercise layer movement/rotation code paths more than normal. We still shipped non tiling layers for non scrollable layers. I think we can still hit these paths for non scrollable layers, just that it's a lot less likely.

Comment 20

[Julien Wajsberg [:julienw]]

Do you think it makes sense to at least try to have a regression window?

Also, I'd like to understand why the user does not have tiling enabled; Milan, Benoit, do you know when we enabled this pref? Is it possible that OTA did not enable it while it should have? Could it happen on shipped device when updating the phone? Or is it only the case for the Flame nightly mechanism, and in that case we should just add the information in MDN?

Comment 21

[Julien Wajsberg [:julienw]]

Let's try to at least have a regression window.

Comment 22

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

(In reply to Julien Wajsberg [:julienw] from comment #20)
> Do you think it makes sense to at least try to have a regression window?

That'd be great!


> Also, I'd like to understand why the user does not have tiling enabled;
> Milan, Benoit, do you know when we enabled this pref? Is it possible that
> OTA did not enable it while it should have? Could it happen on shipped
> device when updating the phone? Or is it only the case for the Flame nightly
> mechanism, and in that case we should just add the information in MDN?

I have no insight into what would happen with OTA when we have new or modified default preferences, but it's a bit scary if the user didn't do anything and still ended up with the "wrong" pref...

Comment 23

[u3woallizom]

(In reply to Milan Sreckovic [:milan] from comment #22)

> I have no insight into what would happen with OTA when we have new or
> modified default preferences, but it's a bit scary if the user didn't do
> anything and still ended up with the "wrong" pref...

To reiterate, it's entirely possible that I accidentally altered the Tiling setting by mistake.  I am *certain* that I only scrolled down on the Developer settings page once or at most twice to have a look.  And I can't rule out that I accidentally disabled Tiling without noticing when I was just having a look at the settings.  Hopefully this is just a case of user error.  I'm sorry I can't be certain.

Whether or not it was user error, disabling of Tiling could have happened a long time ago and I wouldn't have noticed before the update to 2.2 (as this bug does not reproduce on 2.0 or 2.1).

Comment 24

[Pi Wei Cheng [:piwei] (inactive)]

mozilla-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20141020171137
Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko: 223e2f4b0d47
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20141020172632
Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko: fa9c6845338e
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=223e2f4b0d47&tochange=fa9c6845338e

Caused by Bug 1085223.

Comment 25

[Joshua Mitchell (Inactive)]

Caused by Bug 1085223 - can you take a look Matt?

Comment 26

[Julien Wajsberg [:julienw]]

So, same regressing bug than bug 1106641; hopefully the fix to that bug will also fix this one :)

I'll ask around about prefs and OTA.

Comment 27

[Julien Wajsberg [:julienw]]

About prefs and OTA: we just use the default values from b2g.js unless the user changed it.

That said, I don't know how this works if (for example) the user enables then disables a pref: do we keep the "pref disabled" value as being set by the user (and so it won't be changed if we change the default value in b2g.js), or do we unset it?
(I'm not sure I'm really clear :) )

Also there is no way for the user to reset the phones to the default pref values.

Comment 28

[Benoit Girard (:BenWa)]

A fix to culling landed in bug 1113435. Can this be reproduced?

Comment 29

[Julien Wajsberg [:julienw]]

It seems to be a lot more usable but I still occasionally get black backgrounds. Nothing that makes the application unusable as it used to be, though.

Comment 30

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

We wouldn't really want to disable tiling.