mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-31 22:25:30 +00:00
a95ff1c7bb
The issue: only by launching GeckoApp (or a subclass) did we specify what kind of DB we wanted. If we don't specify, we get a StubBrowserDB. The search activity is not a GeckoApp, but it does implicitly access a profile. The same is true for Sync: a background Sync would eventually cause the CP to touch GeckoProfile to get the profile directory. Both of these avenues will poison the GeckoProfile cache, storing a profile with a database member that's a StubBrowserDB. If you subsequently launched the browser you'd get that GeckoProfile instance from the profile cache. StubBrowserDB deliberately returns null for some queries -- such as getTopSites. That causes us to throw here. The solution I chose: have *GeckoApplication* specify which kind of DB to use, and then have WebappImpl (the only subclass for which we want different behavior) override it. GeckoView consumers remain unaffected, because they have their own Application class, and so the usual GeckoProfile fallback applies. |
||
|---|---|---|
| .. | ||
| Allocator.java | ||
| ApkResources.java | ||
| Dispatcher.java | ||
| EventListener.java | ||
| InstallHelper.java | ||
| InstallListener.java | ||
| TaskKiller.java | ||
| UninstallListener.java | ||
| WebappImpl.java | ||
| Webapps.java | ||