Unlock SIM Card Web activity should be trigger by user action

VERIFIED FIXED

Status

Firefox OS
Gaia
P1
normal
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: timdream, Assigned: ochameau)

Tracking

(Blocks: 1 bug, {feature})

unspecified
feature
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(1 attachment)

+++ This bug was initially created as a clone of Bug #794407 +++

According to bug 794407, all non-user action callback cannot trigger Web Activities. Triggering the unlock SIM panel in Settings is one of the instance. That need to be changed too before bug 794407 could land.

I have no idea how we should do it.
Can someone describe when this activity is invoked, and what it does when invoked.

Updated

5 years ago
Priority: P1 → --
(In reply to Jonas Sicking (:sicking) from comment #1)
> Can someone describe when this activity is invoked, and what it does when
> invoked.

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/sim_lock.js#L58
It opens settings app's page to input the sim pincode.
There's not enough information here. Tim, can you clarify what actually needs to happen? We can't figure out how this is not a result of a user action. Will fixing this require new feature work?
Assignee: nobody → timdream+bugs
Flags: needinfo?(timdream+bugs)
Priority: -- → P1
Could we do this by simply having the system app create an

<iframe mozbrowser mozapp="<settings app manifesturl>" src="<settings app url>?sim-pin">


Another solution would be to make an exception and allow the system app (or even all certified apps) to initiate web activities without a user action. But if we do that we'd need to also implement some mechanism to prevent 3rd party apps from implementing this activity.
(In reply to Dietrich Ayala (:dietrich) from comment #3)
> There's not enough information here. Tim, can you clarify what actually
> needs to happen? We can't figure out how this is not a result of a user
> action. Will fixing this require new feature work?

This bug tries to deal with fallout of the security decision and implementation in bug 794407.

(In reply to Jonas Sicking (:sicking) from comment #4)
> Could we do this by simply having the system app create an
> 
> <iframe mozbrowser mozapp="<settings app manifesturl>" src="<settings app
> url>?sim-pin">
> 
> 
> Another solution would be to make an exception and allow the system app (or
> even all certified apps) to initiate web activities without a user action.
> But if we do that we'd need to also implement some mechanism to prevent 3rd
> party apps from implementing this activity.

Why would we preventing 3rd party from writing an Settings app, or a SIM Unlock app? The reason we are using web activities for launching Settings app is exactly that -- allowing 3rd party implementation.

If you look into sim_lock.js you would know when we will ask for Web Activities. One thing we could do is to add a prompt ("Do you want to unlock the SIM?") before the activity, but that's late-l10n and UI change.
Flags: needinfo?(timdream+bugs)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #5)
> (In reply to Dietrich Ayala (:dietrich) from comment #3)
> > There's not enough information here. Tim, can you clarify what actually
> > needs to happen? We can't figure out how this is not a result of a user
> > action. Will fixing this require new feature work?
> 
> This bug tries to deal with fallout of the security decision and
> implementation in bug 794407.
> 
> (In reply to Jonas Sicking (:sicking) from comment #4)
> > Could we do this by simply having the system app create an
> > 
> > <iframe mozbrowser mozapp="<settings app manifesturl>" src="<settings app
> > url>?sim-pin">
> > 
> > 
> > Another solution would be to make an exception and allow the system app (or
> > even all certified apps) to initiate web activities without a user action.
> > But if we do that we'd need to also implement some mechanism to prevent 3rd
> > party apps from implementing this activity.
> 
> Why would we preventing 3rd party from writing an Settings app, or a SIM
> Unlock app? The reason we are using web activities for launching Settings
> app is exactly that -- allowing 3rd party implementation.

The reason is that we currently don't have enough components to actually support this use case. I agree it's something that we want to enable, but right now if a 3rd party app installs this activity, a user can easily get into a situation when the phone stops working correctly because a 3rd party app comes up rather than an app which actually has the capability to unlock the sim.

Replacing system components like the home screen or the settings app needs to be done with a lot of care. Otherwise users will inevitably end up in a state where their phone effectively doesn't work. Or at least where they don't know how to make their phone work again.

I'd be ok with having making it possible to replace the sim card unlocking in developer mode. I.e. only using an activity here if the user has turned on developer mode. Or only registering an activity handler for this activity during installation, if developer mode is enabled at time of installation. Or some such.

I absolutely agree that we should support replacing core components of the device. But I think we need to do it with more care than simply using an activity.
Evelyn, can you drive the discussion with Jonas, Vivien, and Kaze to come up with a fix that everyone agrees on, and implement it?

I have no time to take two P1 bug at the same time and resolve both of them in a timely fashion. :'(
Assignee: timdream+bugs → ehung
After thinking a while, I agree Jonas's opinion. Web activity is not the best implementation in unlocking SIM PIN case. From technique view, like what Jonas concerns, we now can't prevent that 3rd party app didn't implement (or unexpected implemented) the same web activity. From UX view, if the unlock process always need to triggered by user action on device startup, it will slow down the whole booting process. (and probably not a common UX on current smart phone?)

My proposal is:
I'll try to implement SIM PIN unlock process by creating an iframe and read Settings app's manifest URL from mozSettings db (just like what we do for homescreen app). If Settings app is replaced by 3rd party app someday, it has chance to write this setting in db.
Is it okay?

Updated

5 years ago
Blocks: 807904
I'm sorry, but I figure out it's hard to mimic a dynamic created iframe that behave like an inline disposition web activity. Here are problems I face:
1. the iframe should pop up inline, if the user closes it, he will be taken back to the original app in the foreground.
2. the iframe should open a specified page, not an app main page, so I need to specify another entry point of Setting app.

The window manager in System app doesn't provide a way to create an iframe that can fulfill my needs above. It seems I have no choice but use web activity and add a dialog so the user can trigger the SIM pin unlock process.

I suggest we file another bug for 3rd party app installs web activities that unexpectedly replace system working components, because SIM PIN unlock is not the only case, we really need a total solution.

I will focus on dealing with fallout of the security decision and implementation in bug 794407.
(In reply to Evelyn Hung [:evelyn] from comment #9)
> I suggest we file another bug for 3rd party app installs web activities that
> unexpectedly replace system working components, because SIM PIN unlock is
> not the only case, we really need a total solution.

Yeah, that discussion should not be belong to here. Also, since user cannot uninstall built-in apps, the worse case for a shipped phone will be user seeing two apps in the activity handler selection dialog, and some of the user installed apps doesn't really unlock the SIM.
(In reply to Evelyn Hung [:evelyn] from comment #9) 
> The window manager in System app doesn't provide a way to create an iframe
> that can fulfill my needs above. It seems I have no choice but use web
> activity and add a dialog so the user can trigger the SIM pin unlock process.
> 

I believe the SIM PIN dialog should be part of the system app. When the device is started it can show the dialog if needed.

For other applications that needs to show this dialog on demand (like the dialer and sms app for example) I would have expect an event on the sms/telephony APIs when someone try to send a text message that fails or made a call that fails for some reasons.

Since there is no such events I guess a setting could be toggled for now.

> I suggest we file another bug for 3rd party app installs web activities that
> unexpectedly replace system working components, because SIM PIN unlock is
> not the only case, we really need a total solution.

I feel like there is a global lack when an application needs to target a specific part of an other application and we need something for that. But Web Activities is not done for that so adding some 'private' web activities is just a workaround.
Evelyn,

I was thinking of assigning this bug to ochameau, is that fine to you?
Vivien,
Sure, making SIM PIN dialog being part of system app is a big change, I'm glad to have someone's help. Feel free to let me be the patch reviewer. Thanks!
Assignee: ehung → poirot.alex

Updated

5 years ago
No longer blocks: 807904
Depends on: 807904
We're marking this bug with the C1 milestone since it follows the criteria of "unfinished feature work" (see https://etherpad.mozilla.org/b2g-convergence-schedule).

If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.
Target Milestone: --- → B2G C1 (to 19nov)
(In reply to Alex Keybl [:akeybl] from comment #14)
> We're marking this bug with the C1 milestone since it follows the criteria
> of "unfinished feature work" (see
> https://etherpad.mozilla.org/b2g-convergence-schedule).
> 
> If this work is not finished by Nov19, this bug will need an exception and
> will be called out at the upcoming Exec Review.

If this bug isn't fixed, we will ship Firefox OS with whether a security and specification implementation problem (ability to start an activity without user interaction) *or* we will not support users with PIN on their SIM cards.

Updated

5 years ago
Keywords: feature
Alex, why do you call this a feature? It's not a feature but a bug IMO. At best, we can call this polish. The outcome of this ticket being fixed will not add any new functionality, it will just make the Web Activity API being used as it was designed to be used.
(Assignee)

Updated

5 years ago
Depends on: 809924
(Assignee)

Updated

5 years ago
Depends on: 802073
(Assignee)

Comment 17

5 years ago
Created attachment 679738 [details]
Pull request 6286

Depends on bug 802073 [fixed], otherwise the keyboard doesn't appear. MozKeyboard API wasn't catching focus from system app except when Browser or Communication app were active.

And on bug 809924 [still-unfixed], this badly break the SIM PIN unlock workflow. It prevents the SIM PIN dialog to be displayed until you switch on/off the airplane mode. The MozMobileConnection misbehaves and returns a `null` cardState.

Otherwise, in this patch, I've only addressed the original issue of this bug: "remove the web activity". I haven't tried to communicate between apps to show the PIN dialog. I basically copied the existing dialog from settings to system.

As system app displays various kind of dialogs, and it isn't necessary easy to implement a new one, I've added a new utility script: js/system_dialog.js. It allows to document and ease the implementation of new screens and dialogs.
I haven't tried to share code with existing dialog and screens as it doesn't make sense to do so in current project status, but it would be helpfull to start sharing for new dialogs.

I haven't tested puk dialog as I don't have mine with me. I'll test that later.
Attachment #679738 - Flags: review?(21)
Comment on attachment 679738 [details]
Pull request 6286

Redirecting to Alive. I also think that you need to fix the MozActivity use in the dialer/sms app in order to make sure nothing regressed.
Attachment #679738 - Flags: review?(21) → review?(alive)
(Assignee)

Comment 19

5 years ago
(In reply to Vivien Nicolas (:vingtetun) from comment #18)
> I also think that you need to fix the MozActivity use
> in the dialer/sms app in order to make sure nothing regressed.

Actually, there isn't any activity being sent by Communications. System app opens the SIM PIN dialog as soon as an application having sms and/or telephony permission(s) is launched.
(In reply to Mounir Lamouri (:mounir) from comment #16)
> Alex, why do you call this a feature? It's not a feature but a bug IMO. At
> best, we can call this polish. The outcome of this ticket being fixed will
> not add any new functionality, it will just make the Web Activity API being
> used as it was designed to be used.

Without the new work in this patch, can a user easily configure a SIM Card with PIN? Has the user ever been able to? If the answer is no to those questions, this is unimplemented feature work (which is why triage determined it to be a P1 in the first place). Perhaps we had that wrong though.
(Assignee)

Comment 21

5 years ago
(In reply to Alex Keybl [:akeybl] from comment #20)
> Without the new work in this patch, can a user easily configure a SIM Card
> with PIN? Has the user ever been able to? 

Yes, you could change/remove/add SIM PIN in Settings app.
This bug is mainly about moving/copying this feature implementation from settings app to system app in order to unbock bug 794407.

Note that SIM PIN dialog is currently broken by a regression described in bug 809924.
(In reply to Alexandre Poirot (:ochameau) from comment #21)
> (In reply to Alex Keybl [:akeybl] from comment #20)
> > Without the new work in this patch, can a user easily configure a SIM Card
> > with PIN? Has the user ever been able to? 
> 
> Yes, you could change/remove/add SIM PIN in Settings app.
> This bug is mainly about moving/copying this feature implementation from
> settings app to system app in order to unbock bug 794407.

This isn't an unimplemented product requirement, to prompt the user for their PIN as opposed to having them find the interface in Settings? Feel free to remove the keyword if that's not the case - it doesn't really change the priority (this blocks a P1) or milestone (comment 13 suggests this is significant work).
Target Milestone: B2G C1 (to 19nov) → ---
Blocks: 796726
Comment on attachment 679738 [details]
Pull request 6286

r+=me, please remember to rebase to avoid conflict and regression.
Thank for your patience.
Attachment #679738 - Flags: review?(alive) → review+
(Assignee)

Comment 24

5 years ago
(In reply to Alive Kuo [:alive] from comment #23)
> Comment on attachment 679738 [details]
> Pull request 6286
> 
> r+=me, please remember to rebase to avoid conflict and regression.
> Thank for your patience.

Thanks for your quick review cycles!

Rebased, ready to land.
(Assignee)

Comment 25

5 years ago
Stas, this pull request is about to copy locale strings from settings to system app:
https://github.com/mozilla-b2g/gaia/pull/6286/files#diff-5
https://github.com/mozilla-b2g/gaia/commit/e368cc8c46ad7300d6dd41e1f95ba8922e32bb96
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Blocks: 810239

Comment 27

5 years ago
verified on unagi 2012-11-16
build info
gaia master : 9e5fb101b199a3c93870cda24e497b83599b5efc
mozilla-aurora : ea8661c0067f
(Assignee)

Updated

5 years ago
Blocks: 812428
(Assignee)

Updated

5 years ago
Blocks: 812426

Comment 28

5 years ago
Device: Unagi
Build: 20130103070201
Does not repro on this device and build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.