RE: Request to make one proposal for execution model and security model

> -----Original Message-----
> From: Mounir Lamouri [mailto:mounir@lamouri.fr]
> Sent: Wednesday, February 20, 2013 3:01 AM
> To: public-sysapps@w3.org
> Subject: Re: Request to make one proposal for execution model and 
> security model

[...]

>>   * Browsing Context Management *
>>   1) Should runtime allow multiple windows opened concurrently?
>>     1-a) How to manage them (from UI perspective)?
> 
> I think we need implementations feedback for that. Is Tizen and
> Webinos only allow to see one application at a time? Firefox OS only
> shows one application at a time (except some very specific cases) and
> only shows one application window at a time. Like Android would do.

The mobile profile of Tizen will show one application at a time (while the other profiles like TV or PC may not be true). Even within the mobile environment, one application can have multiple windows opened at a time but stacked in such a way that the user can only see the top-most window ("top" in the sense of window stack, but not in HTML5 browsing context sense). In this case, I think it's valuable to highlight in the spec how the runtime will manage the multiple windows.

>From UI perspective, I think runtime can do nothing much but let the application developer to properly manage the navigations among multiple windows (by considering h/w form factors also, like the presence of "back" key or no). We probably put a "note" section in the specification to convey this message/concern to developers, if the group thinks it's required.

>From lifecycle perspective, I think it needs to be elaborated more in the proposed FPWD [1]. Please find more detailed description in next section. 

[1] http://mounirlamouri.github.com/sysapps/proposals/RunTime-Security/Overview.html 

>>     1-b) Do all of them receive lifecycle events or only the main
> browsing context?
> 
> Why not only the Application object?

We probably mixed up the lifecycle events with System Messages (Mozilla proposal) here. For lifecycle events like "pause" and "resume", they will be fired on the application object. But for System Messages, I found that the proposed FPWD did not specify how the message can be delivered to a page (or window). 

It seems that Mozilla did some analysis on this scenario [2], in which it is mentioned that an application can specify pages in manifest to indicate which messages should be delivered to which page. But clearly this is not in the proposed FPWD. In addition to the discussion thread [2], I think the behavior needs to be extended to consider the application lifecycle states and multiple windows. For example, at the time of a system message arrival, the application might be in "paused" state, and the corresponding page might be already loaded in a window but is not on the top of the window stack. One possible behavior of the runtime for this scenario could be: resume the application and deliver the message to the right page/window and, if necessary, put the window on top of the window stack. I can help to elaborate more on the possible scenarios if the group think it's required.

[2] https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/o8bkwx0EtmM 

>>   * Runtime Security *
>>   CSP Policy resolution from different sources (http header,
>> manifest,
> runtime default), Cross Origin Relaxation, etc.
> 
> That's definitely in scope.

But I don't see any combination algorithm for multiple CSP sources (runtime default, manifest, http) specified somewhere in the proposed FPWD. Please correct me if I am wrong.

>>   * Advanced Execution Model * for next version
>>   Execution model for background service page (which is covered only
>> by Google strawman proposal)
> 
> We haven't figure that out yet at Mozilla. Any feedback from Webinos
> or Tizen would be interesting.

Unfortunately, it's not fully explored in Tizen yet. As stated above, I think this can be considered in next version, by when we might have multiple solutions or prototypes available.

Regards,
Ming Jin

Received on Sunday, 24 February 2013 22:51:12 UTC