Closed
Bug 1210537
Opened 9 years ago
Closed 8 years ago
Search engine bar is empty
Categories
(Firefox for Android Graveyard :: General, defect)
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.
Reporter | ||
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
psd is reporting that his icons never appear and that is the attached log above.
Comment 3•9 years ago
|
||
log points to http://mxr.mozilla.org/mozilla-central/source/toolkit/components/search/nsSearchService.js#4250 which is restoreDefaultEngines()
Comment 4•9 years ago
|
||
although that doesnt seem to match the exception string.
Comment 5•9 years ago
|
||
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
Comment 6•9 years ago
|
||
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.
Reporter | ||
Comment 8•9 years ago
|
||
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?
Comment 9•9 years ago
|
||
I do wonder if some of platform team's work to reduce startup time by delaying lots of things might be biting us here.
Comment 10•9 years ago
|
||
(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)
Keywords: regressionwindow-wanted
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.
Comment 13•9 years ago
|
||
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.
Comment 16•9 years ago
|
||
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)
Comment 18•9 years ago
|
||
(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)
Reporter | ||
Comment 19•9 years ago
|
||
I don't see this on my phone anymore either, beyond a 1-2 seconds pause (which is normal).
Flags: needinfo?(liuche)
Reporter | ||
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
Comment 20•1 year ago
|
||
Removing regressionwindow-wanted
keyword because this bug has been resolved.
Keywords: regressionwindow-wanted
Comment 21•1 year ago
|
||
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.
Description
•