Multiple Windows per App (was: New Architecture Proposal)

[Benjamin Francis]

Hi Vivien,

Thanks very much for getting this proposal written up! It's a very interesting proposal, I'm very excited about the idea of turning Gaia apps into hosted web apps, using Service Workers for offline, syncing data via a web service and splitting the apps into multiple documents. This sounds much more like the original vision for Gaia than what we have so far.

As the document says, this architecture is dependent on a new security model to enable more APIs to be exposed to hosted web apps. I hope Jonas' thread on dev-b2g will help move this forward, and that we can also agree on a signing system.

As requested, I started a new thread to discuss one particular topic I'm interested in...

The idea that Gaia apps consist of multiple iframes inside a container which talk to each other is an interesting way to build web apps that I haven't come across before. One downside of this is that each app effectively becomes its own window manager, managing the transitions between different embedded frames, from the point of view of the task manager the app is still a single page app with a single window.

I wonder whether you discussed the idea of splitting apps out into multiple windows for some of those use cases rather than having one container with lots of iframes inside it? One window per app is a limitation that other mobile operating systems have, but Firefox OS doesn't need to share that same limitation. We don't have that limitation on desktop.

Ben

On 11 March 2015 at 14:36, Vivien Nicolas <vnic...@mozilla.com> wrote:

Hello Gaia folks,

In the last 3 years (already!), our teams has built a dedicated front-end experience for the Firefox OS platform, mostly designed around mobile devices, and especially phones.
While Gaia has been built under various constraints, such as last minute features, time-based deadlines, hard memory constraints, various hardware and form factors... I believe our initial goal of shipping a default front-end for our platform has been reached.

The ideation process and the last years highlighted the need for Gaia to scale and adapt. Not only to the constraints mentioned above but also to FirefoxOS users, in a world where there is not only one type of user, but many users with contextual and local needs. As of today, we often take guesses without real usage statistics.

It's also clear that perceived performances need to be on pair with other mobile devices vendors. While perceived performance is not a pure user goal that will motivate the adoption of the phone, a laggy experience may demotivate it.

Lastly, our application model has been designed to behave like static installed applications. While Mozilla is primarily building a browser, which is an installed application, it is designed for the Web. And the web is not about static installed applications but ... define your web here ...

In order to shape Gaia into a scalable and adaptable product, here is a proposal for a new high-level unified architecture https://wiki.mozilla.org/Gaia/Architecture_Proposal

The inner set of libraries needed to achieve this architecture is not described in this document. Implementation details could and should be discussed as part of a separate set of proposals.

This proposal is about moving to hosted apps with delta updates, using simple primitives to enforce encapsulation and expose applications inner structure to the browser instead of relying on a blackbox model, getting live reports from real users for real panels usages or for A/B testing purpose, isolating the front-end as a distinct and easily replaceable component with a strong focus on perceived performance and user experience, and adapting to future hardware features/constraints.

 

I believe this proposal is too big to be discussed in a single mailing-list thread. So please, if you want to discuss a specific point, start a new thread to avoid chaos.

Cheers,

Vivien.

_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Kevin Grandon]

The content wrapper looks a bit weird to me and my preference would be to find another way of polyfilling features if necessary. If we can't add necessary features to the platform in time, perhaps we can explore other ways to polyfill using extensions/addons. It seems like we could use the content wrapper as a crutch, and if we add more things to it I imagine it will be more difficult to migrate away from in the future.

It's likely that there will be different concerns about multiple windows vs the content wrapper. Perhaps we should stick to discussing only the content wrapper in this thread?

Best,

Kevin

[Etienne Segonzac]

On Thu, Mar 12, 2015 at 6:19 PM, Kevin Grandon <kgra...@mozilla.com> wrote:

If we can't add necessary features to the platform in time, perhaps we can explore other ways to polyfill using extensions/addons.

One of the key concerns Wilson raised early on with implementing navigation at the gaia system app level was desktop support, or more generally other platforms support.

(How cool would it be to run a ServiceWorker based gaia email app on Fennec :))

But even if we stay Firefox OS only, I think we still need the flexibility of the content wrapper.

During previous attempts at implementing app navigation at the gaia system level one of the big issue we had was tabs based apps (as in Clock, Dialer, Music etc...).

We can design around it but it's still a pretty common pattern where the navigation must be implemented at the app level because there's no hierarchical relationship between each tab only between screens inside each tabs.
Pretty hard to express this via special window.open calls :/ But easy peasy to make the tabs switching UI part of the content wrapper in order to add this behavior :)

--

Etienne

[Etienne Segonzac]

On Thu, Mar 12, 2015 at 5:55 PM, Benjamin Francis <bfra...@mozilla.com> wrote:

One window per app is a limitation that other mobile operating systems have, but Firefox OS doesn't need to share that same limitation. We don't have that limitation on desktop.

If we want to leave the door open for advanced use cases with multiple windows per app (like on desktop) we shouldn't use window.open for basic navigation :)

[Benjamin Francis]

On 12 March 2015 at 18:03, Etienne Segonzac <eti...@mozilla.com> wrote:

If we want to leave the door open for advanced use cases with multiple windows per app (like on desktop) we shouldn't use window.open for basic navigation :)

That's a good point.

I looked at a couple of examples of the architecture proposal that Kevin pointed me towards like https://github.com/fxos/contacts and https://fxos-messages.herokuapp.com/views/list/index.html (requires web components), and I realised that here iframes are being used more like a templating engine. There's shared UI like a header in the content wrapper, then sub-views embedded as iframes. It's an unusual use of iframes and reminds me a bit of the <frameset> method of building web sites in the olden days, but I don't have anything against that as long as each resource (like a contact or a message thread) has its own URL in the top level frame which you can deep link into.

I guess I was thinking more about use cases like having multiple pages of the same app open at the same time. Like having multiple contacts open at the same time, or multiple message threads open at the same time. A bit like I have a bug list in Bugzilla open in one browser tab, then multiple bugs open in multiple tabs at the same time on desktop.

Maybe a better way to implement that would be to enable the context menu for app windows so that I can long-press on a contact in the contacts list and select "open in new window", swipe back to the contacts list with edge gestures, long-press to open another contact in another window. Then I can swipe between the two contacts.

Another use case is when I have my Facebook app open on one Facebook page in the background, then I deep link into another Facebook page. Rather than unload the first page, it opens in a second window. All the pages of the Facebook app are then grouped together in the task manager.

[Vivien Nicolas]

On Thu, Mar 12, 2015 at 5:55 PM, Benjamin Francis <bfra...@mozilla.com> wrote:

As requested, I started a new thread to discuss one particular topic I'm interested in...

Thanks for starting a new thread!

 

The idea that Gaia apps consist of multiple iframes inside a container which talk to each other is an interesting way to build web apps that I haven't come across before. One downside of this is that each app effectively becomes its own window manager, managing the transitions between different embedded frames, from the point of view of the task manager the app is still a single page app with a single window.

I wonder whether you discussed the idea of splitting apps out into multiple windows for some of those use cases rather than having one container with lots of iframes inside it? One window per app is a limitation that other mobile operating systems have, but Firefox OS doesn't need to share that same limitation. We don't have that limitation on desktop.

That's something that has been discussed. But as you mentioned the main issue with one window === one panel is the fact that it requires a new web api that will only be available on Firefox OS. Many are really against this solution.
And so there has been some discussions with our platform friends to find a solution, but nothing ideal has popped up.

It is a quagmire.

So in order to get out of it, the proposal is, as you mentioned, overriding a small subset of the window manager into what is called the 'Content Wrapper'.
The CW has some benefits by itself, as exposed in the proposal (https://wiki.mozilla.org/Gaia/Architecture_Proposal#Content_Wrapper), but it is a non-goal.
It interferes with native deep linking, and, yeah, has an aftertaste of <frameset>. That's really not sexy.

Having the right set of APIs to get rid of it would be huge. For example the Page Transition API (http://www.programmableweb.com/news/transitions-api-chrome-to-animate-web/2014/11/26 or possibly a stripped down version) may answer some of the needs. But it is not sufficient to answer everything. For example what is the correct behavior for a view when it is not visible but the app is in foreground ?

So one solution is to wait for all APIs to land, get rid of the CW,  and cross-finger hoping those APOs have been designed in a way that match our use cases.
An other solution is to use the CW, move forward, prototype those APIs based on our use cases and help to shape any future standard.

The latter is what has been chosen in the proposal, since a variant of former has already been tried and our shoes are still full of mud.

 

Hope it answers why the CW is here. And why we can't get rid of it (yet).

Vivien.

[Vivien Nicolas]

On Thu, Mar 12, 2015 at 7:32 PM, Benjamin Francis <bfra...@mozilla.com> wrote:

I guess I was thinking more about use cases like having multiple pages of the same app open at the same time. Like having multiple contacts open at the same time, or multiple message threads open at the same time. A bit like I have a bug list in Bugzilla open in one browser tab, then multiple bugs open in multiple tabs at the same time on desktop.

This use case will still be supported. For example if you do a bookmark of one particular contact, it seems expected to open it into a separated window (except if UX disagree :)).

 

Maybe a better way to implement that would be to enable the context menu for app windows so that I can long-press on a contact in the contacts list and select "open in new window", swipe back to the contacts list with edge gestures, long-press to open another contact in another window. Then I can swipe between the two contacts.

I would <3 to enable by default such an item in our context menu!

 

Another use case is when I have my Facebook app open on one Facebook page in the background, then I deep link into another Facebook page. Rather than unload the first page, it opens in a second window. All the pages of the Facebook app are then grouped together in the task manager.

As mentioned in the answer to the first paragraph: this is something the the proposal is made for.
For the moment, there is a 'simulated' deep linking, but 'native' deep linking is what I'm aiming for.

[Michael Henretty]

I wanted to revive this discussion since I think it has an effect on how we move forward with gaia in the meantime as re-architecture work comes together with the new product vision for Ignite.

Since Cwiiis is active working on the Page Transition API, and assuming he can complete this work as part of the re-architecture, do we still need the Content Wrapper? According the Architecture Proposal wiki, we need the content wrapper for the following reasons:

• Page Transition API shim

Cwiis is working on this

• Behavior of Views
  • View is unloaded and forgotten when it is leaved
  • View is unloaded and put in the Back-Forward Cache when it is leaved
  • View is running in the background competing on the event loop
  • View is running in the background deprioritized on the event loop

I could be wrong but this seems like big work for the platform, especially the last two. Are these essential for the re-architecture plan?

• Single point of coordination for the the bridge
  • Error reporting for Servers

It seems like the service work could handle this responsibility. Or perhaps another sort of shared worker.

• Unbreakable navigation on capsule errors

If I understand this correctly, this means if there is a JS error in on of our views, the user can still navigate between views. If so, I think we can achieve this with traditional features of the web.

• Custom pre-rendering support

Again, service worker.

• Multiple layouts with one entry point

I'm not sure what this means?

• Unified navigation between user visible capsules of multiple apps

I'm hoping the page transition API covers the multiple apps case.

Perhaps this is already the plan, but it seems to me we are very close to being able to ditch the CW in favor of straight up web technologies. Is there any update about this?

[Etienne Segonzac]

On Mon, Apr 27, 2015 at 9:13 PM, Michael Henretty <mhen...@mozilla.com> wrote:

Since Cwiiis is active working on the Page Transition API, and assuming he can complete this work as part of the re-architecture, do we still need the Content Wrapper?

Wait, isn't Chris' work living in the Content Wrapper?