window.open is not rendered when alarm goes off in OOP mode

VERIFIED INVALID

Status

VERIFIED INVALID
6 years ago
6 years ago

People

(Reporter: iliu, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:-)

Details

STR
====

1. Launch Clock app and set an alarm.
2. Click power key let the devices in screen off state.
3. Wait for the alarm goes off.

Actual result:
 - There is no render for the attention page which is opened by window.open.

Expected result:
 - The onring attention page should be rendered.

Note:
  We can see that lock screen is showing, but cannot be controlled.
  Because of a transparent onring page is over the lock screen page.

Updated

6 years ago
blocking-basecamp: --- → ?
This should work and therefore should block.  It may be a gaia bug.
blocking-basecamp: ? → +
Out-of-process iframes now don't have a background by default, like same-process iframes.  We need to ensure that iframes created for "pop-up windows" have a white background.
(In the gaia window manager, I mean.)
So is this a Gecko bug?
We need to ensure popup windows have backgrounds before being able to determine that.
I hate to be pedantic but how are we tracking the effort to ensure popup windows have backgrounds?  I looked through open Gaia issues and didn't find anything.
Being pendantic is great!

I don't know who owns the clock app on the gaia team --- do you guys know who does?
Hi Ian! Could you please confirm if the pop-up windows has backgrounds? We need to know the info before the taking the next step.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #7)
> Being pendantic is great!
> 
> I don't know who owns the clock app on the gaia team --- do you guys know
> who does?

Sorry, I'm the owner.
My ID of Bugzilla is hard to identify.
I have refined it.
(In reply to Gene Lian [:gene] from comment #8)
> Hi Ian! Could you please confirm if the pop-up windows has backgrounds? We
> need to know the info before the taking the next step.

Yes, it has a background image to be the background.
I also try to use background-color only.
The issue is still there.
I can only intermittently reproduce this bug.  One time I reproduced it, I saw the attention screen partly drawn at the top of the lock screen.  Another time I reproduced it, the attention screen apparently took focus away from the lock screen and I had to reboot the phone.

This feels like a bug in the gaia window manager to me.  Has anyone verified that the window manager is handling the attention screen in the right way --- setting the frame to visible, giving it the right z-ordering, etc.?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #11)
> I can only intermittently reproduce this bug.  One time I reproduced it, I
> saw the attention screen partly drawn at the top of the lock screen.

That's expected since attention screen can be minimized on the top; the minimized UI is not implemented yet (https://github.com/mozilla-b2g/gaia/issues/2567)
 
> Another time I reproduced it, the attention screen apparently took focus
> away from the lock screen and I had to reboot the phone.

Yes, that's what STR aim to reproduce. Press home button from here will minimize the iframe and trigger the rendering(?); touch the minimized iframe will bring back the full attention screen with correct rendering.

> 
> This feels like a bug in the gaia window manager to me.  Has anyone verified
> that the window manager is handling the attention screen in the right way
> --- setting the frame to visible, giving it the right z-ordering, etc.?

I can pretty sure that the there are no issues on Gaia system part.

- Incoming call screen is always shown without an problem (with screen off or on before incoming call).
- Keep the screen on before the alarm goes off will also prevent this issue from happening.
- Have the power source plugged in does not prevent this issue from happening
- Ian said that if we set background color on iframe in system app, we will be able to show the background color WITHOUT onring HTML content within when the alarm triggers.

Updated

6 years ago
QA Contact: jshih
(In reply to Ian Liu [:ianliu] from comment #9)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #7)
> > Being pendantic is great!
> > 
> > I don't know who owns the clock app on the gaia team --- do you guys know
> > who does?
> 
> Sorry, I'm the owner.

I'm going to assume you should own this bug, too, Ian.  If that's incorrect, feel free to put it back to nobody.  Thanks.
Assignee: nobody → iliu
Summary: There is no render for window.open when alarm goes off in OOP mode. → window.open is not rendered when alarm goes off in OOP mode
Sorry, I have no way to fix the issue on the gaia.
So I change the owner.
Assignee: iliu → nobody
(In reply to Ian Liu [:ianliu] from comment #14)
> Sorry, I have no way to fix the issue on the gaia.
> So I change the owner.

And I think it's not a gaia issue.
Thanks.
Some news:

In the process of getting rid of the dialer background service I started having the same kind of issues.

After 2 days of hair pulling and a lot of help from Vivien, here is the latest theory:

If the screen is off when the attention screen is launched then:
- attention_screen.js calls |turnScreenOn()| on the screen manager
- the screen manager fires an event telling the rest of the system app about this
- the lockscreen catches the event and tries to lock itself
- in the process of locking the lockscreen grabs the focus by precaution
-> We now have a un-drawn iframe on top of everything else, sad face.

Anyway looks like

https://github.com/etiennesegonzac/gaia/blob/8bcd6b3e378114b7a6fd17aa3cababee5fed7939/apps/system/js/attention_screen.js#L52-L57

fixes it!
Ian, can you confirm the fix and close this bug if everything's working now?  Thanks.
Whiteboard: [blocked-on-input Ian Liu]
(In reply to Dietrich Ayala (:dietrich) from comment #17)
> Etienne, so would this cause https://github.com/mozilla-b2g/gaia/issues/4716
> ?

That's very likely. What is describe in the github issue is exactly what Etienne was facing.
(In reply to Etienne Segonzac from comment #16)
> Some news:
> 
> In the process of getting rid of the dialer background service I started
> having the same kind of issues.
> 
> After 2 days of hair pulling and a lot of help from Vivien, here is the
> latest theory:
> 
> If the screen is off when the attention screen is launched then:
> - attention_screen.js calls |turnScreenOn()| on the screen manager
> - the screen manager fires an event telling the rest of the system app about
> this
> - the lockscreen catches the event and tries to lock itself
> - in the process of locking the lockscreen grabs the focus by precaution
> -> We now have a un-drawn iframe on top of everything else, sad face.
> 
> Anyway looks like
> 
> https://github.com/etiennesegonzac/gaia/blob/
> 8bcd6b3e378114b7a6fd17aa3cababee5fed7939/apps/system/js/attention_screen.
> js#L52-L57
> 
> fixes it!

Thanks for your information in detail.
(In reply to Andrew Overholt [:overholt] from comment #18)
> Ian, can you confirm the fix and close this bug if everything's working now?
> Thanks.

I have verified the issue.
Clock APP is working now in this case.
So, we can close the issue.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [blocked-on-input Ian Liu]
Questions:

1. I wonder why does taking away the focus of the attention screen iframe results an undrawn iframe? Looks like a Gecko issue to me.

2. This bug should be REOPENed (and non-blocking) if what mentioned above is a Gecko issue. If it's not a Gecko issue, since this bug doesn't fix anything on Gecko (and Gecko doesn't need any fixes), the bug here should be RESOLVED INVALID.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #22)
> Questions:
> 
> 1. I wonder why does taking away the focus of the attention screen iframe
> results an undrawn iframe? Looks like a Gecko issue to me.
> 
> 2. This bug should be REOPENed (and non-blocking) if what mentioned above is
> a Gecko issue. If it's not a Gecko issue, since this bug doesn't fix
> anything on Gecko (and Gecko doesn't need any fixes), the bug here should be
> RESOLVED INVALID.

I agree question (1).
And it's not a blocking issue now.
So, I change the status to RESOLVED INVALID without blocking +.
blocking-basecamp: + → ?
Resolution: FIXED → INVALID
blocking-basecamp: ? → -

Comment 24

6 years ago
verfied on otoro-ics 2012-09-20
build info
gaia : 9ac2d4f8dd4eb1995bd1c2dfcafa990bceca0b7b
mozilla-central : 0b6677a9d5ed3cd8f0dd95f39cd3a0a204129d76
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.