Cache search engine data in Java to avoid BrowserSearch graphical glitches

RESOLVED DUPLICATE of bug 1186683

Status

()

RESOLVED DUPLICATE of bug 1186683
3 years ago
3 years ago

People

(Reporter: mcomella, Unassigned, Mentored)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

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
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1186683
You need to log in before you can comment on or make changes to this bug.