Closed
Bug 1186703
Opened 10 years ago
Closed 9 years ago
Cache search engine data in Java to avoid BrowserSearch graphical glitches
Categories
(Firefox for Android Graveyard :: General, defect)
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.
Comment 1•10 years ago
|
||
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?
Reporter | ||
Comment 2•10 years ago
|
||
(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
Reporter | ||
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•