Closed Bug 825232 Opened 13 years ago Closed 13 years ago

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

Categories

(Firefox for Android Graveyard :: Awesomescreen, defect)

Product:
Firefox for Android Graveyard
Component:
Awesomescreen
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox19 unaffected, firefox20 affected, firefox21 verified, firefox22 verified, fennec+)

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

People

(Reporter: tech4pwd, 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.
status-firefox19: --- → unaffected
status-firefox20: --- → affected
status-firefox21: --- → affected
Keywords: 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: 13 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
status-firefox22: --- → verified
Verified fixed on: -build: Firefox for Android 21.0a2 (2013-03-19) -device: Samsung Galaxy SII -OS: Android 4.0.3
status-firefox21: affected → verified
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.