With APZ enabled, I sometimes see pages that should have a white background, temporarily have a black background instead which then switched to white. I have so far seen this in two places: 1) The e.me privacy policy page. See STR in bug 959781. The black background can be seen periodically while scrolling around on that page. 2) The AccuWeather app. See STR in bug 964517. The black background can be seen for a moment after clicking on the search button. This happens ever time. See also the video at that bug. Note that the text overlapping that can also be seen in the above two cases looks like a separate issue and is being handled under bug 959781.

Vikram, can you provide more detail about the CS-related concern here or maybe STR for the issue you are seeing? Also, it looks like bug 959781 landed on central after you marked this bug -- does the patch there address the problem you're seeing if you apply it to 1.3?

(In reply to Botond Ballo [:botond] from comment #0) > With APZ enabled, I sometimes see pages that should have a white background, > temporarily have a black background instead which then switched to white. > > I have so far seen this in two places: > > 1) The e.me privacy policy page. See STR in bug 959781. > The black background can be seen periodically while > scrolling around on that page. > > 2) The AccuWeather app. See STR in bug 964517. > The black background can be seen for a moment after > clicking on the search button. This happens ever time. > See also the video at that bug. > > Note that the text overlapping that can also be seen in the above two cases > looks like a separate issue and is being handled under bug 959781. After some further testing, it seems likely that these are two different issues. (2) might actually be related to the problem causing the text overlapping in bug 964517, as they seem to always occur together.

Having something similar to this bug occurring on today's 1.4 in Gallery Going back to main gallery page after viewing a picture's detail view results in a black screen (with GUI still visible.) This only occurs with APZ enabled. Repro Steps: 1) Updated Buri to BuildID: 20140203040201 2) Open gallery app with some pictures present 3) Select any picture 4) Press back button in upper left hand corner Environmental Variables: Device: Buri v1.4 Master Mozilla RIL BuildID: 20140203040201 Gaia: 3b2fe2f86164f95db699b6ea2661925b21ecb994 Gecko: 44ba69cacd7e Version: 29.0a1 Firmware Version: V1.2-device.cfg Issue seems sufficiently similar to this bug (and the bug it duplicated) that I thought I would include STR here instead of writing a new bug.

I had observed the issue in https://bugzilla.mozilla.org/show_bug.cgi?id=965353 earlier. On the latest build, I do not observe this anymore.

Can we remove the CS block for this bug then?

QA Wanted - can we confirm this no longer reproduces as well?

The issues listed in comment 0 reproduce for me on the 02/03/14 1.3 and Master (1.4) builds on a Buri. - Buri 1.3 Build - Device: Buri v1.3 MOZ RIL BuildID: 20140203004001 Gaia: f9a37c77efb4621a1f57e4695b497d18601fe134 Gecko: 3d9d920ca43b Version: 28.0a2 Firmware Version: V1.2-device.cfg

Can we get ETA to fix this bug? Thank you.

(In reply to Mandyam Vikram from comment #5) > I had observed the issue in > https://bugzilla.mozilla.org/show_bug.cgi?id=965353 earlier. On the latest > build, I do not observe this anymore. What build did you see this where it wasn't reproducible?

This bug has a number of STRs (including those in duped bugs) which may be independent. - STR (1) in comment #0 (E.me privacy page) does not reproduce, with or without the bug 964517 patches. I suspect it may have been fixed by something that landed recently. - STR (2) in comment #1 (AccuWeather app) is fixed by the bug 964517 patches. - The STR in comment #4 (Gallery app) still reproduces with the bug 964517 patches. - I could not test the STRs concerning the Email app (bug 965353 and bug 972356) due to bug 974645. Keeping this bug open for now to fix the issue in the Gallery app.

(In reply to Botond Ballo [:botond] from comment #16) > - The STR in comment #4 (Gallery app) still reproduces with the > bug 964517 patches. > > ... > > Keeping this bug open for now to fix the issue in the Gallery app. The problem seems to be related to APZ requesting a displayport of size (384, 2065) in CSS pixels, which with the Nexus 4 device scale of 2 translates to (768, 4130) screen pixels. I guess this exceeds a 4096 pixel limit on a gralloc buffer size.

Sorry, typo in dependency.

Uh-oh! Is there any way we can shrink that down a little bit? Bug 965945 will start killing the gallery app if it keeps that up. A displayport that large is useless anyway since it just goes black.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #19) > Uh-oh! Is there any way we can shrink that down a little bit? Bug 965945 > will start killing the gallery app if it keeps that up. A displayport that > large is useless anyway since it just goes black. 2065 = 590 * 3.5, so we are multiplying the composition bounds height (which is correct, 1280 screen height / 2 device scale - height of various chrome) by the stationary size multiplier. I guess we could decrease the stationary size multipler a bit?

But wait.. this is for the N4. Comment 4 was on a Buri device where the composition bounds would have been smaller. Also I don't know if the 4096 limit holds for Nexus 4.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #21) > But wait.. this is for the N4. Comment 4 was on a Buri device where the > composition bounds would have been smaller. > > Also I don't know if the 4096 limit holds for Nexus 4. I tried decreasing the stationary size multiplier from 3.5 to 3.0. As a result, the gralloc buffer request that used to be (768, 4130) was now (768, 3540), and I didn't get a black screen as a result of this allocation. However, as I used the app more, I saw an allocation of size (768, 4778), which led to the black screen. This larger allocation was preceded by the corresponding setting of a displayport to 2390 CSS pixels. This tells us two things: (A) Nexus 4 seems to have the 4096 limit, as allocations larger than 4096 are correlated with black screens. (B) There is something that is causing a gralloc allocation even larger than the stationary size multiplier times the screen height. I will continue to investigate this. Quite possibly (B) is leading to a gralloc allocation > 4096 on a Buri as well. I'll confirm this tomorrow (don't have a Buri with me at the moment).

(In reply to Brogan Zumwalt from comment #4) > Having something similar to this bug occurring on today's 1.4 in Gallery > > Going back to main gallery page after viewing a picture's detail view > results in a black screen (with GUI still visible.) This only occurs with > APZ enabled. > > Repro Steps: > 1) Updated Buri to BuildID: 20140203040201 > 2) Open gallery app with some pictures present > 3) Select any picture > 4) Press back button in upper left hand corner > > Environmental Variables: > Device: Buri v1.4 Master Mozilla RIL > BuildID: 20140203040201 > Gaia: 3b2fe2f86164f95db699b6ea2661925b21ecb994 > Gecko: 44ba69cacd7e > Version: 29.0a1 > Firmware Version: V1.2-device.cfg > > Issue seems sufficiently similar to this bug (and the bug it duplicated) > that I thought I would include STR here instead of writing a new bug. Does this reproduce on 1.3? The issue is looking like bug 957668, which we decided not to fix for 1.3, so if this doesn't repro on 1.3 we probbaly just want to leave it alone and wait for bug 957668 to be fixed. Marking as qawanted, I don't have a 1.3 build handy atm.

(In reply to Botond Ballo [:botond] from comment #23) > (In reply to Brogan Zumwalt from comment #4) > > Having something similar to this bug occurring on today's 1.4 in Gallery > > > > Going back to main gallery page after viewing a picture's detail view > > results in a black screen (with GUI still visible.) This only occurs with > > APZ enabled. > > > > Repro Steps: > > 1) Updated Buri to BuildID: 20140203040201 > > 2) Open gallery app with some pictures present > > 3) Select any picture > > 4) Press back button in upper left hand corner > > > > Environmental Variables: > > Device: Buri v1.4 Master Mozilla RIL > > BuildID: 20140203040201 > > Gaia: 3b2fe2f86164f95db699b6ea2661925b21ecb994 > > Gecko: 44ba69cacd7e > > Version: 29.0a1 > > Firmware Version: V1.2-device.cfg > > > > Issue seems sufficiently similar to this bug (and the bug it duplicated) > > that I thought I would include STR here instead of writing a new bug. > > Does this reproduce on 1.3? The issue is looking like bug 957668, which we > decided not to fix for 1.3, so if this doesn't repro on 1.3 we probbaly just > want to leave it alone and wait for bug 957668 to be fixed. > > Marking as qawanted, I don't have a 1.3 build handy atm. This issue involving the Gallery app does *not* reproduce for me on the 02/20/14 1.3 build on a Buri device. Device: Buri v1.3 MOZ RIL BuildID: 20140220004003 Gaia: a43904d9646109b48836d62f7aa51e499fbf4b2e Gecko: 32fd5d798477 Version: 28.0 Firmware Version: V1.2-device.cfg

Marking 1.3? as per comment #23 and comment #24.

(and comment 16)

I've lost track of what bug is being fixed here. Can we back up here & confirm what's unrelated? QA Wanted - Can someone report on which of the dupes no longer reproduce on 1.3?

(In reply to Jason Smith [:jsmith] from comment #27) > I've lost track of what bug is being fixed here. Can we back up here & > confirm what's unrelated? > > QA Wanted - Can someone report on which of the dupes no longer reproduce on > 1.3? The dupes I see that are no longer reproducing on the 02/20/14 1.3 build are: bug 965353 & bug 966822

So that means two of the dupes still remain here as still reproducing. Are they truly dupes of this bug or should I break one or both of them out separately?

(In reply to Jason Smith [:jsmith] from comment #29) > So that means two of the dupes still remain here as still reproducing. Are > they truly dupes of this bug or should I break one or both of them out > separately? Let me try reproing them again once bug 974645 hits m-c, then I should be able to say whether they are dupes or not.

(In reply to Botond Ballo [:botond] from comment #22) > I tried decreasing the stationary size multiplier from 3.5 to 3.0. As a > result, the gralloc buffer request that used to be (768, 4130) was now (768, > 3540), and I didn't get a black screen as a result of this allocation. > However, as I used the app more, I saw an allocation of size (768, 4778), > which led to the black screen. This larger allocation was preceded by the > corresponding setting of a displayport to 2390 CSS pixels. > > This tells us two things: > > (A) Nexus 4 seems to have the 4096 limit, as allocations larger than 4096 > are correlated with black screens. > > (B) There is something that is causing a gralloc allocation even larger > than the stationary size multiplier times the screen height. I will > continue to investigate this. It looks like when we transition from the thumbnails view to viewing a single picture, the scrollable element that holds the thumbnails (a <ul> with id "thumbnails") changes dimension from (0, 0, 384, 590) to (0, -1800, 384, 2390) [all numbers in CSS pixels]. Note that 2390 pixels is the height of the scrollable content inside the element. This seems like a strange thing to happen. David, do you know why this happens?

I've got no clue why that would be happening. When we go from thumbnails to a single large image, the thumbnails element just goes from visibility:visible to visibility:hidden. (Maybe it would be better to use display:block and display:none... I don't know if that would help here). But I've got no idea why the y position and the height would change. (I don't suppose you had happened to scroll down exactly 1800 pixels before doing this test, had you?) Sorry not to be more help.

(In reply to David Flanagan [:djf] from comment #32) > I've got no clue why that would be happening. When we go from thumbnails to > a single large image, the thumbnails element just goes from > visibility:visible to visibility:hidden. (Maybe it would be better to use > display:block and display:none... I don't know if that would help here). According to the app manager this happens because when you go to a single large image, the body class changes from "thumbnailListView" to "fullscreenView", and the following style blocks no longer apply: https://github.com/mozilla-b2g/gaia/blob/404867b0d91e6f2af7dde236f61128525823ba77/apps/gallery/style/gallery.css#L179 https://github.com/mozilla-b2g/gaia/blob/404867b0d91e6f2af7dde236f61128525823ba77/apps/gallery/style/gallery.css#L185 Since the top and bottom are no longer specified this causes the position:absolute <ul> to expand to the observed height. This should be fixable by putting a top and/or bottom property into the block dedicated for thumbnails here: https://github.com/mozilla-b2g/gaia/blob/404867b0d91e6f2af7dde236f61128525823ba77/apps/gallery/style/gallery.css#L150

This seems to fix it. The top will still get overridden in thumbnailSelectView and pickView to be 5rem.

(In reply to Botond Ballo [:botond] from comment #30) > (In reply to Jason Smith [:jsmith] from comment #29) > > So that means two of the dupes still remain here as still reproducing. Are > > they truly dupes of this bug or should I break one or both of them out > > separately? > > Let me try reproing them again once bug 974645 hits m-c, then I should be > able to say whether they are dupes or not. I couldn't reproduce bug 972356 on Nexus 4 running master. On Buri running 1.3, I'm unable to load the screen where you enter your gmail username/password. I get "An error occurred during a connection to accounts.google.com, SSL received a malformed Server Hello handshake message (Error code: ssl_error_rx_malformed_server_hello)". Bug 972763 is clearly a duplicate of bug 972356.

(In reply to Botond Ballo [:botond] from comment #35) > On Buri running > 1.3, I'm unable to load the screen where you enter your gmail > username/password. I get "An error occurred during a connection to > accounts.google.com, SSL received a malformed Server Hello handshake message > (Error code: ssl_error_rx_malformed_server_hello)". Same problem on Nexus 4 running 1.3. Is anyone else seeing this? Is it a recent regression on the 1.3 branch perhaps?

I'm able to reproduce bug 972356 but to me it appears to be an evangelism issue. I can't inspect the google page that opens in the app manager, so there's no way for me to tell what it's doing, but to me it just looks like the background of the page is black. Content on top of the background is drawing fine, so it's not a GL texture problem.

Preeti, who can check with e.me and Accuweather? (see comment 37) and switch this to TechEvangelism?

(In reply to Milan Sreckovic [:milan] from comment #38) > Preeti, who can check with e.me and Accuweather? (see comment 37) and switch > this to TechEvangelism? The thing Kats suggested might be an evangelism issue, bug 972356, concerns the Email app, not the e.me and Accuweather apps. (The e.me STR no longer reproduces, and the Accuweather one was fixed by bug 964517).

(In reply to Botond Ballo [:botond] from comment #39) > (In reply to Milan Sreckovic [:milan] from comment #38) > > Preeti, who can check with e.me and Accuweather? (see comment 37) and switch > > this to TechEvangelism? > > The thing Kats suggested might be an evangelism issue, bug 972356, concerns > the Email app, not the e.me and Accuweather apps. Sorry, not the Email app. The page where you import contacts from Gmail, which is Google's page.

(In reply to Botond Ballo [:botond] from comment #35) > (In reply to Botond Ballo [:botond] from comment #30) > > (In reply to Jason Smith [:jsmith] from comment #29) > > > So that means two of the dupes still remain here as still reproducing. Are > > > they truly dupes of this bug or should I break one or both of them out > > > separately? > > > > Let me try reproing them again once bug 974645 hits m-c, then I should be > > able to say whether they are dupes or not. > > I couldn't reproduce bug 972356 on Nexus 4 running master. On Buri running > 1.3, I'm unable to load the screen where you enter your gmail > username/password. I get "An error occurred during a connection to > accounts.google.com, SSL received a malformed Server Hello handshake message > (Error code: ssl_error_rx_malformed_server_hello)". > > Bug 972763 is clearly a duplicate of bug 972356. Sounds like something might not be working your build - maybe the phone's date isn't right? SSL errors typically prominent on device if your phone has a wrong date older than a year. I'm moving the discussion of this over to bug 972356 though.

Jason can you do me a solid and file a bug that we should not allow the date to be set prior to <today> and we automatically update it to at least that date? Making wanted for 1.5 or something. Thanks.

Comment on attachment 8379726 [details] Gallery CSS patch Looks good to me. I did not test it myself. I don't know if this is a regression. If so, it was likely caused by CSS changes to support the flatfish tablet. So it would be great if someone could test the patch on flatfish, too.

I don't have a flatfish; Jason or Milan, do you know if QA people and/or anybody in the Toronto office have a flatfish they can test on? Basically need to apply the gaia patch from attachment 8379726 [details] and do a sanity check on the gallery to make sure the thumbnail view isn't broken.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #44) > I don't have a flatfish; Jason or Milan, do you know if QA people and/or > anybody in the Toronto office have a flatfish they can test on? Basically > need to apply the gaia patch from attachment 8379726 [details] and do a > sanity check on the gallery to make sure the thumbnail view isn't broken. I think Eric should be able you with this request.

For the sake of clarity - reworking title to focus on what this bug is fixing.

It looks okay on flatfish with or without the patch. ~/mozilla-b2g/gaia$ git rev-parse HEAD 16767eb7ed284bc89604aa00be145ef67343f0bc

checkin-needed to merge the gaia pull request from attachment 8379726 [details].

Master: d26d28370ae014dc65650c28726839b04cfc2e0d

Late to the party, but just to be clear - flatfish only issues are not a priority for 1.4.

Dears, will you land the patch to 1.3?, bug#975972 depends on the patch.

(In reply to Jack Liu from comment #51) > Dears, > > will you land the patch to 1.3?, bug#975972 depends on the patch. That's actually a different problem than this bug. That bug was confirmed as works for me on the latest 1.3 build.

Tested and working 1.4 Gecko ce6783c Gaia 7306709 Patform version: 30.0a2 Build ID: 20140324052001 Git commit: 73067095