Closed Bug 939695 Opened 11 years ago Closed 6 years ago

Pre-create a template <iframe mozbrowser> in the system app

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: vingtetun, Unassigned)

References

Details

Attachments

(2 files)

Gaia POC
14.92 KB, patch
Details | Diff | Splinter Review
Gecko POC
20.76 KB, patch
Details | Diff | Splinter Review 
As said in bug 924337, there is a last reflow that happens when an application is launched. This one happens because the iframe that host the app is created and inserted just before launching the app. Pre-creating an iframe in the system app will help by moving the reflow to a less critical time and by also splitting the <iframe mozbrowser> initialization in 2 times. One for creating it, one for loading real content in it.

This is a bit tricky to do though since the current code assume the iframe is immutable once it has been created and all the permissions system broke if we break this assertion for now.

But since this stuff move the template app from ~150/160ms to ~110/120ms it worth playing with it. It changes a lot the look of the profile for app startup and so it also worth landing this before optimizing for the stuff that will belongs to the first part of the initialization of the iframe mozbrowser.
In the Gecko part there is Fabrice's patch to fire an observer when the preallocated process is launched. I qrefresh'ed a bit eagerly and add my changes to it.
Vivien is this still valid and worth continuing?
Flags: needinfo?(21)
(In reply to Dietrich Ayala (:dietrich) from comment #4)
> Vivien is this still valid and worth continuing?

In my previous measurement it was a 40ms win on the template app. Afaik nothing has changed on the platform side that would make that cheaper, and removing the reflow that happens in the system app when the iframe is added to the dom is not really doable without pre-attaching the iframe.

so I would say yes. Do you have some free time to work on that ? The patches here are a bit a mess and I can help to revive them if needed.
Flags: needinfo?(21)
If we only look at reflows, here's what happens when launching a very simple app (Stylish is just a page with a few links):

We have a "big" reflow when displaying the page, but I don't think we can prevent that. Once we are done with reflowing stylish, we have two small ones in the system app. Vivien does that match what you saw? (and yeah, we waste 15ms reflowing about:blank in the preallocated process - not sure if that's something that could be avoided or not).

I/Gecko:ProcessPriorityManager(  496): [Stylish, child-id=6, pid=762] Changing priority from BACKGROUND:CPU_NORMAL to FOREGROUND:CPU_NORMAL.
I/Gecko:ProcessPriorityManager(  496): KillBackgroundApps
I/Gecko   (  496): [Parent 496] WARNING: waitpid failed pid:762 errno:10: file /home/fabrice/dev/mozilla-b2g28_v1_3t/ipc/chromium/src/base/process_util_posix.cc, line 254
I/Gecko   (  496): PresShell::DoReflow() 3.11ms interruptible app://system.gaiamobile.org/index.html
I/Gecko   (  496): PresShell::DoReflow() 2.55ms uninterruptible app://system.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 0.00ms interruptible about:blank
I/Gecko:ProcessPriorityManager(  496): [Homescreen, child-id=2, pid=557] Changing priority from FOREGROUND:CPU_NORMAL to BACKGROUND_HOMESCREEN:CPU_NORMAL.
E/GeckoConsole(  762): [JavaScript Warning: "Content Security Policy: The page's settings blocked the loading of a resource: An attempt to execute inline scripts has been blocked" {file: "app://stylish.gaiamobile.org/index.html" line: 0 column: 0 source: "onclick attribute on BUTTON element"}]
I/Gecko   (  762): PresShell::DoReflow() 94.72ms uninterruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 0.22ms uninterruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 0.17ms uninterruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 1.79ms interruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 0.19ms interruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 0.34ms interruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 1.87ms interruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 0.20ms interruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  762): PresShell::DoReflow() 0.73ms interruptible app://stylish.gaiamobile.org/index.html
I/Gecko   (  496): PresShell::DoReflow() 3.94ms interruptible app://system.gaiamobile.org/index.html
I/Gecko   (  496): PresShell::DoReflow() 2.29ms interruptible app://system.gaiamobile.org/index.html
I/Gecko:ProcessPriorityManager(  496): [(Preallocated), child-id=7, pid=1656] Creating ParticularProcessPriorityManager.
I/Gecko:ProcessPriorityManager(  496): [(Preallocated), child-id=7, pid=1656] Done starting up.  mHoldsCPUWakeLock=0, mHoldsHighPriorityWakeLock=0
I/Gecko:ProcessPriorityManager(  496): [(Preallocated), child-id=7, pid=1656] Changing priority from UNKNOWN:CPU_NORMAL to BACKGROUND:CPU_NORMAL.
I/Gecko   ( 1656): ###################################### forms.js loaded
I/Gecko   ( 1656): ############################### browserElementPanning.js loaded
I/Gecko   ( 1656): ######################## BrowserElementChildPreload.js loaded
I/Gecko   ( 1656): PresShell::DoReflow() 13.72ms uninterruptible about:blank
I/Gecko   ( 1656): PresShell::DoReflow() 0.25ms uninterruptible about:blank
I/Gecko   ( 1656): PresShell::DoReflow() 0.19ms uninterruptible about:blank
Right, the 40ms are spent in ContentParent::CreateBrowserOrApp().
(In reply to Fabrice Desré [:fabrice] from comment #6)
> If we only look at reflows, here's what happens when launching a very simple
> app (Stylish is just a page with a few links):
> 
> We have a "big" reflow when displaying the page, but I don't think we can
> prevent that. Once we are done with reflowing stylish, we have two small
> ones in the system app. Vivien does that match what you saw? (and yeah, we
> waste 15ms reflowing about:blank in the preallocated process - not sure if
> that's something that could be avoided or not).
> 
> I/Gecko:ProcessPriorityManager(  496): [Stylish, child-id=6, pid=762]
> Changing priority from BACKGROUND:CPU_NORMAL to FOREGROUND:CPU_NORMAL.
> I/Gecko:ProcessPriorityManager(  496): KillBackgroundApps
> I/Gecko   (  496): [Parent 496] WARNING: waitpid failed pid:762 errno:10:
> file
> /home/fabrice/dev/mozilla-b2g28_v1_3t/ipc/chromium/src/base/
> process_util_posix.cc, line 254
> I/Gecko   (  496): PresShell::DoReflow() 3.11ms interruptible
> app://system.gaiamobile.org/index.html
> I/Gecko   (  496): PresShell::DoReflow() 2.55ms uninterruptible
> app://system.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 0.00ms interruptible about:blank
> I/Gecko:ProcessPriorityManager(  496): [Homescreen, child-id=2, pid=557]
> Changing priority from FOREGROUND:CPU_NORMAL to
> BACKGROUND_HOMESCREEN:CPU_NORMAL.
> E/GeckoConsole(  762): [JavaScript Warning: "Content Security Policy: The
> page's settings blocked the loading of a resource: An attempt to execute
> inline scripts has been blocked" {file:
> "app://stylish.gaiamobile.org/index.html" line: 0 column: 0 source: "onclick
> attribute on BUTTON element"}]
> I/Gecko   (  762): PresShell::DoReflow() 94.72ms uninterruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 0.22ms uninterruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 0.17ms uninterruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 1.79ms interruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 0.19ms interruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 0.34ms interruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 1.87ms interruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 0.20ms interruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  762): PresShell::DoReflow() 0.73ms interruptible
> app://stylish.gaiamobile.org/index.html
> I/Gecko   (  496): PresShell::DoReflow() 3.94ms interruptible
> app://system.gaiamobile.org/index.html
> I/Gecko   (  496): PresShell::DoReflow() 2.29ms interruptible
> app://system.gaiamobile.org/index.html
> I/Gecko:ProcessPriorityManager(  496): [(Preallocated), child-id=7,
> pid=1656] Creating ParticularProcessPriorityManager.
> I/Gecko:ProcessPriorityManager(  496): [(Preallocated), child-id=7,
> pid=1656] Done starting up.  mHoldsCPUWakeLock=0,
> mHoldsHighPriorityWakeLock=0
> I/Gecko:ProcessPriorityManager(  496): [(Preallocated), child-id=7,
> pid=1656] Changing priority from UNKNOWN:CPU_NORMAL to BACKGROUND:CPU_NORMAL.
> I/Gecko   ( 1656): ###################################### forms.js loaded
> I/Gecko   ( 1656): ############################### browserElementPanning.js
> loaded
> I/Gecko   ( 1656): ######################## BrowserElementChildPreload.js
> loaded
> I/Gecko   ( 1656): PresShell::DoReflow() 13.72ms uninterruptible about:blank
> I/Gecko   ( 1656): PresShell::DoReflow() 0.25ms uninterruptible about:blank
> I/Gecko   ( 1656): PresShell::DoReflow() 0.19ms uninterruptible about:blank

The last time I measure there was also some amount of time spent into graphics things that were mostly related to initializing graphics and setting up the graphic bridge (in my understanding) to render the remote content.

Associating the tabparent to the tabchild in advance was saving part of those things, and I think thats were the time was saved.
Vivien, precreate an iframe would be helpful for app startup as remote-browser-pending, remote-browser-shown, and TryRemoteBrowser() can be done in a different timing, which nsFrameLoader can SendLoadURL() earlier.

But the patches here are kind of out dated, especially gaia one. If we want this feature, how much work do you expect there will be, and has the permssion issue you mentioned ever been addressed?

> This is a bit tricky to do though since the current code assume the iframe is immutable once it has been created and all the permissions system broke if we break this assertion for now.
Flags: needinfo?(21)
The Gecko POC (attachment 8333730 [details] [diff] [review]) does update appId of doc shell also the tab context, which the permission issue should have been addressed.
The POC adds a new interface setAppId() to browser API, I am not sure does it cause security concerns.
(In reply to Ting-Yu Chou [:ting] from comment #11)
> The POC adds a new interface setAppId() to browser API, I am not sure does
> it cause security concerns.

Fabrice, do you think this is OK, or should I ask someone else?
Flags: needinfo?(fabrice)
(In reply to Ting-Yu Chou [:ting] from comment #12)
> (In reply to Ting-Yu Chou [:ting] from comment #11)
> > The POC adds a new interface setAppId() to browser API, I am not sure does
> > it cause security concerns.
> 
> Fabrice, do you think this is OK, or should I ask someone else?

No, exposing the appId is not OK. That's an internal implementation detail that should not leak outside. I think one way to do it would be to support changing the mozapp attribute value and use this manifest url to update the tabcontext and docShell.
Flags: needinfo?(fabrice)
I am trying to create patches: 1) pre-create an iframe in system app, 2) update tab context and corresponding attributes to align mozapp when iframe's src is set, 3) pause and resume forking preallocated processs once it is taken by pre-create iframe
Assignee: nobody → tchou
Status: NEW → ASSIGNED
(In reply to Ting-Yu Chou [:ting] from comment #14)
> update tab context and corresponding attributes to align mozapp when
> iframe's src is set

Currently TabContext can't be changed once it is intialized, not sure if is this intended and whether can this be changed. TabParent is created in ContentParent::CreateBrowserOrApp().
See Also: → 1126681
Because of comment 15, I filed bug 1126681 to pre-create nsFrameLoader/TabParent instead.
Assignee: tchou → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(21)
No longer blocks: AppStartup
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: