Bug 1462702 - Add about:crashparent and about:crashcontent r=ehsan MozReview-Commit-ID: 4KurLWBZh6p

Bug 1459206 - Use FileSystemSecurity in ContentParent::RecvGetFilesRequest, r=ehsan

Bug 1459206 - Use FileSystemSecurity in ContentParent::RecvGetFilesRequest, r=ehsan

Bug 1452538 - Add telemetry probes HTMLEditors which have shown Gecko build-in editing UIs and count of user interaction with them r=Ehsan Gecko has some built-in UIs: * to edit size of objects like <img>, <table> and absolute positioned elements. * to edit position of absolute positioned elements. * to add/remove table columns and rows. Currently, those UIs are available in both designMode editor and contenteditable editor only on Gecko. I.e., the other browsers' users cannot modify as such without web apps implement such function. So, for compatibility with the other browsers, we should hide those UIs by default. On the other hand, if this is too risky for backward compatibility, we should not do that. So, before doing that, we should collect actual usage data of object resizers, inline table editing UI, positioning UI of absolute positioned elements with telemetry probes. This patch adds 3 sets of probes for each UI. One is percentage of showing each UI in all instantiated HTMLEditor. The other is number of user interaction of each UI in HTMLEditors which has shown the UI. This patch makes all new probes as "opt-out" because they are really important data since used for deciding whether those UIs are necessary or unnecessary. MozReview-Commit-ID: B9Y6GTiCPw6

bug 1458720 - make RunOnAllContentParents runnable from any thread r=Ehsan,jcj In bug 1215723 RunOnAllContentParents was added to the DataStorage implementation so we could make more security state information available in child processes. It uses IPC APIs, which in general are not thread-safe. We need to make sure that these APIs are only accessed on the main thread, which means we have to copy any necessary data, create a runnable, and send it to the main thread to do the actual work. Note that the IPC APIs are async, so this dispatch can be async as well. MozReview-Commit-ID: HwkgSX1iORU

Bug 1459097 - Add words to en-US dictionary. r=ehsan

Bug 1454100 - Add some telemetry for time spent moving cookies r=Ehsan,francois,mayhemer MozReview-Commit-ID: 1pAiKaSok3J

Bug 1454100 - Move cookies around every X seconds r=Ehsan,mayhemer MozReview-Commit-ID: Y1zUvbDgDX

Bug 1451576 - Set dir=auto on [Browse...] button of <input type=file> r=Ehsan The label of the button comes from the UI; it's direction should be independent of the web content directionality. As there is no access to :-moz-locale-dir() selectors in HTML, we'll have to rely on auto-direction here. The alternative (or, addition to the fix here) would be adding the value of the dir attribute to HtmlForm.properties, allowing the localizers to set the directionality explicitly. I however don't know if that's necessary. MozReview-Commit-ID: 5NXeLtxLXVH

Bug 1451576 - Add dir=auto to subtitle menu items in video control r=Ehsan The labels of the subtitle track selections come from the web content, from <track label="...">. Given that it will likely be the name of the language in its native writing system, each of the item should have its own directionality, instead of inheriting direction: ltr set on the entire <xul:videocontrol> parent element. I do however wonders if the web content should have the opportunity to affect the directionality of these labels? We would need clarification from the spec to tell if this fix is already adequate. MozReview-Commit-ID: G4I2Wf9gFCu

Bug 1451576 - Allow dir=auto to work in native anonymous content r=Ehsan The rules set in place in bug 839886 and bug 1377826 prevents any native anonymous content to participate in auto-direction, both on having dir=auto to work on it and have it to affect the direction of non-anonymous dir=auto parent. This patch relax the rules a little bit by allowing the anonymous element with dir=auto to particiate in auto-direction. For simplicity, it would allow the text node in to affact auto-direction only if the text node is the direct children of the dir=auto parent. This patch is needed for HTML-based in-content widget to display RTL labels correctly. It shouldn't change any UI on its own; the purpose of the fix here is to display RTL-text filenames correctly when bug 1446830 is fixed. The change is needed in ResetDirectionSetByTextNode() because when CC clean-up the document, the function is called from nsTextNode::UnbindFromTree(). At that point, IsInAnonymousSubtree() will cause an assertion error on when calling SubtreeRoot(), since subtree hierarchy is already broken by earlier UnbindFormTree() calls to our parent nodes. Substitute that check with HasTextNodeDirectionalityMap() in and only in ResetDirectionSetByTextNode() should be ok -- given the function doesn't really do anything if HasTextNodeDirectionalityMap() is false. There is no need to call EnsureMapIsClearFor() when the condition is false either; EnsureMapIsClearFor() itself is a no-op if the condition is false. MozReview-Commit-ID: GqF5ypDZcbH

Bug 887889 - Fix leak in RemoteSpellCheckingEngineChild r=Ehsan The work to migrate to Sqlite.jsm seems to have caused a timing problem in our tests where shutdown the content process while this IPC message is still unresolved. This causes us to destroy RemoteSpellCheckingEngineChild without it having processed its RecvNotiy..., leading to the promise being leaked. As far as I can tell this resolves all of our leak issues on try. MozReview-Commit-ID: GdwVIp5dj1m

Bug 1454527 - Add words to en-US dictionary. r=ehsan

Bug 1455970 - Write test for cookies being synced across tabs r=Ehsan Adds a test for code landed in bug 1450199. Opens two tabs in different processes then sets cookies in one followed by checking the value in the other. MozReview-Commit-ID: 605k68Kl7nA

Bug 1455596 - Remove support for <panel backdrag="true"/>. r=enn,ehsan

Bug 1450199 - Cookie is not synced across tabs r=Ehsan This patch reverts parts of changeset e87e706def11 (bug 1425031). The problem in bug 1425031 was that when the content process set a cookie a notification was sent to the parent process. This notification was then forwarded to all the content processes, including the one it originated from. The solution was to not forward cookies that originated from a content process, but this causes the current bug. The correct fix is to forward the cookie changes to all content processes except the one they originated from. The test for bug 1425031 remains, and should keep passing. MozReview-Commit-ID: 1P6JwHQDy93

Bug 525063 - Initialize uninitialized class attributes in m-c. r=ehsan

Bug 1450620 - Add words to en-US dictionary. r=ehsan

Bug 1449925 - make the --private command line parameter work when browser.startup.blankWindow is true, r=Ehsan.

Bug 1448297 - Assume contiguous XPCOM strings in nsCookie.cpp. r=Ehsan MozReview-Commit-ID: 8aOh13vz6lM

Bug 1449571 - Re-enable JS_CRASH_DIAGNOSTICS on ASan builds. r=ehsan

Bug 1443080 - Now that we use static call, some var instances are not needed anymore r=Ehsan MozReview-Commit-ID: AiuJIY8Gssl

Bug 1443080 - Use the static call for static methods (not instance) r=Ehsan MozReview-Commit-ID: JwHh4bzxuTR

Bug 1445841 - Add words to en-US dictionary. r=ehsan

Bug 1442978 - Add words to en-US dictionary. r=ehsan

Bug 1443080 - Now that we use static call, some var instances are not needed anymore r=Ehsan MozReview-Commit-ID: AiuJIY8Gssl

Bug 1443080 - Use the static call for static methods (not instance) r=Ehsan MozReview-Commit-ID: JwHh4bzxuTR

Bug 1442200 - about:profiles passes a removeFiles boolean param to nsIToolkitProfile::removeInBackground, r=ehsan

Bug 1441496 - Add words to en-US dictionary. r=ehsan

Bug 1431550 - Add words to en-US dictionary. r=ehsan

Bug 1434772 - Ensure caches.open() throws SecurityError in PBM workers r=ehsan

Bug 1436354 - Enable modernize-use-bool-literals at review phase r=Ehsan This won't warn about existing defects. MozReview-Commit-ID: Fra6TmTREf2

Bug 1370794 - Use bool instead of integer being casted to bool r=Ehsan MozReview-Commit-ID: lUVFeU0Y0p

Bug 1370794 - Replace some 0 by false in the dom bindings code generation r=Ehsan MozReview-Commit-ID: IRErUEAlkTc

Bug 1436182 - Add a .mailmap file to mozilla-central, r=ehsan MozReview-Commit-ID: 2reDFK87sj8

Bug 1432915 - don't save download source url when aIsPrivate r=Ehsan MozReview-Commit-ID: 9mQjwcCtrWg

Bug 1360650 part 2 - Export VSINSTALLDIR so LLVM_ENABLE_DIA_SDK will be set. r=ehsan

Bug 1290948 - Part 2: webidl for RTCRtpTransceiver and supporting interfaces r+jib, r+ehsan r=ehsan+251051,jib MozReview-Commit-ID: DmXufKwCAyW

Bug 1290948 - Part 2: webidl for RTCRtpTransceiver and supporting interfaces r+jib, r+ehsan r=ehsan+251051,jib MozReview-Commit-ID: DmXufKwCAyW

Bug 1406818 - about:profile uses nsIToolkitProfile.removeInBackground, r=ehsan

Bug 1406818 - Introduce nsIToolkitProfile.removeInBackground to remove profile folder in a separate thread, r=ehsan

Bug 1348976 - let OffscreenCanvas::TransferToImageBitmap report its error. r=mtseng, r=ehsan MozReview-Commit-ID: 8x5i4ukIWe5

Bug 1404652: Part 1 - Add ChromeUtils.idleDispatch helper method. r=ehsan This is similar to Services.tm.idleDispatchToMainThread, but provides an IdleDeadline argument to its callbacks, the same way that Window.requestIdleCallback does. The IdleDeadline argument was necessary for my first attempt at this bug. It's not necessary for the current version, but I suspect it will be useful in other areas, and it also avoids some XPConnect overhead, so it's probably worth keeping. MozReview-Commit-ID: FtrbNkE7Vz5

Bug 1365894 - Make SystemGroupImpl be a normal ref-counted object. r=ehsan MozReview-Commit-ID: LUcoBhNx2M5

Bug 1406485 - provide PermissionHashKey with a move constructor; r=ehsan

Bug 1406442 - Improve IPCShutdownState annotation for SendFinishShutdown state to know message status. r=ehsan

Bug 1405602 - Add clang-apply-replacements to the clang-tidy build generated by toolchains. r=ehsan MozReview-Commit-ID: 1BT2ukzLoC3

Bug 1402944: Part 9 - Optimize request/response header handling. r=mixedpuppy,ehsan We don't use the initial Map returned by ChannelWrapper as a map, so there's no need for the overhead involved in creating it. We also don't need the header map generated by HeaderChanger unless headers are actually being modified, which for many listeners they never are, so there's no need for the map creation and string lower-casing overhead prior to modification time. MozReview-Commit-ID: K2uK93Oo542

Bug 1402944: Part 7 - Move traceable channel registration to ChannelWrapper. r=mixedpuppy,ehsan MozReview-Commit-ID: 6hGmh4VpJMQ

Bug 1402944: Part 5 - Move request filtering and permission matching into ChannelWrapper. r=mixedpuppy,ehsan This allows us to reuse the same URLInfo objects for each permission or extension that we match, and also avoids a lot of XPConnect overhead we wind up incurring when we access URI objects from the JS side. MozReview-Commit-ID: GqgVRjQ3wYQ