Closed Bug 942788 Opened 12 years ago Closed 12 years ago

OOP frames are not rendered transparently

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3+, firefox28 fixed)

RESOLVED FIXED
blocking-b2g 1.3+
Tracking Status
firefox28 --- fixed

People

(Reporter: timdream, Unassigned)

References

Details

(Keywords: regression)

+++ This bug was initially created as a clone of Bug #941885 +++ Please see attachment 8336808 [details]. This is a very strange bug. When keyboard oop'd, the frame is not rendered transparently. This bug does not reproduce on Unagi ~2 days ago before that build. I've verified this bug has nothing to do with any keyboard frame specific attributes; We simply don't render OOP frames with white background on the new builds.
Another way to reproduce this bug would be: 1. Make a phone call on the phone, wait for the call screen to shown 2. Hang off Expected: 1. The call screen transitions to top while reveal the app below Actual: 1. The call screen transitions to top but the app below is obscured by the white frame.
Note for the regression window - you'll need to enable the keyboard OOP in the developer options to see this bug with the STR in comment 1.
(In reply to Jason Smith [:jsmith] from comment #2) > Note for the regression window - you'll need to enable the keyboard OOP in > the developer options to see this bug with the STR in comment 1. The effect can be seem with call screen on comment 1 without enabling keyboard OOP.
That looks a lot like a unexpected consequence of bug 917416.
QA Contact: gbennett
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #0) > ... > > I've verified this bug has nothing to do with any keyboard frame specific > attributes; We simply don't render OOP frames with white background on the > new builds. BenWa has the details, but I think we may need black background after bug 917416.
Flags: needinfo?(bgirard)
.:First Broken Build:. Environmental Variables: Device: Buri 1.3 mozRIL BuildID: 20131121040202 Gaia: 71063dd91bc8cbb15ba335236ed67a1c5058bd58 Gecko: cf378dddfac8 Version: 28.0a1 Firmware Version: 20131115 .:Last Working Build:. Environmental Variables: Device: Buri 1.3 mozRIL BuildID: 20131120040202 Gaia: c26480b22ce28c812c347290dd4bad090d83db6f Gecko: 4f993fa378eb Version: 28.0a1 Firmware Version: 20131115
It's caused by bug 917416. Well backout.
Depends on: 917416
Flags: needinfo?(bgirard)
I think the real problems is that currently apps relying on being transparent and we shouldn't have them do that. IMO anything that relies on this should block on introducing a good way to ensure that they get transparency. But we will issue a backout for now to be good citizens.
Blocks: 917416
No longer depends on: 917416
(In reply to Benoit Girard (:BenWa) from comment #8) > I think the real problems is that currently apps relying on being > transparent and we shouldn't have them do that. IMO anything that relies on > this should block on introducing a good way to ensure that they get > transparency. But we will issue a backout for now to be good citizens. Thanks. Could it make sense if we do <iframe mozbrowser mozbackgroundtransparent> ?
T(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #9) > Thanks. Could it make sense if we do <iframe mozbrowser > mozbackgroundtransparent> ? This is indeed what will be happen. This bug will be fixed when bug 917416 comment 34 reaches m-c.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocking on the backout.
blocking-b2g: 1.3? → 1.3+
You need to log in before you can comment on or make changes to this bug.