Right now the openWindow method in apps/system/js/window_manager.js is relatively expensive. Some of the expensive calls are described in https://bugzilla.mozilla.org/show_bug.cgi?id=924337#c28. Hopefully Alive volunteered to fix it!

I am working on https://bugzilla.mozilla.org/show_bug.cgi?id=908601 now, would like to fix the style change during openingWindow there. The reason why we reflow(set width/height) during cold launch is we want to resolve bug 840147 and bug 877903. Briefly, we have some UI malfunction when we're opening landscape specific app. So what we do is rotate the appWindow frame and swap width and height. However that introduces bug 840126 and bug 873668. (Or something regresssed). Proposed fix: According to android, during a landscape app is opening the homescreen(background) becomes black. So if the frame is unloaded(cold boot), send an event to homescreenWindow to notify "an landscape app is going to open" (maybe just appwillopen event) and style the homescreen with blackoverlay, and removing the overlay on next closeWindow (appwillclose). In this case we don't need to set the width/height anymore before app is loading, and just apply the basic css rule according to th e class name list appending to #screen element, for example #screen.active-statusbar:not(.software-button-enabled) > #windows > .appWindow { top: 4rem; height: calc(100% - 4rem); width: 100%; }

(In reply to Alive Kuo [:alive] from comment #1) > I am working on https://bugzilla.mozilla.org/show_bug.cgi?id=908601 now, > would like to fix the style change during openingWindow there. > The reason why we reflow(set width/height) during cold launch is we want to > resolve bug 840147 and bug 877903. > Briefly, we have some UI malfunction when we're opening landscape specific > app. > So what we do is rotate the appWindow frame and swap width and height. > However that introduces bug 840126 and bug 873668. (Or something regresssed). > > Proposed fix: > According to android, during a landscape app is opening the > homescreen(background) becomes black. > So if the frame is unloaded(cold boot), send an event to homescreenWindow to > notify "an landscape app is going to open" (maybe just appwillopen event) > and style the homescreen with blackoverlay, and removing the overlay on next > closeWindow (appwillclose). Let's not send anything to the homescreen directly, for the moment the system app is in control of the background so it can do whatever it wants. I was hoping to implement parallax into the homescreen app though which will delegate the background responsibility to the homescreen :/ When bug 924032 comes up yesterday I was wondering about an event on the mgtm part of the mozApps API when an application is launched, but was unable to find a good use case out of the system app. This can be one but it does not convince me 100%. An other use case could be for the homescreen app to re-order the icons based on the number of launches of an application, but one could argue that the user usually click the icon on the homescreen itself so the homescreen has this information already. If there is more use cases we may want this event if we can convince Fabrice ;) About CSS proposal that sounds good to me, is there any reasons why we can not describe everything in CSS (except the additional complexity) ? > > In this case we don't need to set the width/height anymore before app is > loading, and just apply the basic css rule according to th e class name list > appending to #screen element, for example > > #screen.active-statusbar:not(.software-button-enabled) > #windows > > .appWindow { > top: 4rem; > height: calc(100% - 4rem); > width: 100%; > }

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #2) > (In reply to Alive Kuo [:alive] from comment #1) > > Let's not send anything to the homescreen directly, for the moment the > system app is in control of the background so it can do whatever it wants. I > was hoping to implement parallax into the homescreen app though which will > delegate the background responsibility to the homescreen :/ I don't understand this part, I'm talking about having a black overlay in homescreen iframe container, not homescreen app itself. My proposal: When setDisplayedApp(appWidnowA) is invoked: * appWindowA publish 'appcoldlaunch' event to HomescreenLauncher. HomescreenLauncher tells homescreenWindow calls fadeOut() HomescreenWindow displays the overlay. But this "won't affect mozBrowserFrame.setVisible() call". appWindowA just locks the screen orientation before opening window. appWindowA does the opening transition. (Does this cost much? I expect it isn't expensive than original setRotationTransition() ....) * On next HomescreenWindow instance close() request, remove the overlay. So what's the concern? A little hacky but I think it's caused by we don't have a smooth transition about OrientationChange. > When bug 924032 comes up yesterday I was wondering about an event on the > mgtm part of the mozApps API when an application is launched, but was unable > to find a good use case out of the system app. This can be one but it does > not convince me 100%. > > An other use case could be for the homescreen app to re-order the icons > based on the number of launches of an application, but one could argue that > the user usually click the icon on the homescreen itself so the homescreen > has this information already. > > If there is more use cases we may want this event if we can convince Fabrice > ;) This one is interesting but I don't need this API currently ;) I think you just misunderstood the proposal above. I won't send anything to the app itself. Now we have a 'wrapper' object for each app so let's take advantage of the instance. > > About CSS proposal that sounds good to me, is there any reasons why we can > not describe everything in CSS (except the additional complexity) ? > The only thing is we need to do rotation to 90 degree or 270 degree for a landscape app during its opening/closing transition we need to calculate the width/height otherwise the UI would be strange. But now 1. This is inneccessary in cold launch. 2. In warm launch case I was think about: (A) Do the same thing as cold launch (B) Build dynamical CSS rule as var style = document.createElement('style'); ``` var style = document.createElement('style'); style.type = 'text/css'; style.innerHTML = '.crossing-rotation { width: ' + window.innerHeight + 'px; height: ' + window.innerWidth + 'px; }'; document.getElementsByTagName('head')[0].appendChild(style); document.getElementById('app1').classList.add('crossing-rotation'); ``` I am still doing experiment but if you have concern please tell me in advance.

BTW, I think keyboard height is not a pre-define-able factor. The height of keyboard app is not controlled by us so we couldn't dynamically build the css style rule for it. We still need set height in javascript in this case, and since we have change the height, the previous applied rule doesn't work so after that we need to do call resize to correctly size the UI.

(In reply to Alive Kuo [:alive] from comment #3) > (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #2) > > (In reply to Alive Kuo [:alive] from comment #1) > > > > Let's not send anything to the homescreen directly, for the moment the > > system app is in control of the background so it can do whatever it wants. I > > was hoping to implement parallax into the homescreen app though which will > > delegate the background responsibility to the homescreen :/ > > I don't understand this part, I'm talking about having a black overlay in > homescreen iframe container, not homescreen app itself. Then forgot my comment :)

(In reply to Alive Kuo [:alive] from comment #4) > BTW, I think keyboard height is not a pre-define-able factor. The height of > keyboard app is not controlled by us so we couldn't dynamically build the > css style rule for it. We still need set height in javascript in this case, > and since we have change the height, the previous applied rule doesn't work > so after that we need to do call resize to correctly size the UI. Right but the keyboard should never be opened for a cold launch so the resize will only be for warm startup which is a bit less critical.

Most of the reflows are gone with bug 926871 and bug 926875. So let's resolve this one as a dup.