Closed Bug 1210537 Opened 9 years ago Closed 8 years ago

Search engine bar is empty

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox44 affected)

RESOLVED WORKSFORME
Tracking Status
firefox44 --- affected

People

(Reporter: liuche, Unassigned)

References

Details

Attachments

(2 files)

Typing into the urlbar brings up an empty search bar with no search icons. After a few seconds, the icons appear. This happens from a cold start, with the 10/01 nightly.
psd is reporting that his icons never appear and that is the attached log above.
although that doesnt seem to match the exception string.
http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#6664  —> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/search/nsSearchService.js#4258  —> this._defaultEngine is awol. 

makes me wonder about
4264         defaultEngine = this._getSortedEngines(false)[0] || null;
4265       this._defaultEngine = defaultEngine;
4266     }
4267     if (this._defaultEngine.hidden)

if getSortedEngines() call doesnt do the right thing, and on 4264 defaultEngine is set to null, then this._defaultEngine is (re)set to null, and on 4267 we'll try to get the hidden attribute of a null object, this._defaultEngine
psd has reported that this.getSortedEngines() is returning undefined
(In reply to Chenxia Liu [:liuche] from comment #0)
> Typing into the urlbar brings up an empty search bar with no search icons.
> After a few seconds, the icons appear. This happens from a cold start, with
> the 10/01 nightly.

This sounds like expected behavior – we have to wait for Gecko to start to retrieve the search engines and we don't hide the empty search engine bar to avoid wasting valuable startup computation time on re-layout.

The issues Ally & psd are mentioning sound more serious though.
I filed this because it looked like a regression - I've never seen such a long delay for loading the search engines, until around the very end of September. Is there something that 1) changed how the search engines are loaded, and 2) the 3-second-ish delay in displaying the engines is expected, and considered okay?
I do wonder if some of platform team's work to reduce startup time by delaying lots of things might be biting us here.
(In reply to Chenxia Liu [:liuche] from comment #8)
> I filed this because it looked like a regression - I've never seen such a
> long delay for loading the search engines, until around the very end of
> September. Is there something that 1) changed how the search engines are
> loaded

for (1), no nothing on the front end has modifed the search engine loading part. All the work we've done lately is after startup.
Kevin, have you seen this behavior?
Flags: needinfo?(kbrosnan)
bug 1186683 prevented us from reconstructing BrowserSearch each time it was shown – it shouldn't affect the issue mentioned here, but it caused some regressions that could. All of the ones that are marked blocking bug 1186683 have not landed yet, or shouldn't affect this behavior, but perhaps there is one that was fixed that isn't marked.
I have not. I don't see how this is a regression. If we need gecko to be up to display this info that may take several seconds. Going from a killed nightly to typing in the address bar as fast as possible results in a slight delay (100s ms) before the search engine favicons are displayed. Using my Galaxy S5 running Android 5.0.
Flags: needinfo?(kbrosnan)
(In reply to Kevin Brosnan [:kbrosnan] from comment #13)
> I have not. I don't see how this is a regression.

I think Chenxia was saying the delay seemed to increase.

We used to hide the Search Engine Bar until we got the search engines – perhaps it's a perception issue? We might be able to explore drawing the SearchEngineBar *over* the list, for some overdraw (which may hurt scrolling perf, I'm not sure), and padding the list at the bottom so the user can scroll to the last item.

Otherwise, I'm not sure what can be done here without either 1) VIEW.GONE, where we'll be required to relayout the page (iirc, for which there was a noticeable delay) or 2) VIEW.INVISIBLE where the search results on the screen will have a strange white block at the bottom.

Chenxia, do you still see this? Do you think it's a perception issue and do you think it's worth exploring ^?
Flags: needinfo?(liuche)
(In reply to Michael Comella (:mcomella) from comment #14)
> We might be able to explore drawing the
> SearchEngineBar *over* the list,

Because this will allow us to use View.INVISIBLE with relayout of the whole page.
Hi all!

As reported in comment 2, my icons weren't appearing at all. I pulled m-c again, and setup a new repo. Now, the icons appear, but they need around 4-5 seconds the first time I type something in the url bar.
(In reply to Prabhjyot Sodhi [:psd] from comment #16)
> As reported in comment 2, my icons weren't appearing at all. I pulled m-c
> again, and setup a new repo.

Local build? Something fishy may have been going on there (e.g. bad checkout).

> Now, the icons appear, but they need around 4-5
> seconds the first time I type something in the url bar.

This could be expected – which device is this?
Flags: needinfo?(prabhjyotsingh95)
(In reply to Michael Comella (:mcomella) from comment #17)
> > Now, the icons appear, but they need around 4-5
> > seconds the first time I type something in the url bar.
> 
> This could be expected – which device is this?
I tested on a Gionee Elife S5.5 and a Samsung Galaxy. It has a 1-2 second delay now. So it seems okay! :)
Flags: needinfo?(prabhjyotsingh95)
I don't see this on my phone anymore either, beyond a 1-2 seconds pause (which is normal).
Flags: needinfo?(liuche)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard

Removing regressionwindow-wanted keyword because this bug has been resolved.

Removing regressionwindow-wanted keyword because this bug has been resolved.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: