Closed
Bug 942788
Opened 12 years ago
Closed 12 years ago
OOP frames are not rendered transparently
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(blocking-b2g:1.3+, 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.
Reporter | ||
Comment 1•12 years ago
|
||
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.
Comment 2•12 years ago
|
||
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.
Reporter | ||
Comment 3•12 years ago
|
||
(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.
Comment 4•12 years ago
|
||
That looks a lot like a unexpected consequence of bug 917416.
Comment 5•12 years ago
|
||
(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
Keywords: regressionwindow-wanted
Comment 7•12 years ago
|
||
It's caused by bug 917416. Well backout.
Depends on: 917416
Flags: needinfo?(bgirard)
Comment 8•12 years ago
|
||
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.
Updated•12 years ago
|
Reporter | ||
Comment 9•12 years ago
|
||
(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> ?
Reporter | ||
Comment 10•12 years ago
|
||
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.
Reporter | ||
Comment 11•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
status-firefox28:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•