Closed Bug 825232 Opened 8 years ago Closed 8 years ago

Search plugins fail to activate if AwesomeScreen is activated before page finishes loading

Categories

(Firefox for Android :: Awesomescreen, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox19 --- unaffected
firefox20 --- affected
firefox21 --- verified
firefox22 --- verified
fennec + ---

People

(Reporter: pwd.mozilla, Assigned: bnicholson)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20121227 Firefox/20.0
Build ID: 20121227030822

Steps to reproduce:

If you load Fennec but don't wait for it to finish loading whichever page you were on before click the AwesomeScreen, none of the search plugins/suggestions start.
OS: Windows 7 → Android
Hardware: x86 → ARM
I have also seen the awesomescreen items for the searches not showing up -> confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Paul [sabret00the] from comment #0)
> If you load Fennec but don't wait for it to finish loading whichever page
> you were on before click the AwesomeScreen, none of the search
> plugins/suggestions start.

If you back-out and re-enter the AwesomeScreen, I assume they work, correct?
Indeed.
Requesting tracking to see if anything can or should be done here
tracking-fennec: --- → ?
Assignee: nobody → bnicholson
tracking-fennec: ? → +
Possible mentor bug? Add a GeckoReady listener to Awesometabs ?
(In reply to Mark Finkle (:mfinkle) from comment #5)
> Possible mentor bug? Add a GeckoReady listener to Awesometabs ?

We send a SearchEngines:Get message in AllPagesTab initialization here: http://hg.mozilla.org/integration/mozilla-inbound/file/33e9b69e55cc/mobile/android/base/awesomebar/AllPagesTab.java#l94. If Gecko isn't running yet, the events are queued until it's ready, so I think Gecko should be getting this message. This sounds suspiciously similar to bug 769524 (see https://bugzilla.mozilla.org/show_bug.cgi?id=769524#c67).
Blocks: 832338
Note that bug 832987 is similar but probably not the same as this because the behaviour in comments 2 and 3 would not happen if it were caused by the Gecko:Ready getting lost.
I can reproduce this in 20 and 21 but not 19, so this must be a relatively recent regression.
With some logging, it looks like the window and its scripts - including browser.js - are loaded, but the onload="BrowserApp.startup()" in browser.xul isn't fired for some reason when the AwesomeScreen is open.
The regression window for this issue is:

good build:
2012/01/22

bad build 
2012/01/23

possible push-log:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf26f61a0748&tochange=84320dffec6e
The previous comment was wrong:

The regression window for this issue is:

good build:
2012/12/22

bad build 
2012/12/23

possible push-log:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf26f61a0748&tochange=84320dffec6e
This was fixed by bug 844275.
No longer blocks: 760036
Status: NEW → RESOLVED
Closed: 8 years ago
Depends on: 844275
Resolution: --- → FIXED
Verified fixed on:
-build: Firefox for Android 22.0a1 (2013-03-15)
-device: Samsung Galaxy Nexus
-OS: Android 4.1.1
Verified fixed on:
-build: Firefox for Android 21.0a2 (2013-03-19)
-device: Samsung Galaxy SII
-OS: Android 4.0.3
You need to log in before you can comment on or make changes to this bug.