Closed Bug 1186703 Opened 9 years ago Closed 9 years ago

Cache search engine data in Java to avoid BrowserSearch graphical glitches

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1186683

People

(Reporter: mcomella, Unassigned, Mentored)

References

Details

(Whiteboard: [lang=java])

Currently, we get the search engines from Gecko every time BrowserSearch is shown. Unfortunately, this is slow and thus must be done asynchronously, resulting in a relayout/flicker/etc.

It'd be great to cache the search engine data in Java and use this as the default state. Then, we'd only need to relayout if the search engine data we receive from gecko is different than the Java data. This happens infrequently enough that most users would not see this glitch.
BrowserSearch does store the engine list:

    // List of search engines from Gecko.
    // Do not mutate this list.
    // Access to this member must only occur from the UI thread.
    private List<SearchEngine> mSearchEngines;


BrowserSearch only re-fetches in rare circumstances, typically when we've switched locales:

    public void onResume() {
        super.onResume();

        // Fetch engines if we need to.
        if (mSearchEngines.isEmpty() || !Locale.getDefault().equals(mLastLocale)) {
            GeckoAppShell.sendEventToGecko(GeckoEvent.createBroadcastEvent("SearchEngines:GetVisible", null));
        }



The BrowserSearch instance is retained by BrowserApp, so it should only be recreated when the main activity is discarded. That should be rare.

That is to say: I don't see evidence in support of Comment 0. Can you explain further?
(In reply to Richard Newman [:rnewman] from comment #1)
> The BrowserSearch instance is retained by BrowserApp, so it should only be
> recreated when the main activity is discarded. That should be rare.

BrowerSearch is recreated each time it is shown. STR:

1) Place a breakpoint in BrowserSearch.onCreate
2) Open Fennec (in debug mode)
3) Click the url bar and type - breakpoint activates
4) Run code again from breakpoint
5) Hit enter to close search
6) Click the url bar
7) Type to reopen search

Expected: onCreate is not called and thus the breakpoint is not called
Actual: onCreate is called, reinitializing the search engine list.

---
Looking at the Fragments developer guide [1], the lifecycle begins when "Fragment is added". Since we remove the Fragment, we lose the data associated with the Fragment.

Similarly, for onCreate:

The system calls this when creating the fragment. Within your implementation, you should initialize essential components of the fragment that you want to retain when the fragment is paused or stopped, then resumed.

---
The state retention notably does not include the Fragment being removed.

[1]: http://developer.android.com/guide/components/fragments.html#Creating
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.