Re: My plan of System app-Window Manager Refactor/Cleanup/UI restructure

[Tim Chien]

Hi all,

I would like to bump this discussion a little bit. What Alive proposing is
still a draft but I would like to know if this is the right direction. I
have not go through with Alive on the specifics yet though.

Ideally, everything should be dynamic in a Firefox OS System app so people
can plug/unplug features at well. Besides, it could cut the HTML parsing
time significantly, and we could in turn cut the load time by lazily loads
the script.


Tim




On Wed, Jan 16, 2013 at 6:05 PM, alive <al...@mozilla.com> wrote:

> Hi all,
>
> Bug 824677 was landed for a while. It's a nontrivial patch to resolve some
> pain in showing error page and,
> what's more important, the first step to refactor our System app/Window
> Manager.
>
> ## Module pattern of Window Manager is unmanageable now. ##
> Hey, We are stacking workarounds one bug by one bug.
> Every time we have a new bug, we add some lines into Window Manager and
> Yay!
>
> Now time to stop workarounds and cleanup!
> I saw many workarounds in system app is landed because we have a tight
> schedule.
> Yes, workaround is adoptable. But also many regressions upcoming because
> workarounds were affecting each other workarounds..
> Now, it's nearly time to stop workarounds. And it's also time to stop make
> code size of window manager grow unlimitedly.
> As you know Window Manager is the core the system app.
> Now it is about 2000 lines.
> Nearly TL;DR…..
> anyone who is working on it may think this is really hard to trace(and
> lazy to trace…and regression coming!)
>
> ## Static DOM? Why not dynamic? ##
> I feel there's one thing that we should do but never did:
> Make every mozBrowser iframe or iframe which is provided by platform
> having specific tasks live in its own DOM element container, something like
> a <div>. Currently they are grouped together somewhere. This design is
> problematic.
>
> The targets include:
> A) A normal mozbrowser iframe [frameType="window"]
> B) Inline-actvity iframe [frameType="inline"]
> C) Popup dialog[frameType="popup"] (by window.open)
> D) Attention dialog[frameType="attention"] (by window.open with
> 'attention' specified)
> E) Wrapper[frameType='wrapper"…but now it's identified as dataset.wrapper]
> (a bookmark when you choose to bookmark to home screen in browser app)
>
> ## We should know that some dialogs are app-specific and some dialogs are
> system-specific ##
> ### App specific dialogs ###
> 1) Modal Dialog(Alert, confirm, prompt, custom_dialog)
> 2) Error Dialog/Overlay(Tells you that we have network error when loading
> the app page)
> 3) Popup!(By window.open)
> 3.1) Note that an iframe in Popup could also have modal dialogs or error
> overlays.
> 4) Inline Activity!(By design, an inline activity is tightened to the
> caller app. Any inline activities should be canceled/closed if we leave the
> caller app. I had a patch to enable multiple inline activities on single
> app already.
> 4.1) Note that an inline activity frame should have the ability to open
> popup also modal dialogs and error overlays.
> 5) Attention screen(!)
> IMO This is just a special version of popup. It's belong to an app.
> What's different is it's beyond any opened app.
> In the case of dialer, it tries to have the call screen of attention
> screen has its own slide transition.
> I would say this is app specific. The transition of app attention
> screen could be used to replace the app open transition.
> 5.1) As you know attention screen has an active status bar. I would say
> this should be moved to status bar. But still under design.
> 6) Trusted UI(Payment or Persona login)
> 7) Custom Dialog
>
> ### Maybe System-wide ###
> * Permission Screen - Josh tells me this is still under consideration.
> Currently the implementation of permission dialog in platform doesn't
> tell which iframe it's currently happening -- I begin to believe this is
> intentional if we confirm that any permission dialog should be system wide.
>
> ### System-wide dialog ###
> * SIM-PIN Dialog
> * Crash Report
> * System update prompt
>
> We are now make everything `singleton`ed in system/index.html
> And use 'appopen' or 'appwillopen' event fired by window manager to deal
> with app switching case to determine show them or not.
> * It's bad on UX because when the app is transitioning, the app-specific
> dialog should be transitioned as well as it could.
>
> We could just resize the app Window who contains any dialog in its
> container regardless to what's being displayed.
> As you know, resize related events are restrict to two factors
> 1) Global factor:
> 1.1) orientation change
> 1.2) status bar height
> 1.3) Fullscreen status
> 2) App factor:
> 2.1) Keyboard height - it's belong to app I believe.
> We could avoid resize every time appopen event fired. The dialog in a
> certain app would be resized natively if the app container is resized.
>
> ## Gather mozBrowser API ##
> We have much function work relying on mozbrowser API and mozbrowser frames.
> * mozbrowsererror
> * mozbrowsershowmodalprompt
> * mozbrowserloadstart
> * mozbrowserloadend
> * mozbrowsercontextmenu
> * mozbrowseropenwindow
> * mozbrowserclose
> * mozbrowserusernameandpasswordrequired
>
> These events handler are everywhere in system app in many modules.
> Do we have a chance to gather it together to avoid rewrite event handler
> everywhere? Yes I think.
>
> ## Visibility change ##
> We know that setVisible is also part of Browser API. Now window manager is
> in charge of change the visibility of every mozbrowser iframe by some
> complex code paths. And there are also some cases/bugs are not being found
> now.
> For example, if we are having two activities at the same time, currently
> we don't setVisible(false) to the activity frame under the most top one.
> This is undefined because some app(Communications - Contact) is using
> mozvisibilitychange to close itself :O I don't think this is needed to be
> avoided. We still need to investigate this.
>
> ## Home button events and hold home events ##
> Now this is not severe -- many effort had be done to keep 'home button'
> really returns the user to home screen now.
> However, if one day we could make hardware events deliver to app itself -
> that would be reasonable to deliver it in window manager to appWindow.
>
> ## Transition relevant to app/inline activity/.…
> Tim does a good job in implemanting app transition.
> But IMO the transition is belong to appWindow and could be controlled by
> Window Manager by class addition/remove.
> With this, we could 'replace' the openTransition of specific app if
> necessary.
> For example:
> 1) SIM PIN dialog: Replace the zoom-in transition of an appWindow touches
> SIM function with SIM PIN Dialog transitions(like window.open transition)
> 2) Trusted UI dialog: Replace the zoom-in transition of its appWindow
> 3) Call screen: Replace the zoom-in transition of its appWindow by
> slide-down transition
>
> ## Hierarchy manager(dynamic z-index assign) ##
> * If we are creating DOM elements dynamically, it's reasonable to have a
> "z-index assigner" when a new overlay is created.
> For example, if we have the attention screen belong to the app itself, the
> only way to have it displayed upon other app is to assign the attention
> screen
>
> ## So what we could do? What's the plan? What's the next? ##
> * Make (all) mozbrowser iframe be contained in its own container instead
> of '#windows'.
> * Make everything as being an object pattern if possible.
> * Make every `AppWindow` be in charge of dispatching events like
> 'appopen', 'appwillopen', 'appclose'
> * Make Window Manager be in charge of managing cross-app events, gathering
> the events firing by an AppWindow instance and then to determine what's
> going to be done if some events are meeting each other. Yes, a Finite State
> Machine!
> * Move FTU logic out of Window Manager. It's not reasonable to have FTU
> occupied in Window Manager.
> * Move TrustedUI logic out of Window Manager
> * Make Wrapper relevant DOM elements live in appWindow container
> * Move createFrame/open transition/close transition into appWindow objects.
>
> ### The patterns of Window Manager ###
> 1. Global Event Listener to all the elements under '#windows'
> 2. App Switch Manager - bring app to foreground by calling app.open() or
> app.close(). Determine who is 'displayedApp'.
> 3. App Launcher - Launch an app if needed.(include FTU, Homescreen,
> Wrapper, normal app…)
> 4. Resize Manager
> 5. Hierarchy Manager
> 6. Manage system-wide dialogs(fire events)
> 7. Expose reasonable properties.
>
> ### The responsibility of appWindow and appDialog ###
> 1. Create iframe, set suitable attributes
> 2. Create DOM elements/objects if needed. e.g.
> wrapper-header/wrapper-footer, error dialog, modal dialog…
> 3. Event listener to mozbrowser* events
> 4. Event listener to the elements under this container, e.g., click event
> handler.
> 5. resize
> 6. setHeight
> 7. setVisibility
> 8. Fire app* events if the event is belong to the container.
> IMO, in the long run we don't need these events -- at least could be
> limited to a very small amount.
>
> ### Final Structures for example ###
> - Window Manager
> - new AppWindow();
> - new AppWindow(frameType=wrapper) or new Wrapper();
> - new AppWindow();
> - new ModalDialog();
> - new AppError();
> - new ContextMenu();
> - new TrustedUI();
> - new Modal Dialog();
> - new AppError();
> - new InlineActivity();
> - new Popup();
> - new InlineActivity(); // Multiple inline activity I mean
> - new ModalDialog();
> - new AppError();
> - new Popup();
> - new ModalDialog();
> - new AppError();
>
>
>
> Some of these ideas are still draft.
> I think I should make a slide about this plan for others to understand
> easily, but I rather throws these ideas by pure text first.
>
> - Alive
>
>
>


--
Tim Guan-tin Chien, Senior Front-end Dev., Mozilla Corp. (Taiwan)

[Salvador de la Puente González]

Hello folks

This really interests me and I'm answering inline.

On 16/01/13 11:05, alive wrote:

Hi all,

Bug 824677 was landed for a while. It's a nontrivial patch to resolve some pain in showing error page and,
what's more important, the first step to refactor our System app/Window Manager.

## Module pattern of Window Manager is unmanageable now. ##

This is because we don't have a real module architecture here. We have js files but we don't have a way to plug, manage or remove modules. If we want a module architecture here, we should deeply think about what is a module, its requirements, how to pack one, how to plug one and so on...

Hey, We are stacking workarounds one bug by one bug.
Every time we have a new bug, we add some lines into Window Manager and Yay!

Now time to stop workarounds and cleanup!
I saw many workarounds in system app is landed because we have a tight schedule.

Although I agree with we need to stop workarounds, given our tight schedule we should limit the scope and carefully distinguish what is a new feature and what is a bug. I we are going to refactor the system application we need a list of cases and tests with almost complete coverage and we should write those tests before. But, specially, we need the list cases: Which capabilities the system should offer to applications? The lists included of window types made by Alive are good examples of these lists of cases but they are not comprehensive. I.e: I.e: What about system message handlers? Should they be normal `mozbrowser` iframes? What about "special windows hooks" such as the keyboard div, FTU window, lock screen...?

I think Alive has done a very good work trying to list all the functionalities the system application currently does. I stripped out the contents of each point to highlight the list of features.

## Static DOM? Why not dynamic? ##

The targets include:
A) A normal mozbrowser iframe [frameType="window"]
B) Inline-actvity iframe [frameType="inline"]
C) Popup dialog[frameType="popup"] (by window.open)
D) Attention dialog[frameType="attention"] (by window.open with 'attention' specified)
E) Wrapper[frameType='wrapper"…but now it's identified as dataset.wrapper] (a bookmark when you choose to bookmark to home screen in browser app)

### App specific dialogs ###

### Maybe System-wide ###
### System-wide dialog ###

As you know, resize related events are restrict to two factors
1) Global factor:
1.1) orientation change
1.2) status bar height
1.3) Fullscreen status
2) App factor:
2.1) Keyboard height - it's belong to app I believe.

## Gather mozBrowser API ##

## Visibility change ##

## Home button events and hold home events ##

## Transition relevant to app/inline activity/.…

## Hierarchy manager(dynamic z-index assign) ##

But I think we should review this, check with UX if we are covering all the user cases and, if so, then starting to write some tests.

## So what we could do? What's the plan? What's the next? ##

All Alive is saying here make sense to me but If we are moving to a real module pattern, let's first define what is a module as I said before. Furthermore I think this is related with a pending discussion about what is an application (because this implies how to track an application is open: its manifest, its URL, its hash...), and what is an entry point (and, what is a system message handler) and how these special cases of windows should be managed.

### Final Structures for example ###
- Window Manager
- new AppWindow();
- new AppWindow(frameType=wrapper) or new Wrapper();
- new AppWindow();
- new ModalDialog();
- new AppError();
- new ContextMenu();
- new TrustedUI();
- new Modal Dialog();
- new AppError();
- new InlineActivity();
- new Popup();
- new InlineActivity(); // Multiple inline activity I mean
- new ModalDialog();
- new AppError();
- new Popup();
- new ModalDialog();
- new AppError();

We should define this in an API fashion with each element part of the system.

And that's all, these are me general impressions about the System refactor.

Hope it helps.

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Vivien]

On 21/01/2013 05:32, Tim Chien wrote:
> Hi all,
>
> I would like to bump this discussion a little bit. What Alive
> proposing is still a draft but I would like to know if this is the
> right direction. I have not go through with Alive on the specifics yet
> though.
>

It's on my list of things to read and thinks about. I would like 1.0.0
to be out of the box before spending too much time in this but you can
expect an answer from me next week.

Vivien.

> Ideally, everything should be dynamic in a Firefox OS System app so
> people can plug/unplug features at well. Besides, it could cut the
> HTML parsing time significantly, and we could in turn cut the load
> time by lazily loads the script.
>
>
> Tim
>
>
>
>
> On Wed, Jan 16, 2013 at 6:05 PM, alive <al...@mozilla.com

> <mailto:al...@mozilla.com>> wrote:
>
> Hi all,
>
> Bug 824677 was landed for a while. It's a nontrivial patch to
> resolve some pain in showing error page and,
> what's more important, the first step to refactor our System
> app/Window Manager.
>
> ## Module pattern of Window Manager is unmanageable now. ##

> Hey, We are stacking workarounds one bug by one bug.
> Every time we have a new bug, we add some lines into Window
> Manager and Yay!
>
> Now time to stop workarounds and cleanup!
> I saw many workarounds in system app is landed because we have a
> tight schedule.

> Yes, workaround is adoptable. But also many regressions upcoming
> because workarounds were affecting each other workarounds..
> Now, it's nearly time to stop workarounds. And it's also time to
> stop make code size of window manager grow unlimitedly.
> As you know Window Manager is the core the system app.
> Now it is about 2000 lines.
> Nearly TL;DR…..
> anyone who is working on it may think this is really hard to
> trace(and lazy to trace…and regression coming!)
>

> ## Static DOM? Why not dynamic? ##

> I feel there's one thing that we should do but never did:
> Make every mozBrowser iframe or iframe which is provided by
> platform having specific tasks live in its own DOM element
> container, something like a <div>. Currently they are grouped
> together somewhere. This design is problematic.
>

> The targets include:
> A) A normal mozbrowser iframe [frameType="window"]
> B) Inline-actvity iframe [frameType="inline"]
> C) Popup dialog[frameType="popup"] (by window.open)
> D) Attention dialog[frameType="attention"] (by window.open with
> 'attention' specified)
> E) Wrapper[frameType='wrapper"…but now it's identified as
> dataset.wrapper] (a bookmark when you choose to bookmark to home
> screen in browser app)
>

> ## We should know that some dialogs are app-specific and some
> dialogs are system-specific ##

> ### App specific dialogs ###

> As you know, resize related events are restrict to two factors
> 1) Global factor:
> 1.1) orientation change
> 1.2) status bar height
> 1.3) Fullscreen status
> 2) App factor:
> 2.1) Keyboard height - it's belong to app I believe.

> We could avoid resize every time appopen event fired. The dialog
> in a certain app would be resized natively if the app container is
> resized.
>

> ## Gather mozBrowser API ##

> We have much function work relying on mozbrowser API and
> mozbrowser frames.
> * mozbrowsererror
> * mozbrowsershowmodalprompt
> * mozbrowserloadstart
> * mozbrowserloadend
> * mozbrowsercontextmenu
> * mozbrowseropenwindow
> * mozbrowserclose
> * mozbrowserusernameandpasswordrequired
>
> These events handler are everywhere in system app in many modules.
> Do we have a chance to gather it together to avoid rewrite event
> handler everywhere? Yes I think.
>
> ## Visibility change ##
> We know that setVisible is also part of Browser API. Now window
> manager is in charge of change the visibility of every mozbrowser
> iframe by some complex code paths. And there are also some
> cases/bugs are not being found now.
> For example, if we are having two activities at the same time,
> currently we don't setVisible(false) to the activity frame under
> the most top one. This is undefined because some
> app(Communications - Contact) is using mozvisibilitychange to
> close itself :O I don't think this is needed to be avoided. We
> still need to investigate this.
>

> ## Home button events and hold home events ##

> Now this is not severe -- many effort had be done to keep 'home
> button' really returns the user to home screen now.
> However, if one day we could make hardware events deliver to app
> itself - that would be reasonable to deliver it in window manager
> to appWindow.
>

> ## Transition relevant to app/inline activity/.…

> Tim does a good job in implemanting app transition.
> But IMO the transition is belong to appWindow and could be
> controlled by Window Manager by class addition/remove.
> With this, we could 'replace' the openTransition of specific app
> if necessary.
> For example:
> 1) SIM PIN dialog: Replace the zoom-in transition of an appWindow
> touches SIM function with SIM PIN Dialog transitions(like
> window.open transition)
> 2) Trusted UI dialog: Replace the zoom-in transition of its appWindow
> 3) Call screen: Replace the zoom-in transition of its appWindow by
> slide-down transition
>

> ## Hierarchy manager(dynamic z-index assign) ##

> * If we are creating DOM elements dynamically, it's reasonable to
> have a "z-index assigner" when a new overlay is created.
> For example, if we have the attention screen belong to the app
> itself, the only way to have it displayed upon other app is to
> assign the attention screen
>

> ## So what we could do? What's the plan? What's the next? ##

> ### Final Structures for example ###
> - Window Manager
> - new AppWindow();
> - new AppWindow(frameType=wrapper) or new Wrapper();
> - new AppWindow();
> - new ModalDialog();
> - new AppError();
> - new ContextMenu();
> - new TrustedUI();
> - new Modal Dialog();
> - new AppError();
> - new InlineActivity();
> - new Popup();
> - new InlineActivity(); // Multiple inline activity I mean
> - new ModalDialog();
> - new AppError();
> - new Popup();
> - new ModalDialog();
> - new AppError();
>
>
>

[Alive Kuo]

Comments inline!

Salvador de la Puente González 於 2013/1/21 下午5:43 寫道：

> Hello folks
>
> This really interests me and I'm answering inline.
>

> On 16/01/13 11:05, alive wrote:
>> Hi all,
>>
>> Bug 824677 was landed for a while. It's a nontrivial patch to resolve some pain in showing error page and,
>> what's more important, the first step to refactor our System app/Window Manager.
>>
>> ## Module pattern of Window Manager is unmanageable now. ##

> This is because we don't have a real module architecture here. We have js files but we don't have a way to plug, manage or remove modules. If we want a module architecture here, we should deeply think about what is a module, its requirements, how to pack one, how to plug one and so on…

True.

Our module management in system app is nothing now…for example, lock screen is loaded before window manager.
When it refers window manager's public function in its init function or following function calls, an error would happen.

I am thinking using AMD/requireJS as the module management, but it's also a little heavy.
We anyway don't want a heavy management system in system app, because this would affect the performance of whole system.
This is one reason we don't have module architecture I think. Another is system app is changing too fast in the past one year. :)

Maybe we could create a lightweight module loader if we really want one.

>> Hey, We are stacking workarounds one bug by one bug.
>> Every time we have a new bug, we add some lines into Window Manager and Yay!
>>
>> Now time to stop workarounds and cleanup!
>> I saw many workarounds in system app is landed because we have a tight schedule.

> Although I agree with we need to stop workarounds, given our tight schedule we should limit the scope and carefully distinguish what is a new feature and what is a bug. I we are going to refactor the system application we need a list of cases and tests with almost complete coverage and we should write those tests before. But, specially, we need the list cases: Which capabilities the system should offer to applications? The lists included of window types made by Alive are good examples of these lists of cases but they are not comprehensive. I.e: I.e: What about system message handlers? Should they be normal `mozbrowser` iframes? What about "special windows hooks" such as the keyboard div, FTU window, lock screen…?

Let's distinguish by what's the mission the system message is going to complete.
Basically, a system message is being a bridge between gecko and system app to communicate something.
It should be UI-less. If we need an UI upon this task, we should create a new module or utilize current module.

Why UI-specific is important? Because we need to manage all UI layers in system app.
So every different UI is worthy to have a new module and have it own rendering function(give parameters).

>
> I think Alive has done a very good work trying to list all the functionalities the system application currently does. I stripped out the contents of each point to highlight the list of features.

>> ## Static DOM? Why not dynamic? ##

>> The targets include:
>> A) A normal mozbrowser iframe [frameType="window"]
>> B) Inline-actvity iframe [frameType="inline"]
>> C) Popup dialog[frameType="popup"] (by window.open)
>> D) Attention dialog[frameType="attention"] (by window.open with 'attention' specified)
>> E) Wrapper[frameType='wrapper"…but now it's identified as dataset.wrapper] (a bookmark when you choose to bookmark to home screen in browser app)

>> ### App specific dialogs ###

>> ### Maybe System-wide ###
>> ### System-wide dialog ###

>> As you know, resize related events are restrict to two factors
>> 1) Global factor:
>> 1.1) orientation change
>> 1.2) status bar height
>> 1.3) Fullscreen status
>> 2) App factor:
>> 2.1) Keyboard height - it's belong to app I believe.

>> ## Gather mozBrowser API ##

>> ## Visibility change ##

>> ## Home button events and hold home events ##

>> ## Transition relevant to app/inline activity/.…

>> ## Hierarchy manager(dynamic z-index assign) ##

> But I think we should review this, check with UX if we are covering all the user cases and, if so, then starting to write some tests.

Yes, I forgot to mention tests in original post.
Tests are important if we want to do such significant change.
I am still learning how to write tests now :)

About the user cases coverage, in my opinion we could only do the best to try to cover all but it's very ideal.
For example, when inline activity was designed and implemented, nobody could tell if we are going to support multiple inline activities.
So it was implemented as 'only one activity could be triggered at one time.'
But we have bug 824615, which have 2 activities at the same --
finally I had made the patch based on previous 'one-activity' design to enable multiple activities.

However, it's not perfect. We have problems that I had mentioned in original post, the visibility of activity isn't set well.
See bug 833211, which may touches a lost piece that we don't setVisible to inline activity frame if there're more than one frames.

>> ## So what we could do? What's the plan? What's the next? ##

> All Alive is saying here make sense to me but If we are moving to a real module pattern, let's first define what is a module as I said before. Furthermore I think this is related with a pending discussion about what is an application (because this implies how to track an application is open: its manifest, its URL, its hash...), and what is an entry point (and, what is a system message handler) and how these special cases of windows should be managed.

#### about entry points ####

As far as I know, entry point is a special couples of apps that living in the same origin.
We had some troubles in entry points too.
We had to parse the manifest in window manager before..ManifestHelper does help on this stuff. Thanks to Margaret.

What I concern is, which property in entry points is shared by all apps, and which property should be app-specific?
We had moved the locales and fullscreen property into app specific in two different bugs.
I wonder there're more TBD properties.

It's worthy to have another thread on this.

#### about origin ####

About manifestURL/origin/hash/hostname to identify an app, this is a pain also.
Not one of them could really identify an app.

So what we should do is like:

Make AppWindow.id a public attribute/function, then redirect to the real identifier in its inner functions if in the long run we have the answer to this question.
We should discard (AppWindow.)origin in the future.

>> ### Final Structures for example ###
>> - Window Manager
>> - new AppWindow();
>> - new AppWindow(frameType=wrapper) or new Wrapper();
>> - new AppWindow();
>> - new ModalDialog();
>> - new AppError();
>> - new ContextMenu();
>> - new TrustedUI();
>> - new Modal Dialog();
>> - new AppError();
>> - new InlineActivity();
>> - new Popup();
>> - new InlineActivity(); // Multiple inline activity I mean
>> - new ModalDialog();
>> - new AppError();
>> - new Popup();
>> - new ModalDialog();
>> - new AppError();

> We should define this in an API fashion with each element part of the system.
>
> And that's all, these are me general impressions about the System refactor.
>
> Hope it helps.

Thanks for your reply! I really lost something in the first post.

>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Alive C. Kuo, Front end engineer, Mozilla Taiwan
al...@mozilla.com

[Julien Wajsberg]

Le 22/01/2013 11:44, Alive Kuo a écrit :
> #### about origin ####
>
> About manifestURL/origin/hash/hostname to identify an app, this is a pain also.
> Not one of them could really identify an app.

I believe the manifestURL really identifies an app uniquely.

What's a pain is that we have origin for that in some parts of the code,
which is wrong. In v1 we had to disable the installation of an hosted
app if it was on in the same origin than one that is already installed,
which will be a problem. So this is a must-change-soon feature ;)

--
Julien

[Vivien]

On 22/01/2013 11:44, Alive Kuo wrote:
> Comments inline!
>
> Salvador de la Puente González 於 2013/1/21 下午5:43 寫道：
>
>> Hello folks
>>
>> This really interests me and I'm answering inline.
>>
>> On 16/01/13 11:05, alive wrote:
>>> Hi all,
>>>
>>> Bug 824677 was landed for a while. It's a nontrivial patch to resolve some pain in showing error page and,
>>> what's more important, the first step to refactor our System app/Window Manager.
>>>
>>> ## Module pattern of Window Manager is unmanageable now. ##
>> This is because we don't have a real module architecture here. We have js files but we don't have a way to plug, manage or remove modules. If we want a module architecture here, we should deeply think about what is a module, its requirements, how to pack one, how to plug one and so on…
> True.
>
> Our module management in system app is nothing now…for example, lock screen is loaded before window manager.
> When it refers window manager's public function in its init function or following function calls, an error would happen.
>
> I am thinking using AMD/requireJS as the module management, but it's also a little heavy.
> We anyway don't want a heavy management system in system app, because this would affect the performance of whole system.
> This is one reason we don't have module architecture I think. Another is system app is changing too fast in the past one year. :)

The real reason is because Harmony modules are coming
(https://bugzilla.mozilla.org/show_bug.cgi?id=568953) and I feel like
that's what we should use and give feedbacks on.

Vivien.

[Julien Wajsberg]

Le 22/01/2013 11:52, Vivien a écrit :
> The real reason is because Harmony modules are coming
> (https://bugzilla.mozilla.org/show_bug.cgi?id=568953) and I feel like
> that's what we should use and give feedbacks on.

So we should switch to the gecko-21 tree soon ? Or rather backport these
changes in our beloved b2g18 branch ?

[Salvador de la Puente González]

Hello Julien

On 22/01/13 11:51, Julien Wajsberg wrote:
> Le 22/01/2013 11:44, Alive Kuo a écrit :
>> #### about origin ####
>>
>> About manifestURL/origin/hash/hostname to identify an app, this is a
>> pain also.
>> Not one of them could really identify an app.
>
> I believe the manifestURL really identifies an app uniquely.

AFAIK this is not entirely true. See communications, for instance. There
is only one manifest but several entry points characterized by different
properties (launchpath, locales...) and you can have both phone and
contacts opened at the same time. This approach is needed because you
need to share some information across different "applications". I'm not
saying this is the best way to do it but only pointing it out. So I
think the application definition need a deep review.

Bests.

________________________________

[Julien Wajsberg]

Le 22/01/2013 11:59, Salvador de la Puente González a écrit :
> Hello Julien
>
> On 22/01/13 11:51, Julien Wajsberg wrote:
>> Le 22/01/2013 11:44, Alive Kuo a écrit :
>>> #### about origin ####
>>>
>>> About manifestURL/origin/hash/hostname to identify an app, this is a
>>> pain also.
>>> Not one of them could really identify an app.
>>
>> I believe the manifestURL really identifies an app uniquely.
> AFAIK this is not entirely true. See communications, for instance. There
> is only one manifest but several entry points characterized by different
> properties (launchpath, locales...) and you can have both phone and
> contacts opened at the same time. This approach is needed because you
> need to share some information across different "applications". I'm not
> saying this is the best way to do it but only pointing it out. So I
> think the application definition need a deep review.

yep that's right.

From gecko's point of view, this is really one application, also for
the System app. However for the Homescreen this is true that the
entry_points stuff are confusing. That's why they are forbidden for 3rd
party apps BTW :)

[David Flanagan]

On 1/20/13 8:32 PM, Tim Chien wrote:
> Hi all,
>
> I would like to bump this discussion a little bit. What Alive
> proposing is still a draft but I would like to know if this is the
> right direction. I have not go through with Alive on the specifics yet
> though.
>

> Ideally, everything should be dynamic in a Firefox OS System app so
> people can plug/unplug features at well. Besides, it could cut the
> HTML parsing time significantly, and we could in turn cut the load
> time by lazily loads the script.
>
>
> Tim
>

Like Vivien, I have not made the time to read this yet. But what you
say above makes me curious: is HTML parsing time actually a significant
performance issue? Is it a goal to reduce system startup time? Just
last week I found a bug in the Settings app caused by its lazy loading
of modules. So dynamically loaded system modules make me nervous.

David

[James Burke]

On Tue, Jan 22, 2013 at 2:52 AM, Vivien <vnic...@mozilla.com> wrote:
>> Our module management in system app is nothing now…for example, lock
>> screen is loaded before window manager.
>> When it refers window manager's public function in its init function or
>> following function calls, an error would happen.
>>
>> I am thinking using AMD/requireJS as the module management, but it's also
>> a little heavy.
>> We anyway don't want a heavy management system in system app, because this
>> would affect the performance of whole system.
>> This is one reason we don't have module architecture I think. Another is
>> system app is changing too fast in the past one year. :)
>
>

> The real reason is because Harmony modules are coming
> (https://bugzilla.mozilla.org/show_bug.cgi?id=568953) and I feel like that's
> what we should use and give feedbacks on.

If anyone does not want to wait for harmony modules to complete,
instead of writing your own module system or ad-hoc loading mechanism,
I strongly encourage you to use a standard module syntax and a loader
that has some tests behind it and wider use. If using AMD, it should
also be easy to convert AMD modules to ES modules, whenever they do
become available.

I recently created an AMD loader that is 30% smaller than requirejs,
but still passes almost all of its tests:

https://github.com/requirejs/alameda

It also has a Promises A+ implementation that you can use in your app,
so if you are using promises, you can save some more size by using it:

https://github.com/requirejs/alameda#api

James