cedcea79c48d7a3a3381dbcdb3536f660c43ec0d: Bug 1415042 - Wait for two requestAnimationFrames to ensure that animations have been tried to send to the compositor in test_animation_performance_warning.html. r?birtles draft
Hiroyuki Ikezoe <hikezoe@mozilla.com> - Tue, 07 Nov 2017 14:49:59 +0900 - rev 693934
Push 87989 by hikezoe@mozilla.com at Tue, 07 Nov 2017 05:53:46 +0000
Bug 1415042 - Wait for two requestAnimationFrames to ensure that animations have been tried to send to the compositor in test_animation_performance_warning.html. r?birtles To do that, ideally we can wait for MozAfterPaint, but it's sometimes fired before we do a paint process (bug 1341294), we should avoid using it until that bug is fixed. So, we wait for two requestAnimationFrames instead. The callback for requestAnimationFrame is called before styling process, so we need to wait for one more frame there. For now a Promise in waitForFrame is processed after paint process, so these tests would have been working fine with waiting for a single requestAnimationFrame. But after bug 1193394, the Promise will be processed right after requestAnimationFrame, thus these tests will fail with a single requestAnimationFrame. MozReview-Commit-ID: 4pbofZ3DUm3
2d3692c0e411efec60618eabd4183e7f7d4fc26e: Bug 1414981 - Request URL show not show #hash;r=honza draft
Fred Lin <gasolin@gmail.com> - Tue, 07 Nov 2017 13:46:57 +0800 - rev 693933
Push 87988 by bmo:gasolin@mozilla.com at Tue, 07 Nov 2017 05:47:14 +0000
Bug 1414981 - Request URL show not show #hash;r=honza MozReview-Commit-ID: G3FqltGcaTC
bff0b0c683b8817c12fbed30de9f8e01db4d039a: Bug 1414581 - Part 2. Add crashtest. r?masayuki draft
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Mon, 06 Nov 2017 17:06:09 +0900 - rev 693932
Push 87987 by bmo:m_kato@ga2.so-net.ne.jp at Tue, 07 Nov 2017 05:16:46 +0000
Bug 1414581 - Part 2. Add crashtest. r?masayuki MozReview-Commit-ID: 3H4DSubkt0q
fae582b35127395e9ddaa13933c592d1e3eb03d4: Bug 1414581 - Part 1. Require more nullptr check of parent node. r?masayuki draft
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Mon, 06 Nov 2017 17:05:37 +0900 - rev 693931
Push 87987 by bmo:m_kato@ga2.so-net.ne.jp at Tue, 07 Nov 2017 05:16:46 +0000
Bug 1414581 - Part 1. Require more nullptr check of parent node. r?masayuki Bug 1402904 added nullptr check for parent node, but I forgot to add this for this situation. So I need to add more nullptr check. MozReview-Commit-ID: Au9wrG6htk8
9b5beda35a4387c56b9f6951a002d18eb229df40: Bug 1339731 - Refactor FormAutofillHandler to support multiple section machanism. r=lchang,ralin draft
Sean Lee <selee@mozilla.com> - Thu, 26 Oct 2017 17:57:36 +0800 - rev 693930
Push 87986 by bmo:selee@mozilla.com at Tue, 07 Nov 2017 05:14:47 +0000
Bug 1339731 - Refactor FormAutofillHandler to support multiple section machanism. r=lchang,ralin MozReview-Commit-ID: D9g5fKTeTaL
357cbff2b45b7f339166e1c67f0e9704470f0102: bug 1409622 initialize mTime even in Stream AudioTimelineEvents r?padenot draft
Karl Tomlinson <karlt+@karlt.net> - Tue, 07 Nov 2017 13:14:22 +1300 - rev 693929
Push 87985 by ktomlinson@mozilla.com at Tue, 07 Nov 2017 05:14:09 +0000
bug 1409622 initialize mTime even in Stream AudioTimelineEvents r?padenot to avoid uninitialized read in WebAudioUtils::ConvertAudioTimelineEventToTicks() MozReview-Commit-ID: GHPGIrc0T2h
c0b1f09b3e545f90ffe8607649fa7433d070cdfe: Bug 1390158 - Notify user of extension controlling New Tab on first access r?aswan r?jaws draft
Mark Striemer <mstriemer@mozilla.com> - Fri, 27 Oct 2017 12:16:21 -0500 - rev 693928
Push 87984 by bmo:mstriemer@mozilla.com at Tue, 07 Nov 2017 05:04:33 +0000
Bug 1390158 - Notify user of extension controlling New Tab on first access r?aswan r?jaws MozReview-Commit-ID: 1g9d4UTuOgr
4375153f40797e9ddd7c423e0cd5efb3e255adb0: Bug 1412837 - damp fix draft
Fred Lin <gasolin@gmail.com> - Tue, 07 Nov 2017 12:57:04 +0800 - rev 693927
Push 87983 by bmo:gasolin@mozilla.com at Tue, 07 Nov 2017 04:57:48 +0000
Bug 1412837 - damp fix MozReview-Commit-ID: 8Re5mtdjTMm
77068f53090527e57c901eab823167a81420c02b: Bug 1412837 - no default getstack draft
Fred Lin <gasolin@gmail.com> - Fri, 03 Nov 2017 11:53:32 +0800 - rev 693926
Push 87983 by bmo:gasolin@mozilla.com at Tue, 07 Nov 2017 04:57:48 +0000
Bug 1412837 - no default getstack MozReview-Commit-ID: 8vrfOxk8W20
a64b624d49c99d989713d614d418e04a0685b734: Bug 1414713 - EditorUtils::IsDescendantOf() should take EditorDOMPoint and EditorRawDOMPoint as out param r?m_kato, catalinb draft
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 06 Nov 2017 17:01:33 +0900 - rev 693925
Push 87982 by masayuki@d-toybox.com at Tue, 07 Nov 2017 04:29:55 +0000
Bug 1414713 - EditorUtils::IsDescendantOf() should take EditorDOMPoint and EditorRawDOMPoint as out param r?m_kato, catalinb EditorUtils::IsDescendantOf() current takes a pointer to offset or a pointer to child content if the caller needs to know the child of the most ancestor node. However, some callers should get a child as EditorDOMPoint or EditorRawDOMPoint. Then, they can be used for some editor methods which need to take child node for performance optimization. This patch makes EditorUtils::IsDescendantOf() as only two overloads. One takes pointer to EditorRawDOMPoint as optional out argument. The other takes pointer to EditorDOMPoint as an out param. Additionally, this creates new constructor of AutoTrackDOMPoint for making it can treat EditorDOMPoint directly. MozReview-Commit-ID: IsAGTUvKI19
b370bb0592a060ddfebb606fdf4e02137b6eda7d: Bug 1413487 - [Form Autofill] Split "cc-exp" into "cc-exp-month" and "cc-exp-year" in the storage. r=seanlee draft
Luke Chang <lchang@mozilla.com> - Thu, 02 Nov 2017 12:19:22 +0800 - rev 693924
Push 87981 by bmo:lchang@mozilla.com at Tue, 07 Nov 2017 04:21:55 +0000
Bug 1413487 - [Form Autofill] Split "cc-exp" into "cc-exp-month" and "cc-exp-year" in the storage. r=seanlee MozReview-Commit-ID: 1JKJFudYWHb
01cfc1cbea3f97e71626324682c68c093d7b9526: Bug 1415042 - Wait for two requestAnimationFrames to ensure that animations have been tried to send to the compositor in test_running_on_compositor.html. r?birtles draft
Hiroyuki Ikezoe <hikezoe@mozilla.com> - Tue, 07 Nov 2017 13:21:01 +0900 - rev 693923
Push 87980 by hikezoe@mozilla.com at Tue, 07 Nov 2017 04:21:30 +0000
Bug 1415042 - Wait for two requestAnimationFrames to ensure that animations have been tried to send to the compositor in test_running_on_compositor.html. r?birtles MozReview-Commit-ID: FhzRLiKiLC
aecd7ce86b3736068cdb0cae9e228516f0d400c7: Bug 1415042 - Use arrow function in test_running_on_compositor.html. r?birtles draft
Hiroyuki Ikezoe <hikezoe@mozilla.com> - Tue, 07 Nov 2017 13:21:01 +0900 - rev 693922
Push 87980 by hikezoe@mozilla.com at Tue, 07 Nov 2017 04:21:30 +0000
Bug 1415042 - Use arrow function in test_running_on_compositor.html. r?birtles MozReview-Commit-ID: 2zAMkTVK9VE
599d4f06747cbae51b2186aa0156e6a02dca99fd: Bug 1415042 - Wait for two requestAnimationFrames to ensure that animations have been tried to send to the compositor in test_animation_performance_warning.html. r?birtles draft
Hiroyuki Ikezoe <hikezoe@mozilla.com> - Tue, 07 Nov 2017 13:21:01 +0900 - rev 693921
Push 87980 by hikezoe@mozilla.com at Tue, 07 Nov 2017 04:21:30 +0000
Bug 1415042 - Wait for two requestAnimationFrames to ensure that animations have been tried to send to the compositor in test_animation_performance_warning.html. r?birtles To do that, ideally we can wait for MozAfterPaint, but it's sometimes fired before we do a paint process (bug 1341294), we should avoid using it until that bug is fixed. So, we wait for two requestAnimationFrames instead. The callback for requestAnimationFrame is called before styling process, so we need to wait for one more frame there. For now a Promise in waitForFrame is processed after paint process, so these tests would have been working fine with waiting for a single requestAnimationFrame. But after bug 1193394, the Promise will be processed right after requestAnimationFrame, thus these tests will fail with a single requestAnimationFrame. MozReview-Commit-ID: 4pbofZ3DUm3
97b647545e766e55a2f48facac50a077646138ac: Bug 1415042 - Use arrow function in test_animation_performance_warning.html. r?birtles draft
Hiroyuki Ikezoe <hikezoe@mozilla.com> - Tue, 07 Nov 2017 13:21:01 +0900 - rev 693920
Push 87980 by hikezoe@mozilla.com at Tue, 07 Nov 2017 04:21:30 +0000
Bug 1415042 - Use arrow function in test_animation_performance_warning.html. r?birtles MozReview-Commit-ID: JjrL5Tx6y5F
12af8de3d244285b1442b6bd2c4337555dbd0104: Bug 1414740 - Insert info log before async helper functions in form autofill mochitests. r=lchang draft
Ray Lin <ralin@mozilla.com> - Mon, 06 Nov 2017 17:58:41 +0800 - rev 693919
Push 87979 by bmo:ralin@mozilla.com at Tue, 07 Nov 2017 04:06:37 +0000
Bug 1414740 - Insert info log before async helper functions in form autofill mochitests. r=lchang MozReview-Commit-ID: JJN7R2WC2D4
d15a34e7944bfc31b451c21072a1ef933d2bc369: Bug 1414370 - Emit ldflags in directories containing only rust programs for the benefit of cargo. draft
Chris Manchester <cmanchester@mozilla.com> - Mon, 06 Nov 2017 19:57:12 -0800 - rev 693918
Push 87978 by cmanchester@mozilla.com at Tue, 07 Nov 2017 03:57:48 +0000
Bug 1414370 - Emit ldflags in directories containing only rust programs for the benefit of cargo. MozReview-Commit-ID: 6gD7kAIQbtB
06be91e5fe089aacba40236419e4667c4ac69a0f: Bug 1408544 - part 2: RangeBoundaryBase shouldn't compute mRef when mOffset is specified r?catalinb draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Nov 2017 21:25:14 +0900 - rev 693917
Push 87977 by masayuki@d-toybox.com at Tue, 07 Nov 2017 03:51:22 +0000
Bug 1408544 - part 2: RangeBoundaryBase shouldn't compute mRef when mOffset is specified r?catalinb RangeBoundaryBase shouldn't compute mRef when it's initialized with offset. E.g., some users of the template class may initialize it with a container and offset in it but it may not refer mRef or may refer after modifying offset. On the other hand, RangeBoundaryBase::InvalidateOffset() is a special method. It assumes that mRef is always initialized when it's called but can be invalidate mOffset until retrieved actually. This is necessary for nsRange::mStart and nsRange::mEnd since the offset may be changed when some nodes are inserted before the referring node. So, now, InvalidateOffset() should be a protected method and make nsRange a friend class of RangeBoundaryBase. Then, when nsRange sets mStart and/or mEnd, nsRange itself should guarantee that their mRefs are initialized. MozReview-Commit-ID: Alr4YkDXIND
115e81107ed8981f28858318127deec1bf426f29: Bug 1408544 - part 1: Reimplement EditorDOMPoint as a subclass of RangeBoundary r?m_kato, catalinb draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 01 Nov 2017 14:41:03 +0900 - rev 693916
Push 87977 by masayuki@d-toybox.com at Tue, 07 Nov 2017 03:51:22 +0000
Bug 1408544 - part 1: Reimplement EditorDOMPoint as a subclass of RangeBoundary r?m_kato, catalinb A lot of methods in editor returns a child offset with an out param when it returns its container and offset in the container. This is ugly hack for performance of nsINode::IndexOf(). However, there are a lot of regression since the relation between offset and child node can be broken really easily. So, we should make EditorDOMPoint as a subclass of RangeBoundary and manage a set of container, reference child and its offset in it (e.g., SetNextSibling() added by this patch). Note that RangeBoundary's performance is not good for temporary use if we set a point with offset, it immediately retrieves mRef. The following patch will improve this performance. MozReview-Commit-ID: 7mcJ1P1OjVr
fed7535040587a57d34b2c67522d753c5b1366cb: Bug 1415042 - Wait for two requestAnimationFrames to ensure that animations have been tried to send to the compositor. r?birtles draft
Hiroyuki Ikezoe <hikezoe@mozilla.com> - Tue, 07 Nov 2017 12:46:51 +0900 - rev 693915
Push 87976 by hikezoe@mozilla.com at Tue, 07 Nov 2017 03:48:08 +0000
Bug 1415042 - Wait for two requestAnimationFrames to ensure that animations have been tried to send to the compositor. r?birtles To do that, ideally we can wait for MozAfterPaint, but it's sometimes fired before we do a paint process (bug 1341294), we should avoid using it until that bug is fixed. So, we wait for two requestAnimationFrames instead. The callback for requestAnimationFrame is called before styling process, so we need to wait for one more frame there. For now a Promise in waitForFrame is processed after paint process, so these tests would have been working fine with waiting for a single requestAnimationFrame. But after bug 1193394, the Promise will be processed right after requestAnimationFrame, thus these tests will fail with a single requestAnimationFrame. MozReview-Commit-ID: 4pbofZ3DUm3
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip