Closed Bug 1013684 Opened 7 years ago Closed 7 years ago

Distribution handling is accidentally triggered by top sites, not when it's supposed to be


(Firefox for Android Graveyard :: Data Providers, defect)

Not set


(Not tracked)

Firefox 32


(Reporter: rnewman, Assigned: rnewman)




(1 file, 1 obsolete file)

at org.mozilla.gecko.distribution.Distribution.doInit(
at org.mozilla.gecko.distribution.Distribution.getDistributionFile(
at org.mozilla.gecko.distribution.Distribution.getBookmarks(
at org.mozilla.gecko.distribution.Distribution.getBookmarks(
at org.mozilla.gecko.db.BrowserDatabaseHelper.createDistributionBookmarks(
at org.mozilla.gecko.db.BrowserDatabaseHelper.onCreate(
at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(
at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(
at org.mozilla.gecko.db.DBUtils.ensureDatabaseIsNotLocked(
at org.mozilla.gecko.db.PerProfileDatabases.getDatabaseHelperForProfile(
at org.mozilla.gecko.db.AbstractPerProfileDatabaseProvider.getReadableDatabase(
at org.mozilla.gecko.db.BrowserProvider.query(
at android.content.ContentProvider.query(
at android.content.ContentProvider$Transport.query(
at android.content.ContentResolver.query(
at android.content.ContentResolver.query(
at org.mozilla.gecko.db.LocalBrowserDB.getPinnedSites(
at org.mozilla.gecko.db.BrowserDB.getTopSites$5514332a(
at org.mozilla.gecko.home.TopSitesPanel$TopSitesLoader.loadCursor(
at org.mozilla.gecko.home.SimpleCursorLoader.loadInBackground(
at org.mozilla.gecko.home.SimpleCursorLoader.loadInBackground(
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$
I have a patch for this underway.

The general approach I'm taking is to allow consumers to queue up work to be done when the distribution loader is done loading the distribution.

This becomes particularly important when loading the distribution might take fifteen seconds due to network latency.

This might end up as a useful micropattern for startup: right now we tend to rely on background runnables finishing in the right order, which is easy until they rely on something happening on the UI thread in some onCreate method.
Blocks: 1014242
Blocks: 1014283
Not yet cleaned up.
Depends on: 1014338
Attachment #8426619 - Attachment is obsolete: true
No longer blocks: 1014242, 1014283
Comment on attachment 8426714 [details] [diff] [review]
Delay loading of distribution bookmarks.

Review of attachment 8426714 [details] [diff] [review]:

::: mobile/android/base/db/
@@ +768,5 @@
> +        int offset = createDefaultBookmarks(db, 0);
> +
> +        // We'd like to create distribution bookmarks before our own default bookmarks,
> +        // but we won't necessarily have loaded the distribution yet. Oh well.
> +        enqueueDistributionBookmarkLoad(db, offset);

We should make sure to update the documentation about this change. I think we did this partially to dictate the order that thumbnails would appear in top sites, but that's changing with suggested sites anyway. Hopefully distributions won't be disappointed with our 3 default bookmarks appearing before their other bookmarks.
Attachment #8426714 - Flags: feedback+
Comment on attachment 8426714 [details] [diff] [review]
Delay loading of distribution bookmarks.

Please ignore for the moment the scary TODO and the lack of doc changes when considering review. I'll double-check concurrency before I land.
Attachment #8426714 - Flags: review?(margaret.leibovic)
Comment on attachment 8426714 [details] [diff] [review]
Delay loading of distribution bookmarks.

Review of attachment 8426714 [details] [diff] [review]:

Thanks for the doc updates!
Attachment #8426714 - Flags: review?(margaret.leibovic) → review+
I'm making three changes from the reviewed patch as I land this:

1. Rather than fetching a new Distribution instance in createDistributionBookmarks, we take the one that called us as an argument. Makes sense to me.

2. Rather than queuing up a new background runnable for each distro bookmark to create the favicon, do it right then. This makes sense for several reasons:

  * All of this work is now happening in a background runnable, so yay. No worries about blocking the UI, which is why we queued the runnables in the first place.
  * We save creating 2+ runnables. Much quicker to just do the work. Yay efficiency.

3. I spotted a null safety issue with BitmapUtils.getBitmapFromDataURI, which I fixed by adding a null check.

Scream if any of that sounds bad.
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.