931430 - [Settings] Phone lock separation and haida bridge library

Status: RESOLVED WONTFIX

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

Description

[Kevin Grandon :kgrandon]

I think it could be possible to prototype a bridge between now and haida in a simple library. Once we implement haida it would be a matter of simply throwing a switch in the library or setting a pref to enable the new transitions.

I'm currently doing some work for settings, and I feel that this would be a good way forward so I don't duplicate efforts of what's needed in the future.

I will start with a simple panel in settings, then we can expand from there if folks like the approach.

Comment 1

[Kevin Grandon :kgrandon]

Attachment: Github pull request

Hey Guys,

This pull request changes two panels from settings to load in their own HTML page. The goal is that there should be no visual difference to the user, but each panel should be encapsulated with it's own logic and dependencies.

There is a new shared/js/sheet.js file which is a lightweight file to open/close iframes. Once haida rolls around it would be trivial to change this logic to proxy the necessary information to the system app.

I'm currently working on bug 922658 and there is a lot of similar concepts as to what we want to do in haida in the longrun, so I think this may be a good place to start prototyping work.

James - I've marked you as feedback? as I know you have a lot of great ideas on haida which this doesn't capture, but my hope is that we may have the chance to extend this pattern to a few other applications and start adding platform standards and shared worker libraries where possible.

Vivien - I've marked you for review as I actually want to land this for bug 922658. If we land this, or something like this - I will likely flush out the shared library a bit more as I get around to doing this for other settings panels.

Comment 2

[Kevin Grandon :kgrandon]

You can try this out by applying the patch and navigating to Settings -> Phone Lock. The phone lock and passcode panels will be their own iframes.

Comment 3

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

Comment on attachment 822850 [details] [review]
Github pull request

It makes me really happy that you took over this stuff. I think this patch will expose some of our underlying issues! \o/

One thing which is strange imo for now is the fact that each iframes has to embed sheet.js and so each of them will contains sub-iframes. In my mind I was thinking that there will be a a kind of common window container that manages those iframes instead of nesting them.

This container will contains sheet.js and sheets will call window.parent.close(sheet) (overidden in the container window) or window.close directly (if the sheet is displayed as an inline activity and does not have a parent).

This may also let us do dirty tricks if duplicating js is too painful for load time/memory until the platform makes it better. For example the container window may be the only one to contains settings_base.js/l10n.js and child sheets may just reused it. I'm not saying this is what we want at the end but it could be an intermediate step.

I also wonder if you don't want a shared/style/sheet.css.

What do you think?

Comment 4

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

Oh and last but not least can we s/sheet/page/. Please!

Comment 5

[Kevin Grandon :kgrandon]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #3)
> Comment on attachment 822850 [details] [review]
> Github pull request
> 
> One thing which is strange imo for now is the fact that each iframes has to
> embed sheet.js and so each of them will contains sub-iframes. In my mind I
> was thinking that there will be a a kind of common window container that
> manages those iframes instead of nesting them.

Sounds good. it's also a bit strange to me as well - but it shouldn't really matter in the long run. I'm going to take another exploratory step in this at only loading the polyfill in at the container level.

Comment 6

[Kevin Grandon :kgrandon]

Attachment: New WIP pull req

Comment 7

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

Comment on attachment 822850 [details] [review]
Github pull request

As I said I would like to r?/land that for 1.4. So lets cancel the review for now

Comment 8

[James Lal [:lightsofapollo]]

Comment on attachment 822850 [details] [review]
Github pull request

I already left my feedback but never +'ed the flag :)

Comment 9

[Kevin Grandon :kgrandon]

Seems we are going with a different approach now, so closing this one.