a1c6c6703dfb8f75651820685c2260a14e03243f: Bug 1502033 - Implement partial write for memInit, memFill, memCopy. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Fri, 25 Jan 2019 17:00:28 +0100 - rev 458172
Push 111773 by lhansen@mozilla.com at Fri, 08 Feb 2019 09:30:03 +0000
Bug 1502033 - Implement partial write for memInit, memFill, memCopy. r=jseward The new rules for bounds checks for the bulk operations are that they are per-element, this means we'll read and write individual elements (bytes, table slots) until we hit an error or we've finished the task according to the parameters. Furthermore, reading and writing is from low addresses toward higher as a general rule. However, for memory.copy, if the source and target regions overlap and src < target then the direction is higher toward lower. In the absence of a memory.protect instruction (that could render pages in the memory inaccessible) or a memory.shrink instruction (ditto) this is pretty straightforward. This is so even in shared memory that can be growing concurrently with the bulk operation, since there are no fences and the write order therefore is not actually observable absent a trap. We obtain the memory size, compute the in-bounds portion of the source and target, and perform the operation using a standard libc-level bulk operation. If there were out-of-bounds portions of the source or target we then throw an exception. Note that in the case of high-to-low order for memory copy this may mean nothing is written (because we're OOB at the high end of the regions, where we start reading and writing). One final wrinkle is that we can't error out for arithmetic overflow when we compute the bounds: we must work as-if we're checking the source bound, reading the source byte, checking the target bound, writing the target byte, and so on. So we go from using CheckedInt for arithmetic to using 64-bit integers. Additionally, we need to be mindful to use safe-for-races operations when we might be operating on shared memory.
1431d60aedcc42552e70fc5e6c2f882aaf99187b: Bug 1523908 - Require zero byte encoding for memory/table index in the absence of multi-memory/multi-table. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Mon, 04 Feb 2019 14:31:13 +0100 - rev 458171
Push 111773 by lhansen@mozilla.com at Fri, 08 Feb 2019 09:30:03 +0000
Bug 1523908 - Require zero byte encoding for memory/table index in the absence of multi-memory/multi-table. r=jseward Once we have the reftypes proposal (which we already have, but behind another ifdef) we'll need to go to varuint32 for the table index but not for the memory index, hence a wee bit of complexity here, hidden behind a function.
5d720cbe1187b8ef658ab5098fdaf9f36e532504: Bug 1521939 - Correct the offset for reading stack args on ARM64. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 07 Feb 2019 11:12:06 +0100 - rev 458170
Push 111772 by lhansen@mozilla.com at Fri, 08 Feb 2019 09:16:15 +0000
Bug 1521939 - Correct the offset for reading stack args on ARM64. r=bbouvier In the optimized stub, we forgot to account for the frameAlignExtra word when computing the offset from the SP at which stack args are read. The test case finds the problem on the ARM64 simulator, and does not need any special parameters, just to run long enough for a JS JIT to kick in. Also a drive-by fix for an incorrect NaN canonicalization along the non-toValue path, cf the Double case right above it. This code changed recently when I introduced the ScratchFloat32Scope, but the bug predates that. Differential Revision: https://phabricator.services.mozilla.com/D18942
7e9ceabc7541c9f746f99717f228092f78f4bd28: Bug 1507049 - Rename MOZ_CRASH_UNSAFE_OOL MOZ_CRASH_UNSAFE. r=froydnj
Chris Peterson <cpeterson@mozilla.com> - Sun, 03 Feb 2019 00:09:37 -0800 - rev 458169
Push 111771 by cpeterson@mozilla.com at Fri, 08 Feb 2019 07:08:19 +0000
Bug 1507049 - Rename MOZ_CRASH_UNSAFE_OOL MOZ_CRASH_UNSAFE. r=froydnj Differential Revision: https://phabricator.services.mozilla.com/D18515
426f2e129858941cd1e19aab3695659c728af9e5: Bug 1507049 - Rename GeckoCrashOOL GeckoCrash. r=froydnj
Chris Peterson <cpeterson@mozilla.com> - Sun, 03 Feb 2019 00:02:30 -0800 - rev 458168
Push 111771 by cpeterson@mozilla.com at Fri, 08 Feb 2019 07:08:19 +0000
Bug 1507049 - Rename GeckoCrashOOL GeckoCrash. r=froydnj Differential Revision: https://phabricator.services.mozilla.com/D18514
70d80c4a3fa0b6a383298766f658e4a95ce15e99: Bug 1507049 - Rename MOZ_CrashOOL MOZ_Crash. r=froydnj
Chris Peterson <cpeterson@mozilla.com> - Sun, 03 Feb 2019 00:00:12 -0800 - rev 458167
Push 111771 by cpeterson@mozilla.com at Fri, 08 Feb 2019 07:08:19 +0000
Bug 1507049 - Rename MOZ_CrashOOL MOZ_Crash. r=froydnj Differential Revision: https://phabricator.services.mozilla.com/D18513
57b1f35d3f9c57f372c54a0f26c3f8c57a781b96: Merge mozilla-central to mozilla-inbound. a=merge on a CLOSED TREE
Razvan Maries <rmaries@mozilla.com> - Fri, 08 Feb 2019 06:26:00 +0200 - rev 458166
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Merge mozilla-central to mozilla-inbound. a=merge on a CLOSED TREE
d599d1a73a3a87bd11763c0cc52c0af45c67e8dc: Bug 1525747 - Remove XUL grid layout from browser/components/preferences/sanitize.xul. r=Gijs
Tim Nguyen <ntim.bugs@gmail.com> - Thu, 07 Feb 2019 16:50:47 +0000 - rev 458165
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1525747 - Remove XUL grid layout from browser/components/preferences/sanitize.xul. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D18887
760191b55ab399d033c0d24293112514e3c84cde: Bug 1525739 - Remove XUL grid layout from browser/base/content/sanitize.xul. r=Gijs
Tim Nguyen <ntim.bugs@gmail.com> - Thu, 07 Feb 2019 22:12:42 +0000 - rev 458164
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1525739 - Remove XUL grid layout from browser/base/content/sanitize.xul. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D18885
cba914a4f50cb65b25d46dc325eaba9b65205687: Bug 1372133 - Add SH_REWRITE_TEXELFETCHOFFSET_TO_TEXELFETCH for Mac+Intel. r=lsalzman
Jeff Gilbert <jgilbert@mozilla.com> - Thu, 07 Feb 2019 18:05:03 +0000 - rev 458163
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1372133 - Add SH_REWRITE_TEXELFETCHOFFSET_TO_TEXELFETCH for Mac+Intel. r=lsalzman MozReview-Commit-ID: 2WV4jKx6Grh Differential Revision: https://phabricator.services.mozilla.com/D18905
c7ac7a7c954266d7814f4a3b9233aed10f97e099: Bug 1372156 - Color+[U]Int formats should have maxSamples=0. r=lsalzman
Jeff Gilbert <jgilbert@mozilla.com> - Thu, 07 Feb 2019 18:04:29 +0000 - rev 458162
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1372156 - Color+[U]Int formats should have maxSamples=0. r=lsalzman MozReview-Commit-ID: 22PoVlplJNT Differential Revision: https://phabricator.services.mozilla.com/D18900
8254ca56d9f118ec48dfb6a74a6eb34723011a10: Bug 1371694 - Strip `invariant` on Mac. r=lsalzman
Jeff Gilbert <jgilbert@mozilla.com> - Thu, 07 Feb 2019 18:02:54 +0000 - rev 458161
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1371694 - Strip `invariant` on Mac. r=lsalzman MozReview-Commit-ID: 5thQThRUBOY Differential Revision: https://phabricator.services.mozilla.com/D18902
016e46630cea3b2e43d2ab136b20092c9548f8d2: Bug 1509549 - Add "WebAssembly" to the list of globals that are present in JSMs. r=Standard8
Markus Stange <mstange@themasta.com> - Thu, 07 Feb 2019 19:36:41 +0000 - rev 458160
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1509549 - Add "WebAssembly" to the list of globals that are present in JSMs. r=Standard8 Differential Revision: https://phabricator.services.mozilla.com/D13004
22322a39835a1c9dd514ddcfa46452a8f285117a: Bug 1525741 - Support animating yaml files in wrench. r=kvark
Glenn Watson <github@intuitionlibrary.com> - Thu, 07 Feb 2019 18:03:59 +0000 - rev 458159
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1525741 - Support animating yaml files in wrench. r=kvark Add support for supplying a keyframe file to animate a wrench yaml file with. For now, the keyframe animation file must supply a keyframe for every frame. In future, we may expand this to allow specifying interpolation ranges. For now, this is for development purposes only - however we can easily extend this to support animated reftests in the future. Differential Revision: https://phabricator.services.mozilla.com/D18884
f110ae482730f491e621bae28ee5bb145d127670: Bug 1524857 - Part 2: Use display URI's base domain for domain highlighting. r=snorp
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 07 Feb 2019 19:21:45 +0000 - rev 458158
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1524857 - Part 2: Use display URI's base domain for domain highlighting. r=snorp That way, domain highlighting (and therefore the URL justification code that right-justifies the TLD within the URL bar) can run even on error pages. This also means that the workaround from bug 1479311 for blocking javascript: URIs from being highlighted in ToolbarDisplayLayout is no longer required - the base domain for domain highlighting is now being generated from the same URI that actually ends up being displayed in the URL bar, and as such the existing checks in browser.js for only generating a base domain for HTTP(S)/ FTP-URIs, but not any other schemes, finally work the way they are intended. Differential Revision: https://phabricator.services.mozilla.com/D18587
d32c9ce0d3661194e8f6d850e52e6b794f24b05e: Bug 1524857 - Part 1: Separate base domain for doorhangers from base domain used for domain highlighting. r=Gijs
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 07 Feb 2019 19:23:47 +0000 - rev 458157
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1524857 - Part 1: Separate base domain for doorhangers from base domain used for domain highlighting. r=Gijs Currently, the Android front-end uses a tab's base domain both for permission prompt doorhangers, as well as for doing domain highlighting in the URL bar. The base domain in turn is based on the document's nodePrincipal's URI. As per bug 1325955, the nodePrincipal is the right choice for permission prompts, but it causes some problems for domain highlighting instead: For error pages for example, the nodePrincipal's URI will be some variety of about:neterror, which means that the front-end won't be able to do any domain highlighting based on that, since a) we don't generate any baseDomain anyway because the URI's scheme isn't HTTP(S)/FTP, and b) even if we did, the nodePrincipal's baseDomain won't match the contents of the URI displayed in the URL bar. Therefore, we want to separate these two concerns, and generate two baseDomains: One based on the nodePrincipal for use in permission prompts, and one based on the display URI, which going forward will power our domain highlighting. Differential Revision: https://phabricator.services.mozilla.com/D18586
858b4a542bf417cdefb380bc293be7a523d67bea: Bug 1524857 - Part 0: Use short form where possible for defining properties. r=Gijs
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 07 Feb 2019 19:21:27 +0000 - rev 458156
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1524857 - Part 0: Use short form where possible for defining properties. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D18585
1b2817234164d9a6fd06e993495af9558dceda2a: Bug 1523703 - Part 2. Set discovery stream pref to [] for tests r=andreio
k88hudson <k88hudson@gmail.com> - Thu, 07 Feb 2019 18:44:26 +0000 - rev 458155
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1523703 - Part 2. Set discovery stream pref to [] for tests r=andreio Differential Revision: https://phabricator.services.mozilla.com/D18992
55f7952d947c940951cb04bc2da69b9a3779f5da: Bug 1524227 Replacing getParentProcessScalar with generic getProcessScalar r=chutten
Varun Dey <varundey20@gmail.com> - Thu, 07 Feb 2019 18:11:56 +0000 - rev 458154
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1524227 Replacing getParentProcessScalar with generic getProcessScalar r=chutten Replacing existing getParentProcessScalars with a generic implementation of getProcessScalars Differential Revision: https://phabricator.services.mozilla.com/D18861
1fb53779a65c7b12f10b61c288e0bd20776443b8: Bug 1525818 - Remove NS_ASSERTION in ImageBridgeParent::GetInstance() r=mattwoodrow
sotaro <sotaro.ikeda.g@gmail.com> - Thu, 07 Feb 2019 20:28:30 +0000 - rev 458153
Push 111770 by rmaries@mozilla.com at Fri, 08 Feb 2019 04:28:50 +0000
Bug 1525818 - Remove NS_ASSERTION in ImageBridgeParent::GetInstance() r=mattwoodrow Sometimes NS_ASSERTION was hit during window closing. It happens because of aync architecture. It is better to change the NS_ASSERTION to NS_WARNING. Differential Revision: https://phabricator.services.mozilla.com/D18920
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip