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: ntiaj12345@gmail.com

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.

Hi , Uploaded screen shots for the defect

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.

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.

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.

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?

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

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

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

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

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

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

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.

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.

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

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

(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

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?

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?

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.

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.

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

Taking.

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.

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

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

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.

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?

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

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

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.

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.

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.

I think b2g18 do not have the preference problem.

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

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.

Add comment, carry r+. NOTE: This patch is checkin-needed but this do not fix the problem.

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.

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.

Pointer to Github pull-request

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.

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?

(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 on attachment 756280 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10119 stealing the review as per david request

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.

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

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

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

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

What's this? The gaia patch doesn't look reasonable to me. Why don't we take the gecko fix here?

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

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

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

Forgot to remove some debugging code.

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.

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.

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

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)

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

Test changes made and running on try. https://tbpl.mozilla.org/?tree=Try&rev=98efa1fa30b9

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

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

Review comments addressed.

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

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.

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

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

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

Tests pass locally.

Backed out again for orange on Linux. https://hg.mozilla.org/projects/birch/rev/bd28d8ca7112

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

Comment on attachment 760639 [details] [diff] [review] Report app's background color on mozbrowserloadend Sure, if it works.

This is a follow up to use the new event.

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

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

Follow up to fix the test on b2g18 - https://hg.mozilla.org/releases/mozilla-b2g18/rev/b4f8f0a288ca

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

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.

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