957276 - [B2G][Tech Eva][Distant Orbit] Notifications bar overlaps into game view of Distant Orbit

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect)

Description

[pfield]

Attachment: DistantOrbit1.png

Description:
The notifcations bar overlaps into the game view of distant Orbit. It is immediately noticeable and impedes important dialogue and option menus.

Repro Steps:
1) Updated Buri to Build ID: 20140106004001
2) Navigate to marketplace and download "Distant Orbit."
3) Launch "Distant Orbit" after installation and proceed to play the game.

Actual:
The notifications bar overlaps into the "Distant Orvit" game view.

Expected:
The notifications bar does not overlap into the "Distant Orbit" game view.

Environmental Variables
Device: Buri v 1.3.0 COM RIL
Build ID: 20140106004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/a43cb4b322d3
Gaia: 35a60b82f8cf2d759939a350e2dadbb9d8b2f5dc
Platform Version: 28.0a2
RIL Version: 01.02.00.019.102 

Notes:
Repro frequency: 4/4 100%

See attached: (screenshots)

Occurs in Buri 1.2 latest

Comment 1

[pfield]

Attachment: DistantOrbit2.png

Comment 2

[pfield]

Attachment: DistantOrbit3.png

Comment 3

[pfield]

Environmental Variables
Device: Buri v 1.2.0 Mozilla
Build ID: 20140106004001
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/d552c08a72d0
Gaia: 8441587c3b352e052fee07665c21fd192540f19f
Platform Version: 26.0
RIL Version: 01.02.00.019.102

Comment 4

[Jason Smith [:jsmith]]

What happens on 1.1?

Comment 5

[pfield]

does not occur in latest buri 1.1

Environmental Variables
Device: Buri v 1.1.0 COM RIL 
Build ID: 20140102041202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/bdac595a4e46
Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f
Platform Version: 18.1
RIL Version: 01.01.00.019.281

Comment 6

[Jason Smith [:jsmith]]

My guess is that this is a system app bug.

Comment 7

[Sarah Parsons]

This issue started to occur on the Buri 1.2 Build ID: 20130916040205

Gaia   a0079597d510ce8ea0b9cbb02c506030510b9eeb
SourceStamp c4bcef90cef9
BuildID 20130916040205
Version 26.0a1

Last working Buri 1.2 Build ID: 20130915040205

Gaia   3f51f302c3a0c57d8bad482ec7ee86b2819389fb
SourceStamp 9366ee039645
BuildID 20130915040205
Version 26.0a1

Comment 8

[Gregor Wagner [:gwagner]]

Thanks for the regression range. Can we get a list of bugs in this window?

Comment 9

[Jason Smith [:jsmith]]

https://github.com/mozilla-b2g/gaia/compare/3f51f302c3a0c57d8bad482ec7ee86b2819389fb...a0079597d510ce8ea0b9cbb02c506030510b9eeb

Comment 10

[Jason Smith [:jsmith]]

There's three commits in the Gaia regression range in the System app:

1. https://github.com/mozilla-b2g/gaia/commit/50e3f1392b205428fa90dd17b329ba0c0358be3d
2. https://github.com/mozilla-b2g/gaia/commit/56439c30f4101dd5e4bcd09575ada05a6ef5ac15
3. https://github.com/mozilla-b2g/gaia/commit/327bc39dd806b6e532ddc125c3d7fa8534a92802

[1] is dealing with modal dialogs, which doesn't seem related to this bug. [2] seems unlikely, as it's dealing with the keyboard manager. [3] I'm not sure about.

Alive - What do you think?

Comment 11

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

Does this happen on built-in gallery app and camera app?
Not sure this app app is native fullscreen or requesting fullscreen.

Comment 12

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

I cannot reproduce this on v1.3, gaia commit=96c05def12ed7a9896b23f45398e361a97d2ce0e
Also this app seems neither declare fullscreen in manifest nor request fullscreen in the javascript.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #12)
> I cannot reproduce this on v1.3, gaia
> commit=96c05def12ed7a9896b23f45398e361a97d2ce0e
> Also this app seems neither declare fullscreen in manifest nor request
> fullscreen in the javascript.

Really? I was able to reproduce this fine on master on yesterday's build (1/13/2013).

Comment 14

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #13)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #12)
> > I cannot reproduce this on v1.3, gaia
> > commit=96c05def12ed7a9896b23f45398e361a97d2ce0e
> > Also this app seems neither declare fullscreen in manifest nor request
> > fullscreen in the javascript.
> 
> Really? I was able to reproduce this fine on master on yesterday's build
> (1/13/2013).

Actually build date would be 1/12/2014.

Comment 15

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

Attachment: Distant-Orbit v1.3 latest

Comment 16

[Peter Dolanjski [:pdol]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #12)
> I cannot reproduce this on v1.3, gaia
> commit=96c05def12ed7a9896b23f45398e361a97d2ce0e
> Also this app seems neither declare fullscreen in manifest nor request
> fullscreen in the javascript.

If it is not declaring full screen, is this actually a bug in the OS?

Comment 17

[Sarah Parsons]

I can still repro this issue on the Buri 1.3 Build ID: 20140114004002

Gaia   96c05def12ed7a9896b23f45398e361a97d2ce0e
SourceStamp 29c5b8def408
BuildID 20140114004002
Version 28.0a2

Comment 18

[Jason Smith [:jsmith]]

(In reply to Peter Dolanjski [:pdol] from comment #16)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #12)
> > I cannot reproduce this on v1.3, gaia
> > commit=96c05def12ed7a9896b23f45398e361a97d2ce0e
> > Also this app seems neither declare fullscreen in manifest nor request
> > fullscreen in the javascript.
> 
> If it is not declaring full screen, is this actually a bug in the OS?

Yes. The window manager can determine how web content renders. In this case, we're rendering content fullscreen even though the status bar is still present. This means the top level of piece of web content is cut off & not possible to read.

Comment 19

[Preeti Raghunath(:Preeti)]

Jason

Why do we believe this is a blocker? Seems like 1.2, 1.3 and master are all impacted.

Comment 20

[Jason Smith [:jsmith]]

(In reply to Preeti Raghunath(:Preeti) from comment #19)
> Jason
> 
> Why do we believe this is a blocker? Seems like 1.2, 1.3 and master are all
> impacted.

Because it impacts a preinstalled partner app in a target market & is a regression. We can't ship with a bug like this that would prevent a signoff on ensuring existing partner apps continue to work across releases.

FWIW _ This actually would have blocked 1.2 if we were still tracking bugs there.

Comment 21

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

I still cannot reproduce, deassign myself.

Comment 22

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

Note: v1.3 no matter it's direct fullscreen(request) or indirect fullscreen(manifest) -- both works. I don't know why you get the screen. I believe there's something async. Maybe the game version maybe some STR missed...I have no idea.

If fullscreen does fail, gallery would fail too, but do you get statusbar on gallery?

Comment 23

[Jason Smith [:jsmith]]

Checked this again on today's 1.3 Buri build - I can still reproduce. I'm not seeing what you are seeing on your device. I'm seeing what the screenshots show for the bug.

Here's a couple of ideas we can try:

1. Are you sure you running the latest gecko changes as well? If not, can you flash the latest gecko & gaia changes together on your device?

2. Can you try testing this on a different device with a fresh gecko & gaia build of 1.3?

I'm running out of ideas on why you can't reproduce. My only guess at this point is that your gecko build is out of date.

Comment 24

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

I reproduced in buri device.... What the....

Checking.

Comment 25

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

After looking again I do think this is not a gaia system bug.

Please see the source code of Distant Orbit,
It mistakenly thinks its having 320x480 but it doesn't declare to be fullscreen. So no matter what we do in system, it would still be wrong. This is an app side bug. A normal app only consumes 320 x ( 480 - statusbar) We won't know the app wanna to be 320x480 but the app thinks it's 320x480. It is somewhat weird for an app to hardcode the width and height in its code....

Anyway, I guess it's using screen.innerWidth/screen.innerHeight to know the screen w/h.

So the only solution is declare to be fullscreen.

Please contact the app developer of DO to fix this, just need to specifies the fullscreen: true in manifest.

Thanks.

Comment 26

[Jason Smith [:jsmith]]

Then why isn't this problem showing up in 1.1? We aren't seeing this happen in 1.1 if I recall.

Comment 27

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

No idea. But shouldn't be gaia::system bug. Gecko issue maybe. Or they changed something after v1.1 in app side.

Comment 28

[Jason Smith [:jsmith]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #27)
> No idea. But shouldn't be gaia::system bug. Gecko issue maybe. Or they
> changed something after v1.1 in app side.

Can't be - we're using the same app for testing on 1.1 vs. 1.2.

Comment 29

[Tony Chung [:tchung]]

tagging the right team.

Comment 30

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #28)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #27)
> > No idea. But shouldn't be gaia::system bug. Gecko issue maybe. Or they
> > changed something after v1.1 in app side.
> 
> Can't be - we're using the same app for testing on 1.1 vs. 1.2.

There's also a regression range here present, so this can't be an app bug.

Comment 31

[Jason Smith [:jsmith]]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9366ee039645&tochange=c4bcef90cef9

Comment 32

[Jason Smith [:jsmith]]

If we're thinking this isn't a Gaia System bug per Alive's comment, then the only hunch I've got is that this is a layout regression. There are three layout bugs that landed in this range that's not test related:

* bug 914919
* bug 915526
* bug 916158

I haven't checked yet if the app is using SVG images or not, as bug 902525 is present in the regression range as well.

Roc - Could anything in the layout component cause a regression like this?

Comment 33

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #32)
> If we're thinking this isn't a Gaia System bug per Alive's comment, then the
> only hunch I've got is that this is a layout regression. There are three
> layout bugs that landed in this range that's not test related:
> 
> * bug 914919
> * bug 915526
> * bug 916158
> 
> I haven't checked yet if the app is using SVG images or not, as bug 902525
> is present in the regression range as well.
> 
> Roc - Could anything in the layout component cause a regression like this?

Looks like two of those bugs were backed out, which really leaves bug 915526 as a potential candidate. That bug seems to involve preffing on a new feature.

Comment 34

[Jason Smith [:jsmith]]

Clearing System Platform team flag as Alive's comment seems to imply that this is a gecko regression.

Comment 35

[Timothy Nikkel (:tnikkel)]

(In reply to Jason Smith [:jsmith] from comment #33)
> (In reply to Jason Smith [:jsmith] from comment #32)
> > If we're thinking this isn't a Gaia System bug per Alive's comment, then the
> > only hunch I've got is that this is a layout regression. There are three
> > layout bugs that landed in this range that's not test related:
> > 
> > * bug 914919
> > * bug 915526
> > * bug 916158
> > 
> > I haven't checked yet if the app is using SVG images or not, as bug 902525
> > is present in the regression range as well.
> > 
> > Roc - Could anything in the layout component cause a regression like this?
> 
> Looks like two of those bugs were backed out, which really leaves bug 915526
> as a potential candidate. That bug seems to involve preffing on a new
> feature.

Bug 915526 was changing how a prefed off (at that time) feature worked. It should have had no effect until it was prefed on much later.

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What was the "working" behavior prior to the bug?  That the notification bar was hidden, or that the game view took up a smaller area and didn't overlap under the notification bar?

Comment 37

[Jason Smith [:jsmith]]

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #36)
> What was the "working" behavior prior to the bug?  That the notification bar
> was hidden, or that the game view took up a smaller area and didn't overlap
> under the notification bar?

I'll add qawanted to get more details on this.

QA Wanted - Can we an explanation of the behavior on 1.1? A screenshot & description of the behavior on 1.1 will help here.

Comment 38

[Sarah Parsons]

Attachment: Distant_Orbit_1.1.png

Game displays properly on 1.1 Build ID: 20140123041201 there is no screen cut-off or overlapping. Attached is a screenshot of 3 different views that display properly on 1.1 but in 1.2, and 1.3 the screen top portion of the screen is cut off/being overlapped by the notifications bar. 

Gaia   c434fe9a0e823029796805e141cfa983cda2d246
SourceStamp aa0ceb07a73e
BuildID 20140123041201
Version 18.0

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't see anything obvious in either the gaia or gecko regression windows, so I think this needs a smaller regression range.

Comment 40

[Jason Smith [:jsmith]]

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #39)
> I don't see anything obvious in either the gaia or gecko regression windows,
> so I think this needs a smaller regression range.

We can't do that. We don't have builds that go deeper than a day to allow for bisection down to a changeset on Firefox OS. It's a problem being looked into, but I don't expect this be solved in the short term.

The only idea I've got that could possibly help with isolating the bug here based on our existing tools is to apply a 9/16 build of Gaia on top of a 9/15 gecko build and test this bug. Then, repeat the same process with a 9/15 build of Gaia on top of a 9/16 gecko build. If we see this reproducing in one situation & not the other, then we can probably isolate if this is a Gaia or Gecko bug.

QA Wanted - here's what you need to do:

1. Flash the Gaia build from 9/16 on top of a 9/15 gecko build using the fullflash script. Then, test if you can reproduce this bug.

2. Flash the Gaia build from 9/15 on top of a 9/16 gecko build using the fullflash script. Then, test if you can reproduce this bug.

Comment 41

[Sarah Parsons]

Below are the results from the qawanted request in comment 40:


1. Flash the Gaia build from 9/16 on top of a 9/15 gecko build using the fullflash script.

-This issue did not reproduce Build ID: 20130915040205

Gaia   a0079597d510ce8ea0b9cbb02c506030510b9eeb
SourceStamp 9366ee039645
BuildID 20130915040205
Version 26.0a1

2. Flash the Gaia build from 9/15 on top of a 9/16 gecko build using the fullflash script. 

-This issue does reproduce Build ID: 20130916040205

Gaia   3f51f302c3a0c57d8bad482ec7ee86b2819389fb
SourceStamp c4bcef90cef9
BuildID 20130916040205
Version 26.0a1

Comment 42

[Jason Smith [:jsmith]]

Okay - so comment 41 reinforces Alive's comments above - this is a gecko regression, not a gaia regression.

Comment 43

[Timothy Nikkel (:tnikkel)]

Someone should be able to make custom builds with specific gecko revisions to narrow this down further.

Comment 44

[Andrew Overholt [:overholt]]

(In reply to Timothy Nikkel (:tn) from comment #43)
> Someone should be able to make custom builds with specific gecko revisions
> to narrow this down further.

I said I'd find time to do this but I'm at a work week and my time is more limited than I anticipated it would be.  Also, I only have my laptop with me and builds take a while on it.  Is there any way someone else can whip up a script to loop over the commits in the range and produce device builds for each?

I'll still do this if no one else has the time to do so.

Comment 45

[Andrew Overholt [:overholt]]

I can see the notification bar while the game is running in this b2g desktop build:

http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-15-04-02-05-mozilla-central/

Screencast:

http://people.mozilla.org/~aoverholt/distantorbit-b2gdesktop-2013-09-15.webm

Sarah, are you *not* seeing the notification on an device build from 2013-09-15?

Comment 46

[Sarah Parsons]

No, I can see the notifications bar just fine on the 9/15 build.  

(In reply to Andrew Overholt [:overholt] from comment #45)
> I can see the notification bar while the game is running in this b2g desktop
> build:
> 
> http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-15-04-02-
> 05-mozilla-central/
> 
> Screencast:
> 
> http://people.mozilla.org/~aoverholt/distantorbit-b2gdesktop-2013-09-15.webm
> 
> Sarah, are you *not* seeing the notification on an device build from
> 2013-09-15?

Comment 47

[Andrew Overholt [:overholt]]

(In reply to Sarah Parsons from comment #46)
> No, I can see the notifications bar just fine on the 9/15 build.  

Okay, then I'm confused :)  Before what build did the notifications bar *not* overlap the game content?
 
> (In reply to Andrew Overholt [:overholt] from comment #45)
> > I can see the notification bar while the game is running in this b2g desktop
> > build:
> > 
> > http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-15-04-02-
> > 05-mozilla-central/
> > 
> > Screencast:
> > 
> > http://people.mozilla.org/~aoverholt/distantorbit-b2gdesktop-2013-09-15.webm
> > 
> > Sarah, are you *not* seeing the notification on an device build from
> > 2013-09-15?

Comment 48

[Sarah Parsons]

Please refer to comment 7. The issue started to occur on the 9/16 build. The 9/15 was the last working.

Comment 49

[Andrew Overholt [:overholt]]

(In reply to Sarah Parsons from comment #48)
> Please refer to comment 7. The issue started to occur on the 9/16 build. The
> 9/15 was the last working.

This is the root of my confusion:  on b2g desktop builds from 9/14 [1, 2] and 9/15 [3], I can see the notification bar overlapping the game.

This leads me to believe that on devices (but *not* on b2g desktop builds), one cannot see the notification bar while playing the game.  Can you confirm, please, Sarah?  Thanks and sorry for the back-and-forth.

[1]
http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-14-04-02-02-mozilla-central/

[2]
http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-14-04-12-01-mozilla-b2g18/

[3]
http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-15-04-02-05-mozilla-central/

Comment 50

[Sarah Parsons]

Hi Andrew! 

No worries on the back and forth :) So, I just checked the 9/14 and 9/15 1.2 and I can see the notifications bar while playing the game.  

(In reply to Andrew Overholt [:overholt] from comment #49)
> (In reply to Sarah Parsons from comment #48)
> > Please refer to comment 7. The issue started to occur on the 9/16 build. The
> > 9/15 was the last working.
> 
> This is the root of my confusion:  on b2g desktop builds from 9/14 [1, 2]
> and 9/15 [3], I can see the notification bar overlapping the game.
> 
> This leads me to believe that on devices (but *not* on b2g desktop builds),
> one cannot see the notification bar while playing the game.  Can you
> confirm, please, Sarah?  Thanks and sorry for the back-and-forth.
> 
> [1]
> http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-14-04-02-
> 02-mozilla-central/
> 
> [2]
> http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-14-04-12-
> 01-mozilla-b2g18/
> 
> [3]
> http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-15-04-02-
> 05-mozilla-central/

Comment 51

[Andrew Overholt [:overholt]]

So at this point are we confident that there was ever a time that the notifications didn't overlap the game?

Comment 52

[Jason Smith [:jsmith]]

(In reply to Andrew Overholt [:overholt] from comment #51)
> So at this point are we confident that there was ever a time that the
> notifications didn't overlap the game?

The notifications bar always existed, but the overlap only existed on a 9/16 build or later.

Comment 53

[Andrew Overholt [:overholt]]

I've tried desktop builds from September 14th through 17th and I can't reproduce this issue.  I also can't reproduce it on the current 1.3 (aurora) builds.

My conclusion is that this is device-specific and I don't have a buri device to test this on, sorry.

Comment 54

[Jason Smith [:jsmith]]

This is really weird. Doesn't reproduce on a TCL Soul device & Flame device either running 1.3. But I have confirmed this on Buri 1.3 though.

Can someone check if this reproduces on a Leo device running the latest 1.3 bits?

Comment 55

[Sarah Parsons]

I was able to reproduce this issue on the latest Leo 1.3 Build ID: 20140130004001

Gaia   8defa5bf0cbce290c649e564b7f3ebe708e19b23
SourceStamp 6b12800e0e46
BuildID 20140130004001
Version 28.0a2

Comment 56

[Andrew Overholt [:overholt]]

On David Baron's buri (or hamachi?) this reproduces.  He's running a 1.3 build from last week-ish.  The game appears to be fullscreen but the notification bar overlaps the game.  There is game content right to the bottom of the display which seems to indicate that the game content is being shifted _down_ (with content missing?) when it does not reproduce.

Jet, can you find someone to dig in here?

Comment 57

[Jet Villegas (inactive)]

Timothy, can you have a quick look here? Bug fix 915526 landed in the regression range, and looks related.

Comment 58

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

Timothy has another blocker, so this may take a while.

Comment 59

[Jet Villegas (inactive)]

This should be easy to test with "layout.imagevisibility.enabled"==false

Comment 60

[Timothy Nikkel (:tnikkel)]

The thing is that layout.imagevisibility.enabled was false on b2g when bug 915526 landed.

Comment 61

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #60)
> The thing is that layout.imagevisibility.enabled was false on b2g when bug
> 915526 landed.

Apparently that pref is on now though - http://hg.mozilla.org/mozilla-central/file/1e9f169c9715/b2g/app/b2g.js#l762.

I'll put qawanted to see if this reproduces with that preference set to false just to be sure.

Comment 62

[Jet Villegas (inactive)]

Thanks, Jason. The only other bug I see that looks related (and landed in the regression range) is bug 916112. You can test that by setting "layers.force-tiles" == true

Comment 63

[Matthew Vaughan]

(In reply to Jason Smith [:jsmith] from comment #61)
> (In reply to Timothy Nikkel (:tn) from comment #60)
> > The thing is that layout.imagevisibility.enabled was false on b2g when bug
> > 915526 landed.
> 
> Apparently that pref is on now though -
> http://hg.mozilla.org/mozilla-central/file/1e9f169c9715/b2g/app/b2g.js#l762.
> 
> I'll put qawanted to see if this reproduces with that preference set to
> false just to be sure.

This issue does NOT reproduce for me on the 02/06/14 1.3 build on a Buri with layout.imagevisibility.enabled=false. What I see is exactly what is seen in the image attached by Alive (Distant-Orbit v1.3 latest.jpg). The game's assets appear to properly fit without the status bar overlapping them.

Device: Buri v1.3 MOZ RIL
BuildID: 20140205004002
Gaia: 3405c205cfb5625073b9db1e12ed5d173bdcc78c
Gecko: 2c7f237ba88b
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 64

[Timothy Nikkel (:tnikkel)]

(In reply to Matthew Vaughan from comment #63)
> This issue does NOT reproduce for me on the 02/06/14 1.3 build on a Buri
> with layout.imagevisibility.enabled=false. What I see is exactly what is
> seen in the image attached by Alive (Distant-Orbit v1.3 latest.jpg). The
> game's assets appear to properly fit without the status bar overlapping them.

Paradoxically that implies that bug 915526 did not regress this because layout.imagevisibility.enabled was false when bug 915526 landed.

Since we don't seem to be getting consistent results here it could be that the problem doesn't reproduce consistently, so that if it doesn't reproduce one time does not mean that build is not affected.

Comment 65

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #64)
> (In reply to Matthew Vaughan from comment #63)
> > This issue does NOT reproduce for me on the 02/06/14 1.3 build on a Buri
> > with layout.imagevisibility.enabled=false. What I see is exactly what is
> > seen in the image attached by Alive (Distant-Orbit v1.3 latest.jpg). The
> > game's assets appear to properly fit without the status bar overlapping them.
> 
> Paradoxically that implies that bug 915526 did not regress this because
> layout.imagevisibility.enabled was false when bug 915526 landed.
> 
> Since we don't seem to be getting consistent results here it could be that
> the problem doesn't reproduce consistently, so that if it doesn't reproduce
> one time does not mean that build is not affected.

I don't think it's intermittent - when I reproduce this bug on a device affected, it appears to be 100% reproducible.

Comment 66

[Timothy Nikkel (:tnikkel)]

I finally got my local hamachi builds working and I tested in a local build with layout.imagevisibility.enabled both true and false, in both cases I reproduced the problem. So there must be something else going on here that makes straightforward testing produce conflicting results.

Comment 67

[Timothy Nikkel (:tnikkel)]

I manually backed out bug 915526 and I can still reproduce the problem no matter what layout.imagevisibility.enabled is set to.

Comment 68

[Timothy Nikkel (:tnikkel)]

If I set layers.enable-tiles to true (it was false) then the problem does not happen for me. So that points to bug 916112 as what regressed this.

Comment 69

[Benoit Girard (:BenWa)]

You might want to block this bug on enabling bug instead of that bug.

Comment 70

[Benoit Girard (:BenWa)]

Sorry let me elaborate a bit more. Tiling was turned on very briefly by mistake therefore it should be ignored in a regression window. Tiling is meant speed up rendering not change it. We need to find what really caused the issue with that change excluded.

Comment 71

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

So tiling was enabled in bug 887819 (rev https://hg.mozilla.org/mozilla-central/rev/57a03f46e0b2) on Sept 12, 2013. So presumably this problem was happening on Sept 11 build as well - can we get a regression window prior to that? If it doesn't happen on that build then something else must have landed between the 11th and the 16th that caused the breakage, and we should test those builds with the pref disabled to see what did it.

Comment 72

[Matthew Vaughan]

What I found is that this issue started reproducing on the 09/09/13 1.2 build. The last working build is the 09/06/13 1.2 build. Please note, there are no builds for 09/07 or 09/08. 

However this issue did not reproduce from 09/13 to 09/15, which supports the regression window in comment 7.

**I did not adjust the prefs.js file while testing this issue** 

- Works -
Device: Buri v1.3 MOZ RIL
BuildID: 20130906040204
Gaia: 94e5f269874b02ac0ea796b64ab995fce9efa4b3
Gecko: ab5f29823236
Version: 26.0a1
Firmware Version: V1.2-device.cfg

- Broken -
Device: Buri v1.3 MOZ RIL
BuildID: 20130909114657
Gaia: aa4180e9286d385fa6b62d236f30fb24cd8b93e9
Gecko: 218d4334d29e
Version: 26.0a1
Firmware Version: V1.2-device.cfg

Comment 73

[Timothy Nikkel (:tnikkel)]

If anyone wants to wade through the changes in that range:
gaia
https://github.com/mozilla-b2g/gaia/compare/94e5f269874b02ac0ea796b64ab995fce9efa4b3...aa4180e9286d385fa6b62d236f30fb24cd8b93e9
gecko
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab5f29823236&tochange=218d4334d29e

Comment 74

[Jason Smith [:jsmith]]

Let's isolate comment 72's regression range to determine if it's gaia or gecko again. Do the following:

1. Test this bug on a 9/9 Gaia build on top of a 9/6 Gecko build.
2. Test this bug on a 9/6 Gaia build on top of a 9/9 Gecko build.

Comment 75

[Matthew Vaughan]

(In reply to Jason Smith [:jsmith] from comment #74)
> Let's isolate comment 72's regression range to determine if it's gaia or
> gecko again. Do the following:
> 
> 1. Test this bug on a 9/9 Gaia build on top of a 9/6 Gecko build.

After performing this test, the issue does NOT reproduce.

> 2. Test this bug on a 9/6 Gaia build on top of a 9/9 Gecko build.

After performing this test, Firefox OS crashes.

Comment 76

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

So sounds like a Gecko issue, then. My money's on bug 913205.

Comment 77

[Jason Smith [:jsmith]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #76)
> So sounds like a Gecko issue, then. My money's on bug 913205.

Can someone spin a local build with this patch backed out to verify this?

Comment 78

[Timothy Nikkel (:tnikkel)]

(In reply to Jason Smith [:jsmith] from comment #77)
> (In reply to Kartikaya Gupta (email:[e-mail]) from comment #76)
> > So sounds like a Gecko issue, then. My money's on bug 913205.
> 
> Can someone spin a local build with this patch backed out to verify this?

I did this, problem still exists.

Comment 79

[Timothy Nikkel (:tnikkel)]

Setting layers.use-deprecated-textures to true the problem goes away for me. This suggests bug 907745.

Comment 80

[Timothy Nikkel (:tnikkel)]

(In reply to Timothy Nikkel (:tn) from comment #79)
> Setting layers.use-deprecated-textures to true the problem goes away for me.
> This suggests bug 907745.

I tried testing again to make sure, and I saw the same thing. Then I rebooted the phone, and the problem returned. So it seems that while this does have some affect, there must be more at play here.

Comment 81

[Timothy Nikkel (:tnikkel)]

Removing
  pref("gfx.canvas.azure.backends", "skia");
  pref("gfx.canvas.azure.accelerated", true);
from b2g/app/b2g.js seems to fix the problem reliably. => bug 905227

Comment 82

[Jason Smith [:jsmith]]

Looks like this is a regression from Skia GL.

Milan - Can we get an assignee for this bug?

Comment 83

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

So, either a bug in SkiaGL canvas, or SkiaGL is exposing a bug in the game itself, or...?

Comment 84

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

Courtesy of random.org, I randomly pick snorp to answer this needinfo or hand it off to somebody else. Because otherwise everybody's gonna think somebody else will do it and nobody will.

Comment 85

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Milan Sreckovic [:milan] from comment #83)
> So, either a bug in SkiaGL canvas, or SkiaGL is exposing a bug in the game
> itself, or...?

Not sure...I can't seem to reproduce on hamachi using either 1.3 or master...

Comment 86

[Jason Smith [:jsmith]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #85)
> (In reply to Milan Sreckovic [:milan] from comment #83)
> > So, either a bug in SkiaGL canvas, or SkiaGL is exposing a bug in the game
> > itself, or...?
> 
> Not sure...I can't seem to reproduce on hamachi using either 1.3 or master...

Weird - I was able to reproduce originally, but I can't reproduce on 1.4 anymore either.

Comment 87

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #86)
> (In reply to James Willcox (:snorp) ([e-mail]) from comment #85)
> > (In reply to Milan Sreckovic [:milan] from comment #83)
> > > So, either a bug in SkiaGL canvas, or SkiaGL is exposing a bug in the game
> > > itself, or...?
> > 
> > Not sure...I can't seem to reproduce on hamachi using either 1.3 or master...
> 
> Weird - I was able to reproduce originally, but I can't reproduce on 1.4
> anymore either.

On 1.3 however - I was able to reproduce this bug on yesterday's 1.3 build. Let me flag qawanted here for confirmation.

Comment 88

[pfield]

Confirmed that this issue does occur on Buri 1.3

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140212004003
Gaia: ce17d5eae7b1893ae4397c814b10ae598fcbdb58
Gecko: ab07e61c2eb0
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 89

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Jason Smith [:jsmith] from comment #87)
> (In reply to Jason Smith [:jsmith] from comment #86)
> > (In reply to James Willcox (:snorp) ([e-mail]) from comment #85)
> > > (In reply to Milan Sreckovic [:milan] from comment #83)
> > > > So, either a bug in SkiaGL canvas, or SkiaGL is exposing a bug in the game
> > > > itself, or...?
> > > 
> > > Not sure...I can't seem to reproduce on hamachi using either 1.3 or master...
> > 
> > Weird - I was able to reproduce originally, but I can't reproduce on 1.4
> > anymore either.
> 
> On 1.3 however - I was able to reproduce this bug on yesterday's 1.3 build.
> Let me flag qawanted here for confirmation.

Where do I get these builds? I tried a while back and the wiki had outdated or wrong information...

Comment 90

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

I can still repro on 1.3. If you don't want to build 1.3 yourself you can find recent builds at https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-b2g28_v1_3-hamachi-eng/

Comment 91

[James Willcox (:snorp) ([e-mail]) (he/him)]

Alright, I can repro with 1.3 tinderbox, but not with my own build. Weird.

Comment 92

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

I discussed with snorp over IRC. I'll do some initial investigation here to see if I can narrow down the cause a bit, and hand it to him if it is SkiaGL-related.

Comment 93

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

George, can you jump in here if :snorp doesn't have time?

Comment 94

[George Wright (:gw280) (needinfo me!)]

Sure, I can investigate.

Comment 95

[Sotaro Ikeda [:sotaro]]

Attachment: logcat by adding manual logs

Get logcat by adding manual log around HwcComposer2D::PrepareLayerList() and enable "dumps.layer" log.

Comment 96

[Sotaro Ikeda [:sotaro]]

From attachment 8378449 [details], it seems that a Layer side does not provide correct visible region with Layer::GetEffectiveVisibleRegion().

Comment 97

[Sotaro Ikeda [:sotaro]]

It seems that we need to deliver ContainerLayer's visibility info in calculating HwcList(hwc_display_contents_1_t) in HwcComposer2D::PrepareLayerList().

http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#220

Comment 98

[Sotaro Ikeda [:sotaro]]

Comment 97 was incorrect. ContainerLayer's visibility info is already used for calculation.

Comment 99

[Sotaro Ikeda [:sotaro]]

Attachment: logcat by adding manual logs

Add more logs.

Comment 100

[Sotaro Ikeda [:sotaro]]

Attachment: logcat by adding manual logs

Comment 101

[Sotaro Ikeda [:sotaro]]

At first, I thought it is related to layer. But from attachment 8378538 [details], it seems to be a problem around hw composer. "Distant Orbit" allocates (480 * 320) size canvas. And the game area's size is (460*320). This rendering is not handled correctly somewhare. I am going to reconfirm around HwcList(hwc_display_contents_1_t).

Comment 102

[Sotaro Ikeda [:sotaro]]

In OpenGL rendering, the canvas size does not fit to screen size, the rendering result is shifted down. But on hw composer case, rendering result seems to shifted up.

Comment 103

[Sotaro Ikeda [:sotaro]]

hw composer's act in Comment 102 seems qcom hw composer's characteristic. Though, it is not clear yet.

Comment 104

[Sotaro Ikeda [:sotaro]]

Attachment: patch for b2g v1.3 - Do not use hw composer when bufferRect is bigger than clip

This could fix the problem. I am not sure that we could have a better fix.

Comment 105

[Sotaro Ikeda [:sotaro]]

Diego, do you know if hw composer can render as same as OpenGL compositaion in Comment 102 case.

Comment 106

[Sotaro Ikeda [:sotaro]]

In HwcUtils::PrepareLayerRects(), aClip is (0, 20 ,320 ,460) and aBufferRect is (0, 0, 320 ,480) for the canvas. PrepareLayerRects() seems to expect aBufferRect is in display aBufferRect. So, aBufferRect need to be (0, 20, 320 ,480) from PrepareLayerRects() point of view.

Comment 107

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #106)
> PrepareLayerRects() seems to expect aBufferRect is in display aBufferRect.

Correction:
PrepareLayerRects() seems to expect aBufferRect is in display coordinate.

Comment 108

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8378603 [details] [diff] [review]
patch for b2g v1.3 - Do not use hw composer when bufferRect is bigger than clip

This is not a correct fix for the bug. Obsolete it.

Comment 109

[Sushil]

Is it reproducible on JB gonk based device (v1.3) or ICS based device (v1.2) ? Does it happen with GPU Composition also ? Please confirm.

Comment 110

[Sushil]

Sotaro,

Can you please check "visibleRect" and if "state.mHasOwnOffset" is TRUE for this particular layer. Can I get access to this App to reproduce the issue on my device ? I suspect LayerRenderState in this App:
LayerRenderState state = aLayer->GetRenderState();

Comment 111

[Sotaro Ikeda [:sotaro]]

Attachment: logcat by adding manual logs

Updated the logcat.

Comment 112

[Sotaro Ikeda [:sotaro]]

Sushil, I updated the logcat. Yeah, "state.mHasOwnOffset" was TRUE. You can get the app from Firefox Marketplace.

Comment 113

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #112)
> Sushil, I updated the logcat. Yeah, "state.mHasOwnOffset" was TRUE. You can
> get the app from Firefox Marketplace.

Correction:
Sorry, about the canvas layer. the offeset was false

Comment 114

[Sotaro Ikeda [:sotaro]]

Attachment: logcat by adding manual logs

Fix some logs.

Comment 115

[Sotaro Ikeda [:sotaro]]

(In reply to Sushil from comment #109)
> Is it reproducible on JB gonk based device (v1.3) or ICS based device (v1.2)
> ? Does it happen with GPU Composition also ? Please confirm.

I do not know about it. I have a nexus-4 and nexus-7 as JB device. But the app can not render by hw composer on them. They does not support color layer. It seems to affected to it.

Comment 116

[Sotaro Ikeda [:sotaro]]

(In reply to Sushil from comment #109)
> Does it happen with GPU Composition also ? Please confirm.

It happens only on hw composer rendering.

Comment 117

[Sotaro Ikeda [:sotaro]]

By fixing the logcat attachment 8379160 [details], HwcList(hwc_display_contents_1_t) seems to be set almost correct.

Comment 118

[Sushil]

Sotaro,

Thanks for updating new logs. As per your logs, Source crop and destination rectangle are correctly set by PrepareLayerRects():

HwcUtils::PrepareLayerRects()_E
HwcUtils::PrepareLayerRects() 1 aVisible.x 0 aVisible.y 0 aVisible.width 320 aVisible.height 480
HwcUtils::PrepareLayerRects() 2 aClip.x 0 aClip.y 20 aClip.width 320 aClip.height 460
HwcUtils::PrepareLayerRects() 3 aBufferRect.x 0 aBufferRect.y 0 aBufferRect.width 320 aBufferRect.height 480
-------------------------------------------
HwcUtils::PrepareLayerRects() 4 aSourceCrop->left 0 aSourceCrop->top 1 aSourceCrop->right 320 aSourceCrop->bottom 461
HwcUtils::PrepareLayerRects() 5 aVisibleRegionScreen->left 0 aVisibleRegionScreen->top 20 aVisibleRegionScreen->right 320 aVisibleRegionScreen->bottom 480
-------------------------------------------
HwcUtils::PrepareLayerRects()_X

So source crop of buffer is [0 1 320 461] and dest = [0 20 320 480] which means source buffer is being rendered from its almost top left and at correct destination rectangle so there is no chance of overlapping with Navigation Bar. Can you just try to skip Color layer on your device and try to reproduce the issue on your device. My point is, with these logs, issue should not be seen. If you are able to reproduce by skipping Color layers so that it uses HWC, we can dump layer buffer handles.

My other suspect is LayerRenderState so I checked similar use case which is "Crystal Skull" app on my device. The difference is "aVisible" and "aBufferRect" which depends on "state.mSize.width" and "state.mSize.height". See log:

HWComposer: state.mHasOwnOffset is FALSE
HWCutils: PrepareLayerRects: aVisible=[0 0 320 513] aClip=[0 30 480 770] aBufferRect=[0 0 320 513]
HWCutils: PrepareLayerRects: aSourceCrop=[0 0 320 513] aVisibleRegionScreen=[0 30 480 800]
HWComposer: HWC layer[1]::CanvasLayerComposite: dst=[0 30 480 800] src=[0 0 320 513] Tr=2 Blending=0x105 Flags=0x0

Comment 119

[Sotaro Ikeda [:sotaro]]

Crystal skull correctly adjust the canvas size. The following is the related log out of "Crystal Skull".

------------------------------------
02-20 12:14:36.649   135   303 I GonkGfx : HwcUtils::PrepareLayerRects()_E
02-20 12:14:36.649   135   303 I GonkGfx : HwcUtils::PrepareLayerRects() 1 aVisible.x 0 aVisible.y 0 aVisible.width 320 aVisible.height 460
02-20 12:14:36.649   135   303 I GonkGfx : HwcUtils::PrepareLayerRects() 2 aClip.x 0 aClip.y 20 aClip.width 320 aClip.height 460
02-20 12:14:36.649   135   303 I GonkGfx : HwcUtils::PrepareLayerRects() 3 aBufferRect.x 0 aBufferRect.y 0 aBufferRect.width 320 aBufferRect.height 460
02-20 12:14:36.649   135   303 I GonkGfx : HwcUtils::PrepareLayerRects() 4 aSourceCrop->left 0 aSourceCrop->top 0 aSourceCrop->right 320 aSourceCrop->bottom 460
02-20 12:14:36.649   135   303 I GonkGfx : HwcUtils::PrepareLayerRects() 5 aVisibleRegionScreen->left 0 aVisibleRegionScreen->top 20 aVisibleRegionScreen->right 320 aVisibleRegionScreen->bottom 480
02-20 12:14:36.649   135   303 I GonkGfx : HwcUtils::PrepareLayerRects()_X

Comment 120

[Sushil]

I checked "Distant Orbit" App on reference v1.3 device but I do not see the overlapping issue in any frame of the App. Frames are being rendered by HWC always. Here is layer configuration of a frame:

HWComposer: state.mHasOwnOffset is TRUE
HWCutils: PrepareLayerRects: aVisible=[0 0 480 800] aClip=[0 0 480 800] aBufferRect=[0 0 480 800]
HWCutils: PrepareLayerRects: aSourceCrop=[0 0 480 800] aVisibleRegionScreen=[0 0 480 800]
HWComposer: HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0 0 480 800] Tr=0 Blending=0x100 Flags=0x40

E HWComposer: state.mHasOwnOffset is TRUE
HWCutils: PrepareLayerRects: aVisible=[0 0 480 770] aClip=[0 30 480 770] aBufferRect=[0 0 480 770]
HWCutils: PrepareLayerRects: aSourceCrop=[0 0 480 770] aVisibleRegionScreen=[0 30 480 800]
HWComposer: HWC layer[1]::ThebesLayerComposite: dst=[0 30 480 800] src=[0 0 480 770] Tr=0 Blending=0x100 Flags=0x40

HWComposer: state.mHasOwnOffset is FALSE
HWCutils: PrepareLayerRects: aVisible=[0 0 320 480] aClip=[0 30 480 770] aBufferRect=[0 0 320 480]
HWCutils: PrepareLayerRects: aSourceCrop=[0 0 320 480] aVisibleRegionScreen=[0 30 480 750]
02-20 12:55:28.187   294   865 E HWComposer: HWC layer[2]::CanvasLayerComposite: dst=[0 30 480 750] src=[0 0 320 480] Tr=2 Blending=0x105 Flags=0x0
HWComposer: Frame rendered

Comment 121

[Sushil]

Please check if there are any kernel errors on a device on which it is reproduced. Here is command:
adb root
adb shell cat /proc/kmsg

Comment 122

[Sotaro Ikeda [:sotaro]]

Attachment: /proc/kmsg

Comment 123

[Sotaro Ikeda [:sotaro]]

attachment 8379281 [details] is a kmsg log. There seems no kernel errors. I saw the same symptom also on leo device. So, it might be ICS_STRAWBERRY common problem.

Comment 124

[Sotaro Ikeda [:sotaro]]

The problem seems to happen only to GL rendered Canvas Layer. By watching attachment 8379160 [details], I noticed that the gralloc buffers are always "Y Flipped". I assume that the problem seems to happen when the gralloc buffers are "Y Flipped" and cropped.

Comment 125

[Sotaro Ikeda [:sotaro]]

> HWComposer: state.mHasOwnOffset is FALSE
> HWCutils: PrepareLayerRects: aVisible=[0 0 320 480] aClip=[0 30 480 770]
> aBufferRect=[0 0 320 480]
> HWCutils: PrepareLayerRects: aSourceCrop=[0 0 320 480]
> aVisibleRegionScreen=[0 30 480 750]
> 02-20 12:55:28.187   294   865 E HWComposer: HWC
> layer[2]::CanvasLayerComposite: dst=[0 30 480 750] src=[0 0 320 480] Tr=2
> Blending=0x105 Flags=0x0
> HWComposer: Frame rendered

From the above, when reference v1.3 device is used, crop seems not happen on canvas layser. So, the following seems not happens.
 - "Y Flipped" and cropped

Comment 126

[Sotaro Ikeda [:sotaro]]

Sushil, can you confirm if the following gralloc buffers are rendered correctly.
 - "Y Flipped" and cropped

Comment 127

[Sushil]

Yes, this problem is specific to Y-Flip and cropping. I hacked my reference v1.3 device to reproduce the problem. After PrepareLayerRects() call, if we set crop like this, then I can see the issue:

    if (strcmp(aLayer->Name(), "CanvasLayerComposite") == 0) {
        hwcLayer.sourceCrop.left = 0;
        hwcLayer.sourceCrop.top = 1;
        hwcLayer.sourceCrop.right = 320;
        hwcLayer.sourceCrop.bottom = 461;
    }

But if I change it to like this, then I do not see the issue:
    if (strcmp(aLayer->Name(), "CanvasLayerComposite") == 0) {
        hwcLayer.sourceCrop.left = 0;
        hwcLayer.sourceCrop.top = 20;
        hwcLayer.sourceCrop.right = 320;
        hwcLayer.sourceCrop.bottom = 480;
    }

It means driver fetch the cropped data first and then do Vertical Flip. This means sourceCrop.bottom needs to be set correctly in this particular case. So it should be:
[0 20 320 480] - Crop needs to be set properly.
OR
[0 0 320 480] - No crop needed, as per observation on v1.3 reference device (issue is not observed, Comment 120). So image is scaled up / down based on destination.


So we need to track where the crop is being calculated in PrepareLayerRects(). This is the code and most of it depends on Transform matrix and aClip:

    gfxRect visibleRectScreen = aTransform.TransformBounds(visibleRect);
    // |clip| is guaranteed to be integer
    visibleRectScreen.IntersectRect(visibleRectScreen, clip);

    if (visibleRectScreen.IsEmpty()) {
        LOGD("Skip layer");
        return false;
    }

    gfxMatrix inverse(aTransform);
    inverse.Invert();
    gfxRect crop = inverse.TransformBounds(visibleRectScreen);

    //clip to buffer size
    crop.IntersectRect(crop, aBufferRect);


Or the sequence in which driver is doing operation is causing this issue. If that is the case, then we should have seen this issue in lot of other use cases also. So I think we need to set crop correctly.

Comment 129

[Sotaro Ikeda [:sotaro]]

I am going steal this bug.

Comment 130

[Sotaro Ikeda [:sotaro]]

By locally changing the code around PrepareLayerRects(), I confirmed the fix. It is still dirty fix.

Comment 132

[Preeti Raghunath(:Preeti)]

Sotaro,

What is the risk associated with the "dirty fix"?

What testing can be done to mitigate the risk?

Comment 133

[Preeti Raghunath(:Preeti)]

Sorry forgot the ni

Comment 134

[Sotaro Ikeda [:sotaro]]

(In reply to Preeti Raghunath(:Preeti) from comment #132)
> Sotaro,
> 
> What is the risk associated with the "dirty fix"?

Dirty fix just mean just that is not good to review. When I wrote it, I did not understand well about the relationship between Y flip and transform. The patch change only how to render Y flipped buffers. It affect only to Canvas 2d and WebGL.

> What testing can be done to mitigate the risk?

It can be tested by "Distant Orbit" and "Sand Trap".

Comment 135

[Sotaro Ikeda [:sotaro]]

Attachment: patch for v1.3 - Fix YFlipped buffer's source crop

When buffers are rendered by YFlipped, their source crop need to be calculated based on YFlipped coordinate. It is orthogonal to transform matrix.

Comment 136

[Sotaro Ikeda [:sotaro]]

Attachment: patch for master - Fix YFlipped buffer's source crop (r=sushil)

A patch for master. Carry "r=sushil".

Comment 137

[Sotaro Ikeda [:sotaro]]

Attachment: patch for v1.3 - Fix YFlipped buffer's source crop (r=sushil)

Committable patch. Carry "r=sushil".

Comment 138

[Sotaro Ikeda [:sotaro]]

https://hg.mozilla.org/integration/b2g-inbound/rev/d71bff9f01a3

Comment 139

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/d71bff9f01a3

Comment 140

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8380175 [details] [diff] [review]
patch for v1.3 - Fix YFlipped buffer's source crop (r=sushil)

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
User impact if declined: contents using canbas2d and WebGL do not rendered in correct position on hw composer rendering.
Testing completed:  Tested in local
Risk to taking this patch (and alternatives if risky):  Low
String or UUID changes made by this patch:  None

Comment 141

[Salem Elkabule]

This issue is fixed in Buri V1.4 Mozilla RIL
 
Environmental Variables:
Device: Buri V1.4 Mozilla RIL
Build ID: 20140225040205
Gecko: https://hg.mozilla.org/mozilla-central/rev/e3daaa4c73dd
Gaia: e0f39c7179c8b297326c0e2313950610be1f5c52
Platform Version: 30.0a1
Firmware Version: V1.2-device.cfg

The notifications bar does not overlap into the "Distant Orbit" game view.

Comment 142

[cmtalbert]

Removing verifyme keyword, as the bug appears to have been verified in comment 141.

Comment 143

[cmtalbert]

Oops, Bhavana did you want this verified on 1.3? (The verification was done on 1.4).

Comment 144

[bhavana bajaj [:bajaj]]

(In reply to Clint Talbert ( :ctalbert ) from comment #143)
> Oops, Bhavana did you want this verified on 1.3? (The verification was done
> on 1.4).

Thanks Clint. I think the 1.4 verification atleast confirms the fix and unblocks the landing on v1.3. If we have QA bandwidth to verify this on 1.3 builds post branch landing, It would be great :)

Comment 145

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/65a6b2103fc5

Comment 146

[cmtalbert]

kevin, would you mind also finding someone to verify this on the 1.3 branch now that it has landed there?

Once verified, they can set the status-b2g-v1.3 tracking flag to "verified".

Thanks,

Clint

Comment 147

[J Zimbrick]

Just checked this on the latest Buri 1.3 build.

This issue appears to be fixed in this branch, the notification bar is visible but does not overlap any game UI elements.

1.3 Environmental Variables:
Device: Buri
BuildID: 20140228004002
Gaia: 9e439c98a05bde90b571701ef0b2dbb4249ef196
Gecko: 7fb42ba60248
Version: 28.0
Base Image: V1.2-device.cfg

Updating 1.3 tracking flag and removing verifyme tag.