Open Bug 490714 (placesFolders) Opened 15 years ago Updated 7 months ago

[meta] Implement an Asynchronous API for opening container query nodes

Categories

(Toolkit :: Places, task, P3)

task

Tracking

()

Performance Impact low

People

(Reporter: adw, Unassigned)

References

(Blocks 4 open bugs)

Details

(5 keywords)

Attachments

(1 file)

containerNode.openContainerAsync(function () alert("Container opened!")); Like that. By asynchronous I mean that the SQL query underneath the container is asynchronous, using the async storage API. This won't make the entire batch of container children load any faster, but it does mean Firefox won't beachball while the SQL is blocking the UI and everything else. There may be opportunities for the callback to be notified of chunks of children as they're loaded, but this is complicated where we're sorting children in C++ only after obtaining all SQL results. The most obvious use case in the front end is the Places tree view, especially in the library. (Searches in the library should benefit, too.) I'm imagining an animated throbber on top of the whole tree as the children of its root container are loaded, and throbbers in individual container rows as their children are loaded. UI feedback like this should pretty simple via CSS. Fortunately there's an existing nsINavHistoryResultViewer interface that the tree view uses to observe container openings and closings, and so I think the tree view could be made to use the async API without quite as much trouble as one might first think. Perhaps this interface could be used everywhere in lieu of a callback function. Will attach a WIP patch that begins the API and the tree view's use of it after I clean it up a little.
Depends on: 490867
Attached patch WIP v1Splinter Review
Very much a WIP. Includes the patch to bug 490867, which blocks this bug and the test requires to pass. Also includes a stab at updating the tree view. (Of course this portion will be broken out into a different bug later on. Currently the tree view busy waits on the new container node attribute containerOpening.) Need to look at all the places where sync and async openings could intersect and screw each other up, but working on the tree view simultaneously has been a help so far, and this patch prevents some basic interactions between the two.
Keywords: perf
Priority: -- → P1
Whiteboard: [TSnappiness]
Blocks: 491746
Depends on: 499985
Target Milestone: mozilla1.9.1 → ---
Please consider adding the ability to cancel asynchronous queries. It would also be very useful in an extension which I have written, and probably useful also in the library and in other occasions.
Depends on: 536893
Blocks: 556068
Blocks: 559266
Blocks: 365992
No longer blocks: 556068
Blocks: StorageJank
Alias: placesFolders
Depends on: 702639
Whiteboard: [TSnappiness] → [Snappy]
Whiteboard: [Snappy] → [Snappy:P3]
Assignee: adw → nobody
Status: ASSIGNED → NEW
Blocks: OMTPlaces
No longer blocks: StorageJank
Blocks: 1047817
Priority: P1 → --
Priority: -- → P2
Priority: P2 → P3
Whiteboard: [Snappy:P3] → [Snappy:P3] [fxperf]
Whiteboard: [Snappy:P3] [fxperf] → [Snappy:P3] [fxperf:p3]
Blocks: 895049
Blocks: 1765479
Blocks: 1770789
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 17 votes.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mak)
Severity: S3 → N/A
Type: defect → task
Keywords: meta
Summary: Asynchronous API for opening container query nodes → [meta] Implement an Asynchronous API for opening container query nodes
Duplicate of this bug: 895049
Blocks: 1391590
Blocks: 1853983
Performance Impact: --- → low
Whiteboard: [Snappy:P3] [fxperf:p3]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: