1089984 - [User Story] Launching a mobile-data-restricted app

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

Comment 1

[Chris Lord [:cwiiis]]

Working on this here: https://github.com/Cwiiis/gaia/tree/bug1089984-launching-data-restricted-app

Comment 2

[Chris Lord [:cwiiis]]

Attachment: WIP screenshot (2014-11-26)

Comment 3

[Chris Lord [:cwiiis]]

My current problem with implementing this is that the app mobile-data property is only available with the web-apps management permission (fine), but the network error page is implemented in the actual app process instead of the system wrapper.

As far as I know there's no way to distinguish between certified code running in an uncertified app that does stuff like this vs. code from the app, so I don't think there's a secure way of changing the mobile data settings from within the app. This needs to be done in the system or costcontrol apps, I would suppose.

I had a look at handling neterror in the system app instead of the app itself, which would seem feasible, but the 'mozbrowsererror' signal doesn't contain enough information and it seems the about:neterror url doesn't get propagated to the browser element's src either?

If we wanted this to be seamless (i.e. you press the button and the stuff happens without bringing up more screens and whatnot), that button needs to be in a certified app - I suppose perhaps we could use a web activity in the system app to do this? I'll continue looking.

Comment 4

[Salvador de la Puente González [:salva]]

(In reply to Chris Lord [:cwiiis] from comment #3)
> My current problem with implementing this is that the app mobile-data
> property is only available with the web-apps management permission (fine),
> but the network error page is implemented in the actual app process instead
> of the system wrapper.
> 
> As far as I know there's no way to distinguish between certified code
> running in an uncertified app that does stuff like this vs. code from the
> app, so I don't think there's a secure way of changing the mobile data
> settings from within the app. This needs to be done in the system or
> costcontrol apps, I would suppose.
> 
> I had a look at handling neterror in the system app instead of the app
> itself, which would seem feasible, but the 'mozbrowsererror' signal doesn't
> contain enough information and it seems the about:neterror url doesn't get
> propagated to the browser element's src either?
> 
> If we wanted this to be seamless (i.e. you press the button and the stuff
> happens without bringing up more screens and whatnot), that button needs to
> be in a certified app - I suppose perhaps we could use a web activity in the
> system app to do this? I'll continue looking.

I think this could be treated in the same way as permissions are handled. May be this error should trigger a chrome event and the chrome event should be returned to system to allow system to show the proper dialog. This dialog could redirect you via web activity to Smart Data / Settings or simply allow to change the preference directly.

Comment 5

[Chris Lord [:cwiiis]]

(In reply to Salvador de la Puente González [:salva] from comment #4)
> I think this could be treated in the same way as permissions are handled.
> May be this error should trigger a chrome event and the chrome event should
> be returned to system to allow system to show the proper dialog. This dialog
> could redirect you via web activity to Smart Data / Settings or simply allow
> to change the preference directly.

We won't be able to provide the flow we want like this though, it means after pressing the button, the user will have to perform some other action outside of the page before going back to the page - ideally, the user would press the button and continue seamlessly.

Perhaps we could do this as a stop-gap, but I'd rather shoot for a better solution first time, if it's feasible (which it should be).

We should be able to re-architect things so that the net-error handling can be done in chrome immediately rather than in-process, much like cert-errors and permissions. I think this would be the way to go.

We would easily be able to do this now, but for some reason, the browser element doesn't fire the locationchange signal for loading the neterror page. If it did, we could just change that page to a blank page and parse the uri in the AppWindow (and display the UI there, where we can also make sure the title-bar doesn't collapse, and such like).

Comment 6

[Chris Lord [:cwiiis]]

ok, having digged and thought about this some more, I think we have 2 options:

1- As suggested, allow the per-app data restriction flag permission to be requested on-demand, like camera/gps/etc. This would add an extra door-hangar to the process laid out by the spec, but perhaps has the benefit of making more clear to the user the consequences of what they're doing

2- Extend the browser element's 'error' signal to provide more information about the actual error (beyond fatal and non-fatal) and use that to handle neterror in the chrome rather than in the app.

I prefer 2 as I think there's less security risk and it allows us to provide the UX specified. I don't know which of either of these is more effort, but I'm going to look into the second.

n?daleharvey for comment on extending the error signal, if any.

Comment 7

[Chris Lord [:cwiiis]]

So there's already a TODO comment about adding more error types to this signal, so this is looking like a viable way to go: http://mxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementChildPreload.js#1205

Comment 8

[Chris Lord [:cwiiis]]

The patch in bug 1106132 will allow us, I think, to handle this situation in browser chrome. We don't necessarily need to move all the net-error handling into Chrome (though I think doing so would make sense in the long run).

Cancelling n?daleharvey.

Comment 9

[Chris Lord [:cwiiis]]

Attachment: WIP: Implement feature

The feature now works, or at least, it would if the platform feature also worked (thus the commented out bits in the patch, but ignore that).

This is a bit untidy, but I'd like to get some early feedback before going any further in case you'd prefer a different approach/would like to give some advice now.

My personal preference is for all error handling to be done system-side - the current pref hack is kind of against what b2g is about imho (e.g. the user can't provide their own custom net-error handling when using a browser element). This is a first step towards that, after this it would be pretty trivial to also move the rest of the net-error handling into system.

That said, I like how the current net-error handling is more modular, code-wise, and it would be good to restructure this patch to replicate that somehow. Suggestions most welcome.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8532533 [details]
WIP: Implement feature

I wonder where is the API agreed to go and please if there is, please link me the discussion/mail.
* What if on tablet/TV/watch? It seems you are always rendering the dialog. It's bad to see the dialog on other device which is not a mobile.
* It'd be better if the code moved into another instantiatable class such as Net Restriction Dialog.

Comment 11

[Etienne Segonzac (:etienne)]

Comment on attachment 8532533 [details]
WIP: Implement feature

Looks like Alive is on it :)

If it's pref-based can we cover it with Server [1] based integration tests?

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/test/marionette/browser_private_sanity_test.js#L22-25

Comment 12

[Jacob Shen]

[Tracking Requested - why for this release]:

Comment 13

[BMO Automation]

Firefox OS is not being worked on