1020063 - (app-settings-panel) Allow installed apps to embed a panel in Settings app

Status: RESOLVED WONTFIX

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

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

This bug represents a feature in which the user can see settings panels of each of the installed apps in the Settings app. It known as "Settings Bundle" in iOS. 

I am filing this issue so everyone have a bug number to talk about.

I would imagine we would need

- bug 879475 so we could embed another remote app in a remote app process
- a UX spec on how these panels are embedded
- a security review and a decision on which level of exposure of this feature
- a pointer on manifest to the Settings page, maybe |settings_launch_path|?
- maybe mozApp API change if we are not comfortable of having Settings app to parse the above property directly.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

FWIW, I think we should implement this even if we are not planning to expose it to 3rd parties. I can see many FxOS features comes with their independent app, but they inevitability has to touch the Settings codebase just for the sake of expose user settings. With this feature implemented, we could ask them to concentrate their code to their own apps.

Comment 2

[(no longer active)]

I think adding a manifest field which points to the application's settings page makes sense here.

Comment 3

[Arthur Chen [:arthurcc][inactive after 6/30]]

Adding a manifest field makes sense to me and which also makes things easier if we would like to switch to haida in the future.

Regarding the UX of settings bundle, we should consider the inconsistency of the settings panel of each app, and how to show the settings panel from different types of apps (built-in or 3rd party). For example, do we show the settings panels from 3rd-party apps as they are still in the settings app while they may have completely different styles or layouts?

There is also an interesting case in which a button in messaging app links to the message settings panel in settings app. Things become weird if the message settings panel is actually implemented by messaging app itself. We should have a guideline on determining when to use embed settings or not.

Comment 4

[[e-mail]]

Take Apple Settings Bundle for example, they have strict 3rd-party to only use some of elements in preference panel https://developer.apple.com/library/IOs/documentation/Cocoa/Conceptual/UserDefaults/Preferences/Preferences.html

We could come out a similar 'Settings Bundle' web component and let 3rd-party import it as the base, so they will have similar UX as we wish. The 3rd-party app declare a manifest field could show it's panel item in settings, And then we can call the 3rd-party settings via inline activity.
This approach make webapp can call the settings page in app itself and more platform agnostic (works on FirefoxOS and Firefox Android)



What also comes to my mind is currently we don't expose mozSettings to 3rd-party. So we have ask tako owner to clarify if they just want to embed app specific settings or the system-wide settings(mozSettings).

If the request is to modify system-wide settings like new sound settings, we should seek for build-time customization approach instead.

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Fred Lin [:gasolin][OOO 6/23-27] from comment #4)
> Take Apple Settings Bundle for example, they have strict 3rd-party to only
> use some of elements in preference panel
> https://developer.apple.com/library/IOs/documentation/Cocoa/Conceptual/
> UserDefaults/Preferences/Preferences.html
> 
> We could come out a similar 'Settings Bundle' web component and let
> 3rd-party import it as the base, so they will have similar UX as we wish.
> The 3rd-party app declare a manifest field could show it's panel item in
> settings, And then we can call the 3rd-party settings via inline activity.
> This approach make webapp can call the settings page in app itself and more
> platform agnostic (works on FirefoxOS and Firefox Android)
> 
> What also comes to my mind is currently we don't expose mozSettings to
> 3rd-party. So we have ask tako owner to clarify if they just want to embed
> app specific settings or the system-wide settings(mozSettings).
> 
> If the request is to modify system-wide settings like new sound settings, we
> should seek for build-time customization approach instead.

Fred, you are mixing many things in this comment and not everything is related to this bug.

The approach of this bug as been embedding an iframe from other apps. I don't really care how we keep the style consistent across Gaia apps. Gaia apps has building blocks in-place already, we can surely upgrade that to web components but that's out of the scope of this bug.

The other approach you mentioned, based the iOS Settings Bundle in detail, is to simply ask 3rd-party to expose not a path to it's settings page, but a set of structural data describing the switches and labels it would like to put in the Settings app. This again has nothing to do with web components -- app doesn't really need to care how settings are rendered by the Settings app as long as users can see them and flick these switches.

(that approach also puts too much engineering burden on come up with a usable schema of the structural data -- it would take a long time before we can make the schema fit our own use cases in our current settings panels, it will certainly takes a long time before we could expose it.)

You are right about the fact the first approach cannot enforce a consistent look-and-feel on all apps and it force apps to adopt our library/web component just to make their Open Web Apps looks like Firefox OS app. However, I think the other approach is too restrictive. iOS developers suffered on that; my experiences working with add-on SDK taught me the same thing: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/simple-prefs

Please correct me if I totally understand you. I am sorry I didn't had a chance to discuss with you in person first.

Comment 6

[(no longer active)]

I know that Vivien and others have been thinking about theming issues in Gaia, perhaps we don't need to worry about that in this bug.

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

First, this bug is likely a duplicate of bug 920455. This bug try to resolve the same thing, and already discussed the |json schema| issue a bit.


(In reply to Arthur Chen [:arthurcc] from comment #3)
> Adding a manifest field makes sense to me and which also makes things easier
> if we would like to switch to haida in the future.

s/if we would like to/when we will/ ;)

 
> Regarding the UX of settings bundle, we should consider the inconsistency of
> the settings panel of each app, and how to show the settings panel from
> different types of apps (built-in or 3rd party). For example, do we show the
> settings panels from 3rd-party apps as they are still in the settings app
> while they may have completely different styles or layouts?
> 

Inconsistency is an issue, and it was hurting me at first when I discussed that in bug 920455.
Now, that it has been a little while, I think exposing the setting page of an application is the easiest path to go forward. It makes it easy for the app developers to access the same page from both its app, and the settings app.
In the future, if the difference of look and feel are really a usability issue we could come up again with the schema idea.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #6)
> I know that Vivien and others have been thinking about theming issues in
> Gaia, perhaps we don't need to worry about that in this bug.

The specific proposal does not really offer us a chance to control the look and feel of those panels if we expose that to third party apps (and I think we should).

So it's for good or bad - I can't really tell.

The theming framework we are building is an opt-in thing. If people wants to inherit some of the os colors, they can. Otherwise they may also do a completely crazy settings page too :)

Comment 9

[(no longer active)]

Yeah, I think there is not much we can do if the author of the app in question explicitly wants their settings UI to look different than the rest of the settings app...

Also, yes, this looks more or less a dupe of bug 920455 to me too.

Comment 10

[[e-mail]]

What I'd likely to propose is 3rd-party dev or gaia apps does not need embed page or expose data set to settings app in any format. But just keep their settings page in their app.

From settings app perspective, we could provide the `settings-panel` web-component and ask developer to import it to define their own settings panel (in their app). ex:

```
<settings-panel>
 <settings-toggle>Sound</settings-toggle>
</settings-panel>
```

Then use manifest to define the proper settings panel item to show in settings app's root panel.
Then the settings app could use inline activity to call 3-rd party's own setting page.

Comment 11

[(no longer active)]

I don't think that will address the requirements for Tako.  They explicitly want the application specific settings to be accessible *both* through the app itself and in the Settings app.

Comment 12

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Attachment: patch on master

This is a prototype patch and it works well now.

Comment 13

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Comment on attachment 8446324 [details] [review]
patch on master

Arthur,

I already implemented a prototype based on our offline discussions with Ian. By default, we will embed app's settings.html if you don't specify which page to embed. 

I left some changes on keyboard & bt menuItem so that you can easily test this feature and I will remove them later when r+ (I would keep keyboard's change because I think it is ok to change the way we communicate with keyboard app in this patch).

Any feedback / comment would be welcome ! Thanks for the help !

Comment 14

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8446324 [details] [review]
patch on master

I left some comments in github, please check them, thanks!

Comment 15

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Arthur, this one looks better now ! I like your idea to make a generic `back` method which would help us navigate back to original panel no matter where you are.

If this patch is ok, I would start to write tests, so please kindly give it a check !

Thanks :)

Comment 16

[Arthur Chen [:arthurcc][inactive after 6/30]]

The patch looks good to me, thanks.

As we are planning to finish the "in-process" version of this feature in v2.1 so that it can be used for the module separation of settings app, I've created a separate bug 1033951. Then we can use this one for discussion on the long term goal.

Comment 17

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Comment on attachment 8446324 [details] [review]
patch on master

Moved to bug 1033951.

Comment 18

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

This is a meta bug, so deassign myself as an assignee.

Comment 19

[BMO Automation]

Firefox OS is not being worked on