965389 - Going back to main gallery page after viewing a picture's detail view results in a black screen (with GUI still visible.)

Status: VERIFIED FIXED

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

Description

[Botond Ballo [:botond]]

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.

Comment 2

[Dylan Oliver [:doliver]]

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?

Comment 3

[Botond Ballo [:botond]]

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

Comment 4

[Brogan Zumwalt [Inactive]]

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.

Comment 5

[Mandyam Vikram]

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.

Comment 6

[Dylan Oliver [:doliver]]

Can we remove the CS block for this bug then?

Comment 7

[Jason Smith [:jsmith]]

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

Comment 8

[Matthew Vaughan]

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

Comment 10

[Kai-Chih Hu [:khu]]

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

Comment 11

[Chris Lee [:clee]]

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

Comment 16

[Botond Ballo [:botond]]

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.

Comment 17

[Botond Ballo [:botond]]

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

Comment 18

[Botond Ballo [:botond]]

Sorry, typo in dependency.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 20

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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?

Comment 21

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 22

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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).

Comment 23

[Botond Ballo [:botond]]

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

Comment 24

[Matthew Vaughan]

(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

Comment 25

[Botond Ballo [:botond]]

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

Comment 26

[Kartikaya Gupta (email:[e-mail])]

(and comment 16)

Comment 27

[Jason Smith [:jsmith]]

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?

Comment 28

[Matthew Vaughan]

(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

Comment 29

[Jason Smith [:jsmith]]

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?

Comment 30

[Botond Ballo [:botond]]

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

Comment 31

[Botond Ballo [:botond]]

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

Comment 32

[David Flanagan [:djf]]

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.

Comment 33

[Kartikaya Gupta (email:[e-mail])]

(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

Comment 34

[Kartikaya Gupta (email:[e-mail])]

Attachment: Gallery CSS patch

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

Comment 35

[Botond Ballo [:botond]]

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

Comment 36

[Botond Ballo [:botond]]

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

Comment 37

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 38

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

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

Comment 39

[Botond Ballo [:botond]]

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

Comment 40

[Botond Ballo [:botond]]

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

Comment 41

[Jason Smith [:jsmith]]

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

Comment 42

[Andreas Gal :gal]

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 43

[David Flanagan [:djf]]

Comment on attachment 8379726 [details] [review]
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.

Comment 44

[Kartikaya Gupta (email:[e-mail])]

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] [review] and do a sanity check on the gallery to make sure the thumbnail view isn't broken.

Comment 45

[Jason Smith [:jsmith]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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] [review] 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.

Comment 46

[Jason Smith [:jsmith]]

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

Comment 47

[Eric Chang [:ericcc] [:echang]]

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

Comment 48

[Kartikaya Gupta (email:[e-mail])]

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

Comment 49

[Ryan VanderMeulen [:RyanVM]]

Master: d26d28370ae014dc65650c28726839b04cfc2e0d

Comment 50

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

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

Comment 51

[Jack Liu]

Dears, 

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

Comment 52

[Jason Smith [:jsmith]]

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

Comment 53

[Loli (:lolimartinezcr)]

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