Closed Bug 604437 Opened 9 years ago Closed 9 years ago

[Regression] Remote Tab badging slows down awesome bar panning

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Maemo
defect
Not set

Tracking

(fennec2.0b2+)

VERIFIED FIXED
Tracking Status
fennec 2.0b2+ ---

People

(Reporter: aakashd, Assigned: mfinkle)

References

Details

Attachments

(1 file)

Build id:
Mozilla/5.0 (Maemo; Linux armv71; rv:2.0b8pre) Gecko/20101014 Namoroka/4.0b8pre Fennec/4.0b2pre


Note: This regression may be due to the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=595218

Steps to Reproduce:
1. Go to www.gmail.com
2. Log-in
3. Tap on the url bar to open the awesome screen
4. Start panning right when it opens

Actual Results:
Panning is severely slowed down to the point its unresponsive for the first 3-5 seconds of opening the awesome screen.

Expected Results:
Panning should not be slowed with badging occurring on the same domain.
tracking-fennec: --- → ?
I think this is probably due to badging period. We need to split up the badging jobs better and use caching more aggressively.

We use "badges" for two reasons:
1. neat little red boxes for specific URLs
2. showing remote icon for URLs that are from Sync ("desktop")

I think this regression is more from #2 than #1. We only do work for #1 if the awesomebar item URL matches the badge URL. Which didn't even happen in my tests.

But we always do work for #2, and the arrays we loop over can be large. I'll focus there first.
Attached patch patchSplinter Review
This patch speeds up the process of looking for remote URLs and adding the remote icon badge in the awesomebar results. Something was slowing the process down and blocking the UI, making panning and rendering in the awesomebar suck.

When I started, the amount of time required to perform the activity was: 3218ms, 2056ms was getting the list of remote tabs.

The biggest problem was: We use the remotetabs-list binding _getRemoteTabs method to return the array of remote tabs. This was a problem because:
1. The method kicks off a Tab engine sync
2. The method checks against other open tabs using the session store data
3. The method uses the FavIcon service to verify the favicon of the tab

#1 and #3 are useful when loading the "Desktop" section, but not for just pulling the remote tab URLs, which is all we needed. #2 is never needed IMO, so I removed it.

The patch makes a local copy of _getRemoteTabs for the "All Pages" binding to use. Minimal and lightweight, it does not do #1 or #3 at all.

The final change made was to stop converting the URLs to nsIURI to compare using nsIURI.equal(). A simple string comparison works just fine and is much faster.

Final time to do the remote badging activity: 85ms, 10ms is getting the list of remote tabs.
Assignee: nobody → mark.finkle
Attachment #483382 - Flags: review?(21)
Blocks: 604384
Blocks: 604155
tracking-fennec: ? → 2.0b2+
Summary: [Regression] Badging slows down awesome bar panning → [Regression] Remote Tab badging slows down awesome bar panning
pushed:
http://hg.mozilla.org/mobile-browser/rev/28f87044773f
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
verified FIXED on build:
Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101015 Namoroka/4.0b8pre Fennec/4.0b2pre

Aaron, can you test around this and make sure we're not broken anywhere. There could be issues around using sync with this.
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Flags: in-litmus?(aaron.train)
I'm unable to perform the STR in steps 1 due to other reasons. Loading gmail in comment 0, does not load on my device sits at "Loading ... ", clicking the basic HTML viewer results in a Fennec not responding dialog. Have another URL?
https://litmus.mozilla.org/show_test.cgi?id=15203
Flags: in-litmus?(aaron.train) → in-litmus+
You need to log in before you can comment on or make changes to this bug.