869903 - [Gallery] Repeating from Landscape to Portrait mode and vice-versa, white screen appear on some part of the screen

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Gallery, defect, P1)

Description

[Leo]

1. Title: After gallery is loaded images and any image changes from Landscape to Portrait mode and vice-versa, white screen appear on some part of the display screen  
2. Precondition: 300 mb of images in external SD card
3. Tester's Action: (1) insert the SD card, which has 300 mb of images 
                    (2) Power On
                    (3) Open gallery 
                    (4) Open the any one image
                    (5) Frequently move from Landscape to Portrait mode and vice-versa 
4. Detailed Symptom (ENG.) : White screen is appearing in some part of the screen  of  the window and image in remaining part of display window for a moment 
5. Expected: it should not display the white screen and image should display on full screen
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia Master/v1-train: Reproduced on Gaia master
8. Gaia Revision:  61d7ab244db3e2174b22bfa6de3e3d69136b4904
9. Personal email id: [e-mail]

Comment 1

[Leo]

This comment add the delatiled Symptom:
Around the 300 mb images are huge amount of data. If the images are considered around of less in resolution [800x533, 472x600, etc.], it is around 3000 images in external SD card.  While loading the gallery, it will load the images one by one and display in portrait grid view of the gallery.  As the number of the Images get added to grid view of the galley, size of the grid view page get increase. In such case when, gallery change from portrait mode to landscape mode and vice-versa, white screen appears on some part of the display screen for a moment.
If the same amount of images of higher resolution [5 MP] are loaded in external SD card, the issue is not reproducible. The portrait mode page length may be one of the reasons to cause the issue.

Comment 2

[Leo]

Attachment: White screen on some part of the diplay screen

Comment 3

[Leo]

Attachment: Another eg : White screen on some part of the diplay screen

Hi , 

Uploaded screen shots for the defect

Comment 4

[Leo]

For attachment:
--------------- 
1. White screen on some part of the diplay screen (84.64 KB, image/png)
2. Another eg : White screen on some part of the diplay screen 
Because of the white background, It is not visiable. Please save the image to the system.

Comment 5

[David Flanagan [:djf]]

If I'm understanding the report correctly, the white rectangles are transient, and only occur when the app is busy scanning images. So in a sense, the issue is just that low-powered CPUs don't perform well when they're under high load.

If there is a bug here, it is almost certainly a gecko or graphics bug, not something specific to Gaia::Gallery.

If we can reproduce the bug we might be able to work around it in the Gallery app, however. Maybe when we get a resize event we can clear the screen and then restore it.  If the CPU is heavily loaded, I'd still expect a sluggish response, but maybe we can get a sluggish response with a blank screen rather than a sluggish response that shows an invalid screen.

Comment 6

[David Flanagan [:djf]]

In the second attached screenshot, it appears that the white screen is occuring when rotating the phone in thumbnails view. That is, this is not just related to the way we display full-screen photos, but it happens whenever the phone is rotated.

So this really is a gecko bug, not a gaia bug. I'm not sure what to change the component to, however.

Comment 7

[Alex Keybl [:akeybl]]

Leo - what's your desired outcome for this bug?

Would you like the animation to be very quick regardless of CPU usage? That would be a new perf requirement.

Or would you like the background to be changed to black for the short amount of time the background is displayed?

Comment 8

[Leo]

(In reply to David Flanagan [:djf] from comment #5)
> If I'm understanding the report correctly, the white rectangles are
> transient, and only occur when the app is busy scanning images. So in a
> sense, the issue is just that low-powered CPUs don't perform well when
> they're under high load.
> 
> If there is a bug here, it is almost certainly a gecko or graphics bug, not
> something specific to Gaia::Gallery.
> 
> If we can reproduce the bug we might be able to work around it in the
> Gallery app, however. Maybe when we get a resize event we can clear the
> screen and then restore it.  If the CPU is heavily loaded, I'd still expect
> a sluggish response, but maybe we can get a sluggish response with a blank
> screen rather than a sluggish response that shows an invalid screen.

The question on comment 5. to reproduce the issue and large processing power is need. this is not related to gaia also. is their any specific reasion that the issue becasue of gecko ?

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

triage: leo-, tracking-b2g18+. it's bad for users to see white partial screens but should not block release. would take a patch with approval

Comment 10

[David Flanagan [:djf]]

Leo: I don't understand your question. What information do you need from me?

Comment 11

[Leo]

(In reply to David Flanagan [:djf] from comment #10)
> Leo: I don't understand your question. What information do you need from me?

Is there any specific reason that issue cause by gecko?

Comment 12

[David Flanagan [:djf]]

(In reply to Leo from comment #11)
> (In reply to David Flanagan [:djf] from comment #10)
> > Leo: I don't understand your question. What information do you need from me?
> 
> Is there any specific reason that issue cause by gecko?

The bug occurs during an orientation change. Gecko handles that, so it seems like this is probably a gecko issue. The bug displays white squares, and the app never uses white for anything.

Maybe we can work around it in Gaia, but I don't think it is a Gaia bug.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

Change component to system and taken first, recently we're having some orientation UI bugs,

Comment 14

[Jim Porter (:squib)]

It might be useful to have a video of the issue in action to make it easier to determine exactly when this happens and how transient the corruption is.

Comment 15

[David Flanagan [:djf]]

Bug 848288 is also about the appearance of white regions. While investigating that, I've realized that bug 866174 recently removed the background-color:black setting on the body element.

Alive: if you can reproduce this bug, try putting the background color back to see if the white square symptom goes away.  (There might still be an orientation bug, but changing the white to black will make it much less noticeable.)

If that fixes things, then discuss with Vivien how best to fix this without breaking his patch in bug 866174.

Comment 16

[Leo]

Attachment: Video Attachment

300 mb of small resolution images in external SD card. After gallery loading  is completed.

Comment 17

[Leo]

Attachment: Video Attachment

300 mb of small resolution images in external SD card. After gallery loading  is completed.

Comment 18

[Leo]

(In reply to Jim Porter (:squib) from comment #14)
> It might be useful to have a video of the issue in action to make it easier
> to determine exactly when this happens and how transient the corruption is.

Please see the attached videos

Comment 19

[Jim Porter (:squib)]

Based on the videos, I think I agree with comment 15: if we just change the background-color, this should be significantly less jarring. It might be worth figuring out what's causing us to do this in the first place though, but I have no idea where to start looking. Perhaps the orientation change is happening with too low a priority?

Comment 20

[Lucas Adamski [:ladamski]]

Sorry, just noticed this was previously changed from Gallery to System component.  None the less, maybe we should figure out if there's a simple workaround for gallery while investigating the bug in more detail separately?

Comment 21

[David Flanagan [:djf]]

Jim,

Why don't you investigate per comment 15. If that fixes the bug (or at least the symptom of the bug) you can take this from Alive.  And if not, we've at least confirmed that it is a system bug not a gallery bug.

But note that we can't just set the background back to black or it will break Vivien's patch which I think had something to do with an icon or splash screen showing through a transparent body element before the rest of the document had loaded.  

Maybe we can change the background color after the app is fully loaded or something?  Or maybe there is somewhere else in the element hierarchy where we can add an opaque background.

Comment 22

[David Flanagan [:djf]]

This has been listed as a priority bug for the San Diego work week. Alive and Jim: let me know if you'd like me to take this.

Comment 23

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to David Flanagan [:djf] from comment #22)
> This has been listed as a priority bug for the San Diego work week. Alive
> and Jim: let me know if you'd like me to take this.

David, welcome to steal.

Comment 24

[Jim Porter (:squib)]

Taking.

Comment 25

[Jim Porter (:squib)]

Just an update on this: I'm having some real troubles flashing my Leo device; trying `./config.sh leo` (or anything else, really) gives me a bunch of "fatal: The remote end hung up unexpectedly" responses, and so I'm left with a broken build environment. I've already bricked my Ikura doing this, which I hope I'll be able to fix once I resolve my issues with configuring.

Comment 26

[Leo]

As discussed during San Diego work week marking this as leo+

Comment 27

[Jim Porter (:squib)]

Ok, I think I might have bricked my Leo device, so it might be a good idea for someone else to take a look at this too, in case I can't get it fixed in time. (Luckily for my other bugs, I have other devices I can test on -- I think.)

Comment 28

[Jim Porter (:squib)]

Oh, I should also mention that I tried reproducing this on my Unagi, but I'm not seeing the issue, so using another device to reproduce this bug doesn't seem to work.

Comment 29

[David Flanagan [:djf]]

Randy investigated the hypothesis of comment 15 and found that restoring the black background of the app does not fix the bug.  So I don't think we can do anything about this in Gaia.  Randy has taken the bug and will investigate a gecko fix.

We've learned that this is not dependent on a Leo device: Randy duplicated it on his Unagi. But it really does need thousands of photos in the gallery before it starts to appear, so maybe it has something to do with the way we handle images under memory pressure?

Comment 30

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Can reproduce on unagi device @b2g18 05/29 nightly build with 3k jpg files in SD card.

Comment 31

[Jim Porter (:squib)]

(In reply to David Flanagan [:djf] from comment #29)
> We've learned that this is not dependent on a Leo device: Randy duplicated
> it on his Unagi. But it really does need thousands of photos in the gallery
> before it starts to appear, so maybe it has something to do with the way we
> handle images under memory pressure?

Well, that explains why I didn't see this on Unagi; I must not have had enough photos to trigger it.

Comment 32

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Attachment: unagi repo video

Comment 33

[Andreas Gal :gal]

Its white despite a black background? It seems to me that we paint the current layout and then reflow, and that first paint is white for some reason.

Comment 34

[Chiajung Hung [:chiajung]]

This is a layer transaction synchronization problem and there is a orientation sync time limit in b2g.js:

layers.orientation.sync.timeout

set this value to higher value can fix the problem. In original design, this value should be infinite, and :cjones suggest that we should limit the timeout to avoid some unexpected problem cause layer tree destruction or similar to prevent screen update.

Though the problem should be fixed by make the limit to higher value, I don't know why it is broken now. I will upload a fix to it later.

Comment 35

[Chiajung Hung [:chiajung]]

Attachment: Patch V1 - Fix orientation timeout

This patch is for mozilla-central version. 

This patch fix:
- Orientation change in some app need sync (e.g.Gallery) then any orientation change in other apps have to wait until timeout

Though this patch may not fix the symptom in this bug, I think it should be land to fix the pref. If you think that I should file another bug for that, please let know me, and I will file it!

 *NOTE*: This patch does not change the timeout value. Since any reflow should not take longer than 1 sec after orientation change. Please apply this patch, and try to increase the timeout value to check whether the problem occurs.

Comment 36

[Chiajung Hung [:chiajung]]

I think b2g18 do not have the preference problem.

Comment 37

[Nick Cameron [:nrc]]

Comment on attachment 755788 [details] [diff] [review]
Patch V1 - Fix orientation timeout

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

r=me if this gets a better commit message

Comment 38

[Chiajung Hung [:chiajung]]

https://tbpl.mozilla.org/?tree=Try&rev=07bcaa3768a1

Comment 39

[Chiajung Hung [:chiajung]]

I managed to reproduce the problem once, this problem is not sync problem. The layer orientation is in fact synced up. But the layout is incorrect.

It seems for me that the layer tree is shifted with correct orientation. I think we should find someone familiar with layer construction and reflow to help this bug.

Comment 40

[Chiajung Hung [:chiajung]]

Attachment: Patch V1 - Fix orientation timeout

Add comment, carry r+.

NOTE: This patch is checkin-needed but this do not fix the problem.

Comment 41

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Check with Chiajung, 
For b2g18 branch , change this pref in b2g.js from 1000ms to 5000ms, it helps. 
+pref("layers.orientation.sync.timeout", 5000);

But if the orientation change takes more than 5s, the user still can see the white region, this change also reduce the happen rate to low.

Comment 42

[Andreas Gal :gal]

We don't want that 5000ms hack. The problem seems to be that we don't clear the frame buffer to black. That needs a fix.

Comment 43

[Michael Wu [:mwu]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10119

Pointer to Github pull-request

Comment 44

[Michael Wu [:mwu]]

Comment on attachment 756280 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10119

This sets the default background of packaged apps to black, which is a less noticeable color than white when we can't reflow the app in time.

Comment 45

[Andre Graziani (:graziani)]

Hi Michael,

please refer to bug 863609.
It is the same problem, but reported in Video application.
This patch could help in that issue also, since it is applyed in System app.
Shall we mark it as duplicated?

Comment 46

[Michael Wu [:mwu]]

(In reply to andre.graziani from comment #45)
> Hi Michael,
> 
> please refer to bug 863609.
> It is the same problem, but reported in Video application.
> This patch could help in that issue also, since it is applyed in System app.
> Shall we mark it as duplicated?

We can mark as duplicated if we decide this patch is what we want to do.

Comment 47

[:gerard-majax]

Comment on attachment 756280 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10119

stealing the review as per david request

Comment 48

[:gerard-majax]

I'd say r+ if you change the "origin.substr()" call to an origin.indexOf() check, as it is done in other areas of gaia.

Comment 49

[Michael Wu [:mwu]]

(In reply to Alexandre LISSY :gerard-majax from comment #48)
> I'd say r+ if you change the "origin.substr()" call to an origin.indexOf()
> check, as it is done in other areas of gaia.

Done. Definitely looks nicer that way.

Comment 50

[:gerard-majax]

(In reply to Michael Wu [:mwu] from comment #49)
> (In reply to Alexandre LISSY :gerard-majax from comment #48)
> > I'd say r+ if you change the "origin.substr()" call to an origin.indexOf()
> > check, as it is done in other areas of gaia.
> 
> Done. Definitely looks nicer that way.

Thanks !

Comment 51

[:gerard-majax]

I'm not sure that I can perform the merge, however.

Comment 52

[Michael Wu [:mwu]]

I'll do the uplift for this since the css rule needs a little bit of tweaking for v1-train.

Comment 53

[Michael Wu [:mwu]]

https://github.com/mozilla-b2g/gaia/commit/cb6d9120b97a50b86da6e5d73d59c844bc2157a8

Comment 54

[(inactive after 6/18) Alive Kuo [:alive]]

What's this?
The gaia patch doesn't look reasonable to me.

Why don't we take the gecko fix here?

Comment 55

[Michael Wu [:mwu]]

Backed out due to regressions:

https://github.com/mozilla-b2g/gaia/commit/8faac42c35e9f3e894b9b88f1e25d410a1225ab3 (master)
https://github.com/mozilla-b2g/gaia/commit/409085ce73363a79a7df5b89ba1be650c22c5618 (v1-train)

Comment 56

[Michael Wu [:mwu]]

Attachment: Report app's background color on mozbrowserfirstpaint

This makes mozbrowserfirstpaint report the background color so the window manager can select an appropriate background color for the iframe.

Not sure if firstpaint is a good event, but it seems like the app will have white flashing problems if it can't get the background right on first paint.

Comment 57

[Justin Lebar (not reading bugmail)]

Comment on attachment 757544 [details] [diff] [review]
Report app's background color on mozbrowserfirstpaint

f=me on reporting the bg color on the firstload event.  That sounds fine.

But instead of setting the detail property to the bg color, I think we should set detail to {backgroundColor = color}.  This gives us room to grow and add other properties.

This also needs a test.

Comment 58

[Michael Wu [:mwu]]

Attachment: Report app's background color on mozbrowserfirstpaint, v2

Added a simple test. Will ask for review after running through try.

Comment 59

[Michael Wu [:mwu]]

Attachment: Report app's background color on mozbrowserfirstpaint, v3

Forgot to remove some debugging code.

Comment 60

[Michael Wu [:mwu]]

https://tbpl.mozilla.org/?tree=Try&rev=065bc4f7043e

Comment 61

[Michael Wu [:mwu]]

Attachment: Set iframe background to app background using firstpaint (gaia patch)

This uses mozbrowserfirstpaint to determine what the background color should be.

Bug 866174 removed background-color from most apps. They'll need to be put back for this to work well in other apps.

Comment 62

[(inactive after 6/18) Alive Kuo [:alive]]

Does this report the true color of the iframe "background"?
How if an app specify body's backgroundColor = black but it has a 100%width/height div under the body element with color=white?
Does this event fires every time the app changes the backgroundColor?

(In reply to Justin Lebar [:jlebar] from comment #57)
> Comment on attachment 757544 [details] [diff] [review]
> Report app's background color on mozbrowserfirstpaint
> 
> f=me on reporting the bg color on the firstload event.  That sounds fine.
> 
> But instead of setting the detail property to the bg color, I think we
> should set detail to {backgroundColor = color}.  This gives us room to grow
> and add other properties.
> 
> This also needs a test.

Comment 63

[Michael Wu [:mwu]]

(In reply to Alive Kuo [:alive] from comment #62)
> Does this report the true color of the iframe "background"?
> How if an app specify body's backgroundColor = black but it has a
> 100%width/height div under the body element with color=white?
> Does this event fires every time the app changes the backgroundColor?
> 

This is only a simple heuristic to make things less noticeable when we can't reflow the app in time. Obviously, apps can do any number of things to defeat the heuristic.

Comment 64

[(inactive after 6/18) Alive Kuo [:alive]]

This kind of sad workaround would make window manager un-manage-able.
Though you don't set review to me,
please add a comment to describe what this code specifies.

// XXX: This workaround is to ....(what you said)

Comment 65

[Michael Wu [:mwu]]

I don't consider it a workaround - it's just a backup plan. Apps can waste large amounts of time if they want to and defeat any time limit we have for rotation. Android has the same problem and we had to give Android a bit of a hint to how to draw our background when Fennec can't respond in time.

Of course, a comment still won't hurt and I'll add one to the gaia patch.

Comment 66

[Justin Lebar (not reading bugmail)]

Comment on attachment 757766 [details] [diff] [review]
Report app's background color on mozbrowserfirstpaint, v3

This test would pass if we always returned "transparent" for the bg color (which is precisely the failure mode we thought we might have been in earlier today).

Can you test that we are capable of returning two different bg colors?

>+    ok(e.detail.backgroundColor == "transparent", "Got a background color.");

Does is() work?  It'll give a nicer message if it fails.

Comment 67

[Michael Wu [:mwu]]

Test changes made and running on try.

https://tbpl.mozilla.org/?tree=Try&rev=98efa1fa30b9

Comment 68

[Michael Wu [:mwu]]

Comment on attachment 757770 [details] [diff] [review]
Set iframe background to app background using firstpaint (gaia patch)

This is a request for review on just the window manager part. It looks like some work was done to remove the background-color of apps on master so I won't want to remove this without addressing the flickering you saw. However, on v1-train, the background colors are still applied and this patch will make things better there.

Comment 69

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 757770 [details] [diff] [review]
Set iframe background to app background using firstpaint (gaia patch)

>diff --git a/apps/gallery/style/gallery.css b/apps/gallery/style/gallery.css
> 
> body {
>+  background-color: black;

As you guess I removed the background colors because of a flicker when the app was showing right after the screenshot was removed. I'm afraid that this will add it back but the more I think about it the more I think it should be resolved differently since third party content is not going to remove it. So that's fine for me if the flicker comes back.

>diff --git a/apps/system/js/window_manager.js b/apps/system/js/window_manager.js
> 
>+  windows.addEventListener('mozbrowserfirstpaint', function (evt) {
nit: let's add a name to this anonymous function. Maybe firstpaint?

>+    var iframe = evt.target;
no need to assign this variable before it is used. Even just using evt.target will be enough.

nit: var backgroundColor = evt.detail.backgroundColor; and then use it.

>+    if (evt.detail.backgroundColor.indexOf('rgb(') != -1) {
I'm not really sure why you are checking for rgb here. I would have expect it to be sanitize by the browser api here.

>+      iframe.style.backgroundColor = evt.detail.backgroundColor;
>+    }
>+  });

Please do not forgot to add a comment as Alive mentionned.


Also I agree with Alive about the first patch that tries to add a black background color to packaged app. It does not sound good.
This one makes sense to me though - so I'm mostly r- it because I want to see a new version of the patch.

Comment 70

[Michael Wu [:mwu]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #69)
> >diff --git a/apps/system/js/window_manager.js b/apps/system/js/window_manager.js
> > 
> >+  windows.addEventListener('mozbrowserfirstpaint', function (evt) {
> nit: let's add a name to this anonymous function. Maybe firstpaint?
> 

mozbrowserloadend already uses firstpaint, amusingly. I'll rename that one and use firstpaint here.

> >+    if (evt.detail.backgroundColor.indexOf('rgb(') != -1) {
> I'm not really sure why you are checking for rgb here. I would have expect
> it to be sanitize by the browser api here.
> 

This is mostly so we don't do anything if the app defaults to transparent or tries to use RGBA - transparent windows seem like a security issue.

Comment 71

[Michael Wu [:mwu]]

Attachment: Set iframe background to app background using firstpaint (gaia patch), v2

Review comments addressed.

Comment 72

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Michael Wu [:mwu] from comment #70)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #69)
> > >diff --git a/apps/system/js/window_manager.js b/apps/system/js/window_manager.js
> > > 
> > >+  windows.addEventListener('mozbrowserfirstpaint', function (evt) {
> > nit: let's add a name to this anonymous function. Maybe firstpaint?
> > 
> 
> mozbrowserloadend already uses firstpaint, amusingly. I'll rename that one
> and use firstpaint here.

Could be that I made the exact same comment in the past but for the wrong event :)

> 
> > >+    if (evt.detail.backgroundColor.indexOf('rgb(') != -1) {
> > I'm not really sure why you are checking for rgb here. I would have expect
> > it to be sanitize by the browser api here.
> > 
> 
> This is mostly so we don't do anything if the app defaults to transparent or
> tries to use RGBA - transparent windows seem like a security issue.

Adding a comment to explain it would be good then.

Comment 73

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 758269 [details] [diff] [review]
Set iframe background to app background using firstpaint (gaia patch), v2

>diff --git a/apps/system/js/window_manager.js b/apps/system/js/window_manager.js
>+    /* Only allow opaque colors */

Seems like you already added the comment.

>+    if (backgroundColor.indexOf('rgb(') != -1) {
>+      evt.target.style.backgroundColor = backgroundColor;
>+    }
>+  });
>+
>+  windows.addEventListener('mozbrowserloadend', function loadend(evt) {

Thanks for the renaming.

Comment 74

[Michael Wu [:mwu]]

https://hg.mozilla.org/projects/birch/rev/3b3acc25c034
https://github.com/mozilla-b2g/gaia/commit/4bbe3c7034e98e4b5b9fa61c0b462c43258d5fc5

Uplift will require a slightly different patch for gaia.

Comment 75

[Michael Wu [:mwu]]

Gecko side backed out for a test failure. Apparently the test I edited wasn't on the whitelist of b2g tests.

https://hg.mozilla.org/projects/birch/rev/ace064f09f79

Comment 76

[Justin Lebar (not reading bugmail)]

(In reply to Michael Wu [:mwu] from comment #75)
> Gecko side backed out for a test failure. Apparently the test I edited
> wasn't on the whitelist of b2g tests.

It's true that the mozbrowser tests don't run on B2G; they run on Linux desktop.  (mozbrowser and its unit tests predate b2g testing.)  We haven't had any problems with running these tests only on desktop, that I'm aware of.

Comment 77

[Michael Wu [:mwu]]

https://tbpl.mozilla.org/?tree=Try&rev=c46433e8cd72

Comment 78

[Michael Wu [:mwu]]

I'm still getting failures on the test and I'm not sure why. It seems to return transparent on a page with a green background.

https://tbpl.mozilla.org/?tree=Try&rev=98c7f4fd4f24

Comment 79

[Michael Wu [:mwu]]

Attachment: Report app's background color on mozbrowserfirstpaint, v4

Tests pass locally.

Comment 80

[Michael Wu [:mwu]]

https://hg.mozilla.org/projects/birch/rev/a0faa1e1837e

Comment 81

[Michael Wu [:mwu]]

Backed out again for orange on Linux.

https://hg.mozilla.org/projects/birch/rev/bd28d8ca7112

Comment 82

[Michael Wu [:mwu]]

Attachment: Report app's background color on mozbrowserloadend

This seems to be more reliable in tests. Will push to try.

Comment 83

[Michael Wu [:mwu]]

https://tbpl.mozilla.org/?tree=Try&rev=8f6b7e5fcb1a

Comment 84

[Justin Lebar (not reading bugmail)]

Comment on attachment 760639 [details] [diff] [review]
Report app's background color on mozbrowserloadend

Sure, if it works.

Comment 85

[Michael Wu [:mwu]]

Attachment: Switch to mozbrowserloadend in gaia

This is a follow up to use the new event.

Comment 86

[Michael Wu [:mwu]]

https://hg.mozilla.org/projects/birch/rev/03ef793619f2
https://github.com/mozilla-b2g/gaia/commit/f6ad4a959b610daf8cfc95f618490ef4c0f9b16e

Comment 87

[Michael Wu [:mwu]]

Attachment: Report app's background color on mozbrowserloadend (b2g18)

Comment 88

[Michael Wu [:mwu]]

Attachment: Set iframe background to app background using firstpaint (gaia patch, v1-train)

Comment 89

[Michael Wu [:mwu]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/d731940d886b
https://github.com/mozilla-b2g/gaia/commit/ba1cf2af3f0286dc665492e2ed19275c8aa34a34

Comment 90

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/03ef793619f2

Comment 91

[Michael Wu [:mwu]]

Follow up to fix the test on b2g18 -

https://hg.mozilla.org/releases/mozilla-b2g18/rev/b4f8f0a288ca

Comment 92

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/d731940d886b
https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/b4f8f0a288ca

Comment 93

[Parul Mathur]

Attachment: Black background in portrait mode

Verified fixed on:
Device: Leo phone
Build Identifier: 20130612070210
Update channel: no-update-commercial-ril
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/b4f8f0a288ca
Gaia: 547db47241459b5944ba40bacc94b15977d8a02e1371033420
Git commit info: 2013-06-12 10:37:00
OS version: 1.1.0.0-prerelease

Prerequisites:
Load the SD Card of the B2G phone with a large number of images (roughly 3000).

Scenario #1
Steps to Reproduce:
1. On the B2G phone home screen, tap on the Gallery icon to launch the Gallery app.
2. Wait for the Gallery app to display thumbnails of almost all images.
3. When a large number of thumbnails have been displayed, rotate the phone from portrait mode to landscape mode and vice versa.

Expected Result:
Some part of the screen is in the default background color of black as the Gallery app takes time to display the thumbnails in a different orientation.
(see screenshots attached)

Actual Result:
Matches the expected result.

Comment 94

[Parul Mathur]

Attachment: Black background in landscape orientation

Comment 95

[Parul Mathur]

Created test case in MozTrap: https://moztrap.mozilla.org/manage/case/8753/