Skip to content
This repository has been archived by the owner on Oct 2, 2019. It is now read-only.

Race condition on multiple instances of running app #100

Open
marcoscaceres opened this issue Apr 29, 2013 · 16 comments
Open

Race condition on multiple instances of running app #100

marcoscaceres opened this issue Apr 29, 2013 · 16 comments
Labels

Comments

@marcoscaceres
Copy link
Contributor

Consider two windows of one application. Both have the Application object and registered onpause() handlers.

When a pause event is triggered, which handler will process first?

And if one handler calls exit(), then will the other handler be called before application quit?

This issue may also exist when a management app has got the app's Application object.

@marcoscaceres
Copy link
Contributor Author

See also/related: #98

@jmajnert
Copy link

Do we even allow having two windows from the same running application instance open? Note that this is different than having multiple instances of the same application running.

@marcoscaceres
Copy link
Contributor Author

Firefox OS currently does allow this (window.open() opens another viewport). Can you check in Tizen?

Here is the code I used (for a hosted web app):

<button onclick="window.open('test.html')">test - local </button>

Note that in firefox OS the open() causes the document to be overlaid ontop of the original application.

Screen Shot 2013-04-29 at 4 34 58 PM

@marcoscaceres
Copy link
Contributor Author

Note also that I can open both internal and external links.

@marcoscaceres
Copy link
Contributor Author

(not really related, but interesting: I was able to set "locaStorage" to a value in the window.open("test.html") window and then get it from the application once the pop-up window was closed).

@jmajnert
Copy link

In Tizen:

  • window.open() opens another viewport, scripts in the originating context keep running
  • external links are not blocked
  • localStorage works as expected - same origin documents share the same DB

@jmajnert
Copy link

In Tizen:

window.open() opens another viewport, scripts in the originating context keep running
external links are not blocked
localStorage works as expected - same origin documents share the same DB

Actually, depending on configuration, external links may or may not be blocked or opened in platform browser (separate process, no access to system APIs).

@poussa
Copy link

poussa commented May 8, 2013

In mobile, the window management is fairly trivial. If you open a new window, it is stacked on top of the old one. And you need to close the topmost window it in order to go back to the 'old/original' window.

However, in desktop the situation is more complex. That is, if window 'A' opens another window 'B', both of the windows can be visible at the same time. Also, the use can close either of the window at any time.

Currently, the specification does not deal with this (multi-window desktop case) at all. I think it is an important use case we need to address.

@seanlong
Copy link

seanlong commented May 8, 2013

IMO the "Application" interface design may make the app development tough in multiple-windows environment.

For instance, an application with multiple windows opened may want to save some log (i.e. application termination time) when terminate. Then every window needs to register the onterminate handler for the Application interface, in order to make sure the callback happens even when other windows were closed. And the handler itself could be difficult to write too, it will be developer's responsibility to make the log saving only happens once a time.

@seanlong
Copy link

seanlong commented May 8, 2013

related to #98, in multiple-windows environment what's the difference between a window.open(app_home_page), and a new instance of app with app_home_page? Will the Application interface reference to the same application?

@jmajnert
Copy link

jmajnert commented May 9, 2013

IMO the "Application" interface design may make the app development tough in multiple-windows environment.

You made a really good point here. I think the original design concept was that there can be only one Application object per application, and all references should point to it. In multiple-windows-per-app scenario we run into trouble, as any of the contexts can:

  • call the hide() method, which should logically hide all the windows belonging to that app
  • register a handler for any of the events, in which case even after a window is closed, the UA must keep it alive as long as the handler is registered.

related to #98, in multiple-windows environment what's the difference between a window.open(app_home_page), and a new instance of app with app_home_page? Will the Application interface reference to the same application?

I think if you do window.open(app_home_page) from within that app, you should get a new window running as part of the same app.

@seanlong
Copy link

...

  • register a handler for any of the events, in which case even after a window is closed, the UA must keep it alive as long as the handler is registered.

Agree. I think maybe that's why Chromium has event page for its packaged app.

I think if you do window.open(app_home_page) from within that app, you should get a new window running as part of the same app.

Then how about Application interface for multiple application instances? How to identify which Application refer to which instance?

@jmajnert
Copy link

Agree. I think maybe that's why Chromium has event page for its packaged app.

Yes. This interface and system message handling fits nice with the event page concept

@poussa
Copy link

poussa commented May 10, 2013

Chrome event page model for the packaged apps is handling the multi-windows case nicely. I think we should take a look of that and learn from it.

@hmin
Copy link

hmin commented Jun 20, 2013

@poussa I am studying the design principle of multiple window support in combination with chrome event page, and will work out an investigation report.

@marcoscaceres
Copy link
Contributor Author

@hmin @poussa yeah, we are thinking the same thing over on the Moz side. See @annevk's email on public-webapps.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants