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
--HG--
extra : rebase_source : e36faf63dadeba0c897b769cb7e14a2d01d0f628
extra : amend_source : 2c7a88b6e3d6de50b37c34a5579b3ab6fb0c10dd
Regression tests will be added in bug 1381411 when methods to retrieve the metadata will be available.
MozReview-Commit-ID: I3MgwM0EOty
--HG--
extra : source : 6b7ffdcb3f99be007e88c685fd54a8132d844101
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
--HG--
extra : rebase_source : df2d50d50c45a98e257caaa6efa9d0da2fa79237
extra : source : 278858e3d78b5e371f865adac043d07b770f1d3f
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
--HG--
extra : rebase_source : f429fe475ea1887180e269ee8aa0addcee76704d
extra : source : df5f46c825a10587149a7bbac2e126c3906e0393
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
--HG--
extra : rebase_source : 44b8783e5c44460d3aa4fb9bd0834c981110e98e
extra : source : 56b8e456797c56c45ed791c0d40f43031e94dc22
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
--HG--
extra : rebase_source : 3a9ea310d3e4a8642aabbc10636c04bfe2e77070
See also pt. 4. We are moving app menu notification state
into a jsm since it is not specific to one window and this
simplifies work for the new app update UI.
MozReview-Commit-ID: InEp5b0y2n0
--HG--
extra : rebase_source : afe4870fe01d64c7b870ddf568c525e6b12f27b2
This removes the arrowStyledIndicator killswitch and the associated ability for system add-ons to restore the previous design of the Downloads Indicator in the toolbar. The removal includes all the related code, styles, and strings. Based on the original patch by :rexboy.
MozReview-Commit-ID: 2OEBzPNzl0O
--HG--
extra : rebase_source : f40a319bb4afacb9e196465fc901cb3eb0b25ab5
With this change two new attention states are introduced, "severe" and "warning",
along with the previous "success" and "no attention" states. "No attention" is
still a falsy value in order to mitigate any add-on compatibility issues.
"severe" and "warning states" now display an icon badge to the downloads button
(or the hamburger button if the downloads button is tucked away).
MozReview-Commit-ID: 3gc9Ji7zCXY
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
--HG--
extra : commitid : F2ItGm8ptRz
extra : rebase_source : b082fe4bf77e22e297e303fc601165ceff1c4cbc
