I agree with this proposal. I have no idea why we never used MergeCursor in the first place.
On Mon, Jan 18, 2016 at 2:19 PM, Richard Newman <[email protected]> wrote: > That's my concrete proposal, looking at: > > > https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/db/LocalBrowserDB.java#1679 > > — push getTopSites and getPinnedSites down into BrowserProvider, so we're > only dealing with a single SQLite cursor. > > If we can figure out a way to generate a suggested sites cursor without > first reading the resulting top sites cursor (all that excludedUrls > nonsense), great, then use Android's own MergeCursor to concatenate the > two. > > If we can't do so, then push the list of suggested sites into > BrowserProvider as a URI argument, and have it include them in the > returned cursor. > > Currently we do this: > > * Query for pinned sites. > * Query for top sites. > * Walk both cursors to get excluded URLs. > * Get a synthetic cursor for suggested sites. > * Use our own implementation of a merging cursor. > > That is: two queries, and we walk the resulting cursors more than once. We > shouldn't need to do either of those things. > > On Mon, Jan 18, 2016 at 11:06 AM, Richard Newman <[email protected]> > wrote: > >> Does the problem only occur in the loader that uses TopSitesCursorWrapper? >> >> If so, can you eliminate that by simply generating a single cursor inside >> BrowserProvider, containing everything it needs? We shouldn't be hitting >> three cursors to show Top Sites. >> >> On Mon, Jan 18, 2016 at 5:33 AM, Margaret Leibovic <[email protected] >> > wrote: >> >>> On Fri, Jan 15, 2016 at 1:17 PM, Michael Comella < >>> [email protected]> wrote: >>> >>>> I started to investigate and came up with some speculative fixes, >>>> seeing that the framework used `CancellationSignal`s, but I later >>>> discovered the framework has two implementations (one built-in and one in >>>> the support library), one of which does not use the `CancellationSignal`s >>>> so I think the implementation with the signals is an optimization and I >>>> lost confidence in my solution. >>>> >>> >>> This crash is still happening on Nightly with this speculative fix, so I >>> agree that this doesn't look like the source of the crash. >>> >>> This bug is now the #1 top crasher on beta, so any help investigating >>> would be much appreciated: >>> >>> https://crash-stats.mozilla.com/topcrashers/?product=FennecAndroid&version=44.0b9&days=7 >>> >>> Margaret >>> >>> >>> _______________________________________________ >>> mobile-firefox-dev mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>> >>> >> > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
