4 commits

Author	SHA1	Message	Date
Andrew McCreight	5dec0e0beb	Bug 1432992, part 1 - Remove definitions of Ci, Cr, Cc, and Cu. r=florian ... 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 --HG-- extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b	2018-02-06 09:36:57 -08:00
Florian Quèze	5e3539e504	Bug 1353542 - massive script-generated patch converting Task.async and Task.spawn calls, and generators clearly identifiable as tasks, rs=Mossop.	2017-05-12 14:42:39 +02:00
Henry Chang	f3be63826d	Bug 1339050 - Asynchronously apply safebrowsing DB update. r=francois,gcp ... A new function Classifier::AsyncApplyUpdates() is implemented for async update. Besides, all public Classifier interfaces become "worker thread only" and we remove DBServiceWorker::ApplyUpdatesBackground/Foreground. In DBServiceWorker::FinishUpdate, instead of calling Classifier::ApplyUpdates, we call Classifier::AsyncApplyUpdates and install a callback for notifying the update observer when update is finished. The callback will occur on the caller thread (i.e. worker thread.) As for the shutdown issue, when the main thread is notified to shut down, we at first *synchronously* dispatch an event to the worker thread to shut down the update thread. After getting synchronized with all other threads, we send last two events "CancelUpdate" and "CloseDb" to notify dangling update (i.e. BeginUpdate is called but FinishUpdate isn't) and do cleanup work. MozReview-Commit-ID: DXZvA2eFKlc --HG-- extra : rebase_source : cd2e27a6b679d2c96e769854d1582ed2dcda12bb	2017-04-06 07:07:56 +08:00
Henry	4365be8782	Bug 1328824 - Test if about:blocked can be loaded in a secure context. r=Gijs ... MozReview-Commit-ID: GQAfd4xuRJT --HG-- extra : amend_source : 65fdbfa64ab205040a5e8a825b9196936167dbaf	2017-01-13 00:08:45 +08:00