Closed Bug 1109745 Opened 5 years ago Closed 5 years ago

[Messages] Load thread_ui and activity_handler earlier when starting as an activity

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
2.2 S3 (9jan)

People

(Reporter: julienw, Assigned: azasypkin)

References

Details

(Whiteboard: [sms-papercuts][p=1])

Attachments

(1 file)

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.
Assignee: nobody → azasypkin
Status: NEW → ASSIGNED
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.
Attachment #8536473 - Flags: feedback?(felash)
Comment on attachment 8536473 [details] [review]
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?
Attachment #8536473 - Flags: feedback?(felash) → feedback+
Whiteboard: [sms-papercuts] → [sms-papercuts][p=1]
Target Milestone: --- → 2.2 S3 (9jan)
Blocks: 1112135
Comment on attachment 8536473 [details] [review]
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!
Attachment #8536473 - Attachment description: GitHub pull request URL (WIP) → GitHub pull request URL
Attachment #8536473 - Flags: review?(felash)
Comment on attachment 8536473 [details] [review]
GitHub pull request URL

r=me, thanks !
Attachment #8536473 - Flags: review?(felash) → review+
Thanks for review!

Master: https://github.com/mozilla-b2g/gaia/commit/8af26c30380e701d329fcaa8d035544bf52c8eda
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
See Also: → 1082066
Depends on: 1156464
You need to log in before you can comment on or make changes to this bug.