Closed Bug 939778 Opened 6 years ago Closed 6 years ago
Spinning favicon after installing new search engine
Environment: Device: Asus Transformer Tab (Android 4.0.3) Build: Nightly 28.0a1 (2013-11-18) Steps to reproduce: 1. Go to bbc.com and wait until the favicon appears; 2. Long tap on the search field; 3. From the pop-up tap on 'Add Search Engine'; 4. Set the name for the search engine and tap 'OK' button; 5. Go to Settings -> Search settings; 6. Check if the search engine is installed; 7. Load cnn.com in the same tab. Expected result: The default loading favicon is spinning when the page is loading. Acutal result: The favicon from the 1st page is spinning while the second page is loading. Note: Please check the video: http://www.youtube.com/watch?v=i3xFMsV2Zmo
No Favicon whatsoever should be spinning at all. Only a throbber should be spinning during page-load. With that said, I'm unable to reproduce. In step 2, I don't even even see an 'Add Search Engine' for BBC.com (desktop version), I checked their site and they don't have an open-search link, so how are you doing that? In the video, I don't even see that you're on BBC. Do you have better steps to reproduce?
The bug is tablet specific. It is not reproducible on phones. I made another video following the steps: http://www.youtube.com/watch?v=Lj3QeYtRaxY
I'm unable to reproduce on my Galaxy Tab 3 (Nightly 11/18). On-load of CNN, I get the expected throbber not a spinning favicon. Also, I don't see what adding a search-engine has anything to with the issue shown in the video here. Can you reproduce this by going to settings and then backing out before loading CNN and after loading BBC?
tracking-fennec: --- → ?
I am able to reproduce this issue on Samsung Galaxy Tab(Android 4.0.4) following the exact steps from the bug. First load BBC and add the search engine, then go to settings->search settings, exit the settings, then load CNN.
I think the smaller STR is to go to Settings > Customize > Search settings and then back out. flaviu, can you repro with this smaller set of steps?
(In reply to Chenxia Liu [:liuche] from comment #6) > flaviu, can you repro with this smaller set of steps? Yes the bug is reproducible with the smaller set of steps: New steps to reproduce: 1. Go to Settings > Customize > Search settings; 2. Go back to the awesomescreen and load a page.
Assignee: nobody → liuche
tracking-fennec: ? → 28+
I'm going on PTO for two weeks, so feel free to take this. I'll pick it up when I get back if it's still open.
Needs a new assignee for Aurora.
Assignee: liuche → nobody
Assignee: nobody → michael.l.comella
I initially assumed this was related to loading favicons to display them in the settings screen, however, it appears this may not be the case: I removed all the lines between <PreferenceScreen> and its closing tag in preferences_search.xml  but the issue still occurred. Additionally, I commented out the "SearchEngines:Data" event registering code in SearchPreferenceCategory.java and the subsequent "SearchEngines:Get" broadcast , preventing any favicons from being loaded at all in the preferences screen, but the issue still occurred. Perhaps the issue is related to this being the only Preferences screen that opens a sub-screen. : https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/resources/xml/preferences_search.xml#6 : https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/preferences/SearchPreferenceCategory.java#47
Status: NEW → ASSIGNED
A blank PreferenceScreen (also using GeckoPreferenceFragment) shows the same behavior.
mcomella and I talked a little about this today, and since this touches settings stuff I'll take it.
Assignee: michael.l.comella → liuche
Further investigation: While testing on other devices, this doesn't seem to be present in the 2013-09-10 Nightly, so it's a regression since then. The problem seems to be correlated to changing headers in the Settings menu. New STR: 1. On a fully loaded page, open Settings and click on one of the side-panel headers. 2. Exit settings, load a page. On a fully loaded page, opening Settings and then closing it again reverts the spinning favicon problem. During a page load however, entering and then exiting the Settings menu (even without clicking any headers) causes the throbber to get stuck - no favicon is ever loaded.
I also can't repro this on the Samsung Galaxy Tab 3, and I don't have any other tablets to test on. (Also, ignore the regression range because I mistakenly thought the Galaxy Tab 3 also had this problem.)
Great, I can repro on a Galaxy Tab running 4.0.4 with the STR from comment #13, and the regression is at least after the 10/17 Nightly build. The Galaxy Tab 3's we have that don't display this are running 4.2.*, so this could be a 4.0 bug (no data on 4.1).
Any news on this, Chenxia?
Is this bug still an issue now that "progress bar" patch landed in bug 917896 ?
The bug is no longer reproducible on the nightly build after bug 917896 has landed. The bug is still reproducible on aurora build.
So we need an Aurora fix. What about Beta?
Doesn't repro for me either on Nightly. I'm not sure what the fix for Aurora would be - I had a lot of trouble nailing down what exactly the cause was, and none of my hypotheses panned out (collision of Android element ids, race in managing load state). AFAICT, the problem was that while the resource for the ImageView was set correctly when switching from favicon to throbber, the image was just wrong. This problem occurred when a preference header (in tablet mode) was tapped, or if the settings where opened during a page load (with the spinning throbber). Opening up a new PreferenceFragment when a page wasn't in the middle of a load would reset the behavior so the throbber resource was updated correctly. Basically, I got really stuck trying to pin down what the cause of the failed resource displaying was. Any suggestions or takers for trying to find a fix for Aurora welcome.
Sounds like wont-fix for 28 based on the summary
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.