It takes a very long time to enter the message composer panel when starting an activity (new or shared). We should be able to lower this delay by simply loading the lazyloaded files earlier when we detect we're in an activity. We should likely do the same when entering from clicking a notification. There are 2 ways: * either use navigator.mozHasPendingMessage; This may have a perf penalty so be careful to test the time needed to merely executing this function. * or test the location.hash value (but then we'd need to add a hash to the "notification" system message handler, and therefore to test that it's not breaking in every possible situation).

Will experiment with the approaches from comment 0.

Hey Julien, Here is WIP patch that uses "hash" approach from the comment 0. Using Flame with the latest PVT and light workload I see obvious improvements for the "activity-share" case, but not for "activity-new" and "notification" cases. Moreover the "notification" case (if we Messages app isn't run) feels insanely slow, but maybe it's not that frequent case. I mean when we receive new message app is run via "sms-received" system message and _not_ closed, so that when we tap on notification it's handled by ready application. But if app was killed then we'll have really slow path.

Comment on attachment 8536473 [details] GitHub pull request URL This looks better but I see that loading the panel competes with rendering the thread list. I wonder if we could wait that the user is in the right panel before calling ThreadListUI.renderThreads? Maybe in a separate bug?

Comment on attachment 8536473 [details] GitHub pull request URL Hey Julien, I've added unit tests + your suggestions, I'll try to delay thread rendering in the scope of bug 1112135. Could you please review this patch? Thanks!

Comment on attachment 8536473 [details] GitHub pull request URL r=me, thanks !

Thanks for review! Master: https://github.com/mozilla-b2g/gaia/commit/8af26c30380e701d329fcaa8d035544bf52c8eda