1128793 - [FFOS7715 v2.1][STK]USAT case 27.22.7.6.1 IDLE SCREEN AVAILABLE EVENT SEQ 1.1，select the idle screen，no EVENT DOWNLOAD - IDLE SCREEN AVAILABLE

Status: RESOLVED DUPLICATE of bug 1132363

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[jinghua.xing]

[Testing Steps     ]:USAT case 27.22.7.6.1 IDLE SCREEN AVAILABLE EVENT SEQ 1.1  EVENT DOWNLOAD - IDLE SCREEN AVAILABLE

[Expected Result  ]:case pass

[Test Result      ]:select the idle screen，no EVENT DOWNLOAD - IDLE SCREEN AVAILABLE

Comment 1

[jinghua.xing]

In ETSI TS 101 267 describes for Idle screen available event :

>When the ME next enters a state where it would accept rather than reject a DISPLAY TEXT command of
>normal priority, the ME shall inform the SIM that this has occurred, by using the ENVELOPE (EVENT
>DOWNLOAD - idle screen available) command as defined below.

Only when the active app is homescreen or settings can the normal priority text can be displayed

Comment 2

[jinghua.xing]

But in our design for the Idle screen available event, we listen to the

Comment 3

[jinghua.xing]

But in our design for the Idle screen available event, we listen to the 'lockscreen-appopened' event and only if once we go to the lockscreen can send the EVENT DOWNLOAD to the sim. 

I think this behavior do not comply with the standard and the event download should be send once we go to the homescreen but not the lockscreen. 

What's your opinion about this?

Comment 4

[jinghua.xing]

If we first open an app like sms and then lock the screen, at this moment there is an event download to the sim, but if we send a normal priority DISPLAY TEXT command, it will be reject. 

So I think listen to the 'lockscreen-appopened' event is wrong for this case.

Vance, can you help me check this case? Thank you.

Comment 5

[shawn ku [:sku]]

Sean,
 Please help clarify this issue first.
Thanks!!

Comment 6

[Sean Lee [:seanlee][:weilonge]]

In this case, I would suggest to listen 'screenchange' event.
When evt.detail.screenEnabled is true, the screen turns ON.
If both 'screenchange' triggered and evt.detail.screenEnabled === true happened,
the event envelope could be sent.
Thanks.

Comment 7

[jinghua.xing]

Sean

If we listen to the 'screenchange' event and the event will be downloaded when we click the power button and turn on the screen. The problem like what I said in comment 4 is still existing. So I think we should act as the protocol in comment 1 describes and send the event envelope when the next is the homescreen/settings.

What do you think about this? Thank you.

Comment 8

[Sean Lee [:seanlee][:weilonge]]

Hi Jinghua,

You can use this way to get the origin of the current active app:
window.appWindowManager.getActiveApp().origin

The origin of Home Screen and Settings app looks like these:
 Home Screen: app://verticalhome.gaiamobile.org
Settings app: app://settings.gaiamobile.org

Thank you.

Comment 9

[jinghua.xing]

Sean：

I think the event should be downloaded at the moment "when the ME next enters a state where it would accept rather than reject a DISPLAY TEXT command of normal priority" as the protocol describes. And in the test case showed in ETSI TS 102 384 V7.1.0, in the case 27.22.7.6.1, the event should downloaded once we entered an idle screen from a screen other than the Terminal idle screen.

How do you think if we listen the 'homescreenopened' event?

Thank you

Comment 10

[Sean Lee [:seanlee][:weilonge]]

Hi Jinghua,

comment 8 is for your reference to listen Home Screen and Settings app opened, and this one is more generic.
Listening 'homescreenopened' is a simpler way to know when the home screen is opened, but it's only for Home Screen.

Thank you.

Comment 11

[jinghua.xing]

Sean：

I have asked our QA this issue again for this case, and in their tests, they only treat the homescreen as the idle screen.

What do you think for this, and what is the idle screen in our FFOS? Thank you.

Comment 12

[Sean Lee [:seanlee][:weilonge]]

Hi Jinghua,

IMHO, FFOS does not define idle screen.
However, when Home Screen or Settings app is active,
it's the state that can handle DISPLAY TEXT command.

Thank you.

Comment 13

[jinghua.xing]

Sean：

Thank you for your kindly help and this issue has been fixed now.