This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
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
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
The height of the "panelmultiview" binding is now determined by the stack layout code, and doesn't have to be calculated manually via JavaScript anymore. This allows the removal of mutation and overflow observers, and reduces the number of synchronous layouts being made.
There is still a workaround included for wrapping blocks not being taken into account in height calculations.
MozReview-Commit-ID: 9rrPU5O5hUx
1) In the Downloads Panel, hovering over an item would sometimes not trigger an
actual selection, due to an error in how 'onDownloadMouseOver()' events were
processed - 'aEvent.orginalTarget' doesn't take retargets into account. Fixed
by using 'aEvent.target' instead of 'aEvent.originalTarget'.
2) In the Downloads Panel, right-clicking an item opens a context menu that
lets you act on the selected item. However, if you unintentionally hover over a
different item when the context menu is open, the selection changes. You may,
for example, 'Remove From History' a different, unintended item. Fixed by
inhibiting item selection when a context menu is open for a download item.
MozReview-Commit-ID: DLIAFNcs33N