* Maintain a _nextNotificationType LIFO "queue" of one, to play overlapping events in series
* _showNotification assumes everything could have changed since it was last called
* Signature of showEventNotification is unchanged, but most of its work is now done in _showNotification
MozReview-Commit-ID: 8sv4DZoZU65
* Maintain a _nextNotificationType LIFO "queue" of one, to play overlapping events in series
* _showNotification assumes everything could have changed since it was last called
* Signature of showEventNotification is unchanged, but most of its work is now done in _showNotification
MozReview-Commit-ID: 8sv4DZoZU65
This also changes the Library window to use the newly added back-end object. The only user-visible change should be how the selection behaves when retrying downloads.
MozReview-Commit-ID: 7CQr1m21rcB
* Filmstrip style svg animation for start download notification, vertically centered to allow for variable-height toolbar buttons
* Simultaneous identifer "dip" animation on the icon for download start
* Identifier icon bounce animation for download finish (no notification animation in the #downloads-animation-container)
* Always measure the anchor element as toolbarheight may change in a session (e.g. switching to compact mode)
* Conditionally include the start/finish pngs for non-Photon builds
* Have #downloads-notification-anchor hidden by default, and show it before measuring for placement. This avoids the interference with scrolling/APZ when the notifier element is tall enough to overlap the tabbrowser element
MozReview-Commit-ID: LJF6iV9HiJi
The DownloadList object now provides batch notifications directly, in preparation for linking front-end views to other types of download lists without having to use the DownloadsData indirection.
MozReview-Commit-ID: FOTz1YwGRE1
The front-end download views now maintain the old download state themselves, instead of relying on the DownloadsData object dispatching the onDownloadStateChanged notification.
This allows each view to keep only the state relevant to it, for example the Downloads Panel already keeps the state only for the visible items. This also makes it possible for each view to use a different hash than the one provided by the legacy stateOfDownload method, and allows bypassing the DownloadsData indirection entirely.
MozReview-Commit-ID: 2D1ixsZCkCa
When a new front-end view is added to the DownloadsData object, the Download objects it contains are loaded into the view starting with the newest, which is the opposite of the order used by the underlying DownloadList.
This was originally implemented as an optimization for the Downloads Panel, at a time when the full list of completed downloads was persisted in the same SQLite database as session downloads. This difference is now unnecessary given the low number of session downloads, and can be removed in preparation for bypassing the DownloadsData indirection entirely.
MozReview-Commit-ID: 5EBkqvyXFq4
This was regressed by bug 1264206 while removing legacy array comprehensions, because selectedItems is a NodeList and not an Array.
MozReview-Commit-ID: 61GG3SiiWwS
* Split out the arrow and progressbar in the indicatorOverlay for individual animation.
* Group icon and progressbar parts into addressable elements in a single download-icons.svg
MozReview-Commit-ID: KAn0gFqjKjc
Changes to Promise tests designed to test .then(null) have been reverted, and the browser/extensions directory was excluded because the projects it contains have a separate process for accepting changes.
MozReview-Commit-ID: 1buqgX1EP4P
