Closed Bug 957276 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: Graphics: Layers, defect)

26 Branch
ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla30
blocking-b2g 1.3+
Tracking Status
firefox28 --- wontfix
firefox29 --- wontfix
firefox30 --- fixed
b2g-v1.2 --- wontfix
b2g-v1.3 --- verified
b2g-v1.3T --- fixed
b2g-v1.4 --- verified

People

(Reporter: pfield, Assigned: sotaro)

References

Details

(Keywords: regression, Whiteboard: dogfood1.3)

Attachments

(9 files, 6 obsolete files)

17.58 KB, image/png
Details
29.01 KB, image/png
Details
22.77 KB, image/png
Details
230.78 KB, image/jpeg
Details
83.45 KB, image/png
Details
494.56 KB, text/plain
Details
4.88 KB, text/plain
Details
3.72 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
3.80 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
Attached image 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
Attached image DistantOrbit2.png
Attached image DistantOrbit3.png
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
What happens on 1.1?
Flags: needinfo?(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
Flags: needinfo?(pfield)
QA Contact: sparsons
My guess is that this is a system app bug.
Component: Preinstalled B2G Apps → Gaia::System
Product: Tech Evangelism → Firefox OS
blocking-b2g: --- → 1.3?
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
Thanks for the regression range. Can we get a list of bugs in this window?
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?
Flags: needinfo?(alive)
Does this happen on built-in gallery app and camera app?
Not sure this app app is native fullscreen or requesting fullscreen.
Assignee: nobody → alive
Flags: needinfo?(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.
(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).
(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.
(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?
Flags: needinfo?
I can still repro this issue on the Buri 1.3 Build ID: 20140114004002

Gaia   96c05def12ed7a9896b23f45398e361a97d2ce0e
SourceStamp 29c5b8def408
BuildID 20140114004002
Version 28.0a2
Flags: needinfo?
Keywords: qawanted
Flags: needinfo?
(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.
Flags: needinfo?
Jason

Why do we believe this is a blocker? Seems like 1.2, 1.3 and master are all impacted.
Flags: needinfo?(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.
Flags: needinfo?(jsmith)
blocking-b2g: 1.3? → 1.3+
I still cannot reproduce, deassign myself.
Assignee: alive → nobody
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?
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.
Flags: needinfo?(alive)
I reproduced in buri device.... What the....

Checking.
Assignee: nobody → alive
Flags: needinfo?(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.
Assignee: alive → nobody
Component: Gaia::System → General
Then why isn't this problem showing up in 1.1? We aren't seeing this happen in 1.1 if I recall.
Flags: needinfo?(alive)
No idea. But shouldn't be gaia::system bug. Gecko issue maybe. Or they changed something after v1.1 in app side.
Flags: needinfo?(alive)
(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.
tagging the right team.
Whiteboard: dogfood1.3 → dogfood1.3, [System-Platform]
(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.
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?
Component: General → Layout
Flags: needinfo?(roc)
Product: Firefox OS → Core
Version: unspecified → 26 Branch
(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.
Clearing System Platform team flag as Alive's comment seems to imply that this is a gecko regression.
Whiteboard: dogfood1.3, [System-Platform] → dogfood1.3
(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.
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?
(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.
Flags: needinfo?(roc)
Keywords: qawanted
Attached image 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
Keywords: qawanted
I don't see anything obvious in either the gaia or gecko regression windows, so I think this needs a smaller regression range.
(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.
QA Contact: sparsons
QA Contact: sparsons
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
Keywords: qawanted
Okay - so comment 41 reinforces Alive's comments above - this is a gecko regression, not a gaia regression.
Someone should be able to make custom builds with specific gecko revisions to narrow this down further.
(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.
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?
Flags: needinfo?(sparsons)
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?
Flags: needinfo?(sparsons)
(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?
Flags: needinfo?(sparsons)
Please refer to comment 7. The issue started to occur on the 9/16 build. The 9/15 was the last working.
Flags: needinfo?(sparsons)
(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/
Flags: needinfo?(sparsons)
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/
Flags: needinfo?(sparsons)
So at this point are we confident that there was ever a time that the notifications didn't overlap the game?
(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.
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.
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?
Keywords: qawanted
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
Keywords: qawanted
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?
Flags: needinfo?(bugs)
Timothy, can you have a quick look here? Bug fix 915526 landed in the regression range, and looks related.
Flags: needinfo?(bugs) → needinfo?(tnikkel)
Timothy has another blocker, so this may take a while.
Whiteboard: dogfood1.3 → dogfood1.3, [ETA: 2/21]
This should be easy to test with "layout.imagevisibility.enabled"==false
Flags: needinfo?(jsmith)
The thing is that layout.imagevisibility.enabled was false on b2g when bug 915526 landed.
(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.
Flags: needinfo?(jsmith)
Keywords: qawanted
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
(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
Keywords: qawanted
(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.
(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.
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.
I manually backed out bug 915526 and I can still reproduce the problem no matter what layout.imagevisibility.enabled is set to.
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.
Flags: needinfo?(tnikkel)
You might want to block this bug on enabling bug instead of that bug.
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.
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.
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
QA Contact: sparsons → mvaughan
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.
Keywords: qawanted
(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.
Keywords: qawanted
So sounds like a Gecko issue, then. My money's on bug 913205.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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?
(In reply to Jason Smith [:jsmith] from comment #77)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Setting layers.use-deprecated-textures to true the problem goes away for me. This suggests bug 907745.
Component: Layout → Graphics: Layers
(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.
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
Blocks: 905277
No longer blocks: 916112
Blocks: 905227
No longer blocks: 905277
Looks like this is a regression from Skia GL.

Milan - Can we get an assignee for this bug?
Flags: needinfo?(milan)
So, either a bug in SkiaGL canvas, or SkiaGL is exposing a bug in the game itself, or...?
Flags: needinfo?(snorp)
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(milan)
Flags: needinfo?(gwright)
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.
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(gwright)
(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...
Flags: needinfo?(snorp)
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.
(In reply to Jason Smith [:jsmith] from comment #86)
> (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.
Keywords: qawanted
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
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #87)
> (In reply to Jason Smith [:jsmith] from comment #86)
> > (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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...
Alright, I can repro with 1.3 tinderbox, but not with my own build. Weird.
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.
Assignee: nobody → bugmail.mozilla
George, can you jump in here if :snorp doesn't have time?
Flags: needinfo?(gwright)
Sure, I can investigate.
Flags: needinfo?(gwright)
Assignee: bugmail.mozilla → gwright
Attached file logcat by adding manual logs (obsolete) —
Get logcat by adding manual log around HwcComposer2D::PrepareLayerList() and enable "dumps.layer" log.
From attachment 8378449 [details], it seems that a Layer side does not provide correct visible region with Layer::GetEffectiveVisibleRegion().
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 97 was incorrect. ContainerLayer's visibility info is already used for calculation.
Attached file logcat by adding manual logs (obsolete) —
Add more logs.
Attached file logcat by adding manual logs (obsolete) —
Attachment #8378449 - Attachment is obsolete: true
Attachment #8378519 - Attachment is obsolete: true
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).
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.
hw composer's act in Comment 102 seems qcom hw composer's characteristic. Though, it is not clear yet.
This could fix the problem. I am not sure that we could have a better fix.
Diego, do you know if hw composer can render as same as OpenGL compositaion in Comment 102 case.
Flags: needinfo?(dwilson)
Attachment #8378603 - Attachment description: patch - Do not use hw composer when bufferRect is bigger than clip → patch for b2g v1.3 - Do not use hw composer when bufferRect is bigger than clip
Flags: needinfo?(dwilson)
Flags: needinfo?(sushilchauhan)
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.
(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 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.
Attachment #8378603 - Attachment is obsolete: true
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.
Flags: needinfo?(sushilchauhan)
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();
Flags: needinfo?(sotaro.ikeda.g)
Attached patch logcat by adding manual logs (obsolete) — Splinter Review
Updated the logcat.
Flags: needinfo?(sotaro.ikeda.g)
Sushil, I updated the logcat. Yeah, "state.mHasOwnOffset" was TRUE. You can get the app from Firefox Marketplace.
(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
Fix some logs.
Attachment #8378538 - Attachment is obsolete: true
Attachment #8379140 - Attachment is obsolete: true
(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.
(In reply to Sushil from comment #109)
> Does it happen with GPU Composition also ? Please confirm.

It happens only on hw composer rendering.
By fixing the logcat attachment 8379160 [details], HwcList(hwc_display_contents_1_t) seems to be set almost correct.
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
Flags: needinfo?(sotaro.ikeda.g)
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
Flags: needinfo?(sotaro.ikeda.g)
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
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
Attached file /proc/kmsg
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.
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.
> 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
Sushil, can you confirm if the following gralloc buffers are rendered correctly.
 - "Y Flipped" and cropped
Flags: needinfo?(sushilchauhan)
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.
Flags: needinfo?(sushilchauhan) → needinfo?(sotaro.ikeda.g)
Duplicate of this bug: 966447
I am going steal this bug.
Assignee: gwright → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
By locally changing the code around PrepareLayerRects(), I confirmed the fix. It is still dirty fix.
Duplicate of this bug: 966447
Sotaro,

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

What testing can be done to mitigate the risk?
Sorry forgot the ni
Flags: needinfo?(sotaro.ikeda.g)
(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".
Flags: needinfo?(sotaro.ikeda.g)
When buffers are rendered by YFlipped, their source crop need to be calculated based on YFlipped coordinate. It is orthogonal to transform matrix.
Attachment #8380002 - Flags: review?(sushilchauhan)
Attachment #8380002 - Attachment description: patch - Fix YFlipped buffer's source crop → patch for v1.3 - Fix YFlipped buffer's source crop
Attachment #8380002 - Flags: review?(sushilchauhan) → review+
A patch for master. Carry "r=sushil".
Attachment #8380169 - Flags: review+
Committable patch. Carry "r=sushil".
Attachment #8380002 - Attachment is obsolete: true
Attachment #8380175 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/d71bff9f01a3
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
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
Attachment #8380175 - Flags: approval-mozilla-b2g28?
Keywords: verifyme
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.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Removing verifyme keyword, as the bug appears to have been verified in comment 141.
Keywords: verifyme
Oops, Bhavana did you want this verified on 1.3? (The verification was done on 1.4).
Flags: needinfo?(bbajaj)
(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 :)
Flags: needinfo?(bbajaj)
Attachment #8380175 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
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
Flags: needinfo?(ktucker)
Keywords: verifyme
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.
Flags: needinfo?(ktucker)
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.