0eac6bd98bd0bedff228108ec924c87b38762c7a: Bug 1088305 - Adjusted browser theme test to check Firebug theme; r=jdescottes
Sebastian Zartner <sebastianzartner@gmail.com> - Sat, 08 Oct 2016 01:54:17 +0200 - rev 360643
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1088305 - Adjusted browser theme test to check Firebug theme; r=jdescottes MozReview-Commit-ID: 4mCaF46aLx8
720ec39fe42b2a2b834dca6513f4281ab66d1fc2: Bug 1088305 - Allowed to customize the text color of the font preview tooltip; r=jdescottes
Sebastian Zartner <sebastianzartner@gmail.com> - Thu, 06 Oct 2016 22:43:57 +0200 - rev 360642
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1088305 - Allowed to customize the text color of the font preview tooltip; r=jdescottes MozReview-Commit-ID: 4dESdQNgwRA
752382b58cc46c9158af0f5325b388b32fd8d35d: Bug 1304689 - Ensure frame reconstructions don't clobber a 'stronger' scroll origin with a 'weaker' one. r=tnikkel
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 11 Oct 2016 09:36:22 -0400 - rev 360641
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1304689 - Ensure frame reconstructions don't clobber a 'stronger' scroll origin with a 'weaker' one. r=tnikkel If, within a single refresh driver tick, the scroll position is updated by JS explicitly, and then subsequently also updated by a frame reconstruction, the scroll origin from the former (nsGkAtoms::other) can get clobbered by the latter (to nsGkAtoms::restore). The restore scroll origin is "weaker" in that it can be ignored by the APZ code in some circumstances. This is undesirable because it means the JS scroll update also gets ignored. This patch ensures that when setting the scroll origin we don't do this clobbering of stronger origins with weaker origins. MozReview-Commit-ID: DA4EHp1Debu
c07923f57466df5e436ec55c0112d89d59ac3e39: Bug 1309589 - Cleanup old loop.* preferences in profiles after Firefox Hello removal. r=mikedeboer
Mark Banner <standard8@mozilla.com> - Wed, 12 Oct 2016 16:08:55 +0100 - rev 360640
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1309589 - Cleanup old loop.* preferences in profiles after Firefox Hello removal. r=mikedeboer MozReview-Commit-ID: KNOJzUL7hRv
971b4fc7d1f4a23a10f083b6d35a947ab6a8b929: Bug 1309794 - Make RefCnt types non-copyable. r=froydnj
Xidorn Quan <me@upsuper.org> - Thu, 13 Oct 2016 16:52:54 +1100 - rev 360639
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1309794 - Make RefCnt types non-copyable. r=froydnj MozReview-Commit-ID: Lx344xrXDZT
4e2c6be6037962a0d5b9ad868e47278d71d5a535: Bug 1306551 - don't update playback position for video-only seek when seek is completed. r=kaku
JW Wang <jwwang@mozilla.com> - Thu, 06 Oct 2016 17:06:58 +0800 - rev 360638
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1306551 - don't update playback position for video-only seek when seek is completed. r=kaku MozReview-Commit-ID: 7vByX0pPNo
3c6457fdf27c0f4d092049fafea3b21a41ebbc77: Merge mozilla-central to autoland
Carsten "Tomcat" Book <cbook@mozilla.com> - Thu, 13 Oct 2016 12:00:23 +0200 - rev 360637
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Merge mozilla-central to autoland
70d19ed29c980ba3d6825e5286bda08fa7dc676f: Bug 1306639 - Searching in locationbar by typing something and pressing enter is not accounted in telemetry. r=adw
Marco Bonardo <mbonardo@mozilla.com> - Thu, 06 Oct 2016 17:40:13 +0200 - rev 360636
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1306639 - Searching in locationbar by typing something and pressing enter is not accounted in telemetry. r=adw MozReview-Commit-ID: 9r8IyyyxruC
64cd7d87e78cf2e4b919aad10fb9f4962834b004: Bug 1309593 - remove b2g, mulet, graphene, horizon references from mozharness. r=catlee
Joel Maher - Wed, 12 Oct 2016 19:20:02 +0000 - rev 360635
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1309593 - remove b2g, mulet, graphene, horizon references from mozharness. r=catlee MozReview-Commit-ID: JdrltSor9dL
d3cf438132337bcc7f615859863271a95f746a28: Bug 1304620 part.5 ContentCacheInParent should store the latest composition start offset with mCompositionStartInChild r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 12 Oct 2016 21:52:01 +0900 - rev 360634
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1304620 part.5 ContentCacheInParent should store the latest composition start offset with mCompositionStartInChild r=m_kato When ContentCacheInParent receives eCompositionStart, it temporarily sets mCompositionStart to selection start offset. However, if there is a composition in the remote process, the selection start is caret position in the composition string. Therefore, it's not useful information. Instead, the composition start offset should be used because around there are a lot of information. For that, ContentCacheInParent should always store compostion start offset in the remote process with mCompositionStartInChild even if mWidgetHasComposition is false. And when it receives eCompositionStart, mCompositionStart should be set to mCompositionStartInChild. MozReview-Commit-ID: DksPNEsi6Ec
aa2c12432274f8926ffbc3b35502eedf176034b1: Bug 1304620 part.4 ContentCacheInParent::mCompositionStart should be set to better value for mWidgetHasComposition state r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 12 Oct 2016 22:05:09 +0900 - rev 360633
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1304620 part.4 ContentCacheInParent::mCompositionStart should be set to better value for mWidgetHasComposition state r=m_kato ContentCacheInParent::mCompositionStart was set to ContentCacheInChild::mCompositionStart without any check. However, that's clearly wrong approach. For example, when the remote process handles some composition events after eCompositionCommit(AsIs) in the parent process, mCompositionStart is valid offset even after mWidgetHasComposition is set to false. Similarly, even after parent process sends eCompositionStart, the remote process may send invalid offset for mCompositionStart due to no composition in it. For solving this issue, ContentCacheInParent should check mWidgetHasComposition. If it's true and coming offset is valid, let's use it (even if mPendingCompositionCount is 2 or bigger since widget shouldn't use WidgetQueryContentEvent when there are some pending events). If the coming offset is invalid but mWidgetHasComposition is false, let's use selection start instead because HandleQueryContentEvent() can work around selection start offset only. Otherwise, i.e., mWidgetHasComposition is false, we should always set mCompositionStart to invalid offset. MozReview-Commit-ID: IONU0Cbhpil
64f030acc66bae6f210b5d8a2d82e38993bde2cf: Bug 1304620 part.3 The start offset of TextComposition instance in the parent process shouldn't be updated with older composition in the remote process r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 12 Oct 2016 22:03:16 +0900 - rev 360632
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1304620 part.3 The start offset of TextComposition instance in the parent process shouldn't be updated with older composition in the remote process r=m_kato When ContentCacheInParent receives content information from the remote process, it notifies TextComposition of the latest composition start offset in the remote process. However, the information may be older composition's, i.e., the composition was already committed in the process but is still being handled by the remote process. TextComposition shouldn't work with such obsolete information. Note that TextComposition instance is created and destroyed when WidgetCompostionEvent is handled by IMEStateManager. Then, TextComposition instance guarantees that all following composition events for a composition are sent to same EventTarget (including TabParent). So, TextComposition is always synced with a composition in widget. MozReview-Commit-ID: 78NuvpE2rPx
97cb51652c868d8698c966ad0483f1421be1d449: Bug 1304620 part.2 ContentCacheInParent should manage if there is pending composition in the remote process r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 12 Oct 2016 17:09:02 +0900 - rev 360631
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1304620 part.2 ContentCacheInParent should manage if there is pending composition in the remote process r=m_kato If the remote process is busy or user restarts composition too quickly, there could be 2 or more compositions in ContentCache. For managing such case, ContentCacheInParent should manage the pending composition count which is increased at dispatching eCompositionStart event to the remote process and decreased at receiving eCompositionCommit(AsIs) event from the remote process. MozReview-Commit-ID: KbTsK20NEZD
8bea9647dc86865e874f346a3fccc14565ce3f65: Bug 1304620 part.1 Rename ContentCacheInParent::mIsComposing to mWidgetHasComposition r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 12 Oct 2016 16:42:28 +0900 - rev 360630
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1304620 part.1 Rename ContentCacheInParent::mIsComposing to mWidgetHasComposition r=m_kato For making the meaning of ContentCacheInParent::mIsComposing clearer, let's rename it to mWidgetHasComposition. It becomes true when the parent process sends eCompositionStart to the remote process and false when the parent process sends eCompositionCommit(AsIs). So, it represents if the widget (i.e., the native IME handler in the chrome process) has composition. MozReview-Commit-ID: 5k05IXMgJxw
84286e454b4e67a193470eb68fb2a504835999fd: Backed out changeset fe84473a739c (bug 567954) for failing mda tests due to own test
Carsten "Tomcat" Book <cbook@mozilla.com> - Thu, 13 Oct 2016 11:32:45 +0200 - rev 360629
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Backed out changeset fe84473a739c (bug 567954) for failing mda tests due to own test
ce9ca1a342bcc7cff3074c111eeb16e3ecf9a905: Bug 1309650 - remove non remote friendly APIs from selection.js;r=pbro
Julian Descottes <jdescottes@mozilla.com> - Wed, 12 Oct 2016 20:04:17 +0200 - rev 360628
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1309650 - remove non remote friendly APIs from selection.js;r=pbro MozReview-Commit-ID: 4EZIn2NWiZ5
f7a6d2efbf88d12a09b615139b6318e2a9789a0e: Bug 1308946 - Part 1 - Ensure that empty views not matching the current panel level are hidden. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 11 Oct 2016 21:00:36 +0200 - rev 360627
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1308946 - Part 1 - Ensure that empty views not matching the current panel level are hidden. r=liuche Setting an empty view's visibility only for the view corresponding to the current PanelLevel was intended to make sure the empty view doesn't get hidden because of an unrelated status update - e.g. to prevent the history empty view hiding itself because the recent tabs count changes. This approach however doesn't work for switching between panel levels (the user moving into and out of the sync/recent tabs folders) - in that case we always need to turn off the empty view of the previous panel level, which is not possible with the above approach. So instead, we revert to always updating the visibility of the empty views, but at the same time initialise the desired state of current PanelLevel's empty view with its current visibility instead of simply defaulting to false. MozReview-Commit-ID: 6Xsnuo29srk
2d84870484441cd38ae1decf651fd709ed32f5b6: Bug 1308946 - Part 0 - Import PanelLevel enum. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 11 Oct 2016 20:41:47 +0200 - rev 360626
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1308946 - Part 0 - Import PanelLevel enum. r=liuche MozReview-Commit-ID: 32Qvym2Neh1
6cb3fe45e73128a9683523c21849716fdbfbf4b5: Backed out changeset 68be44803595 (bug 1305485) for further investigations after failures when this landed
Carsten "Tomcat" Book <cbook@mozilla.com> - Thu, 13 Oct 2016 10:00:00 +0200 - rev 360625
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Backed out changeset 68be44803595 (bug 1305485) for further investigations after failures when this landed
7480f3d08b18ee0d347a944020509c2d57bb5cf0: Bug 1304950 - Reduce timeslice to avoid races with the source ending. r=jwwang
Andreas Pehrson <pehrsons@gmail.com> - Wed, 12 Oct 2016 16:02:56 +0200 - rev 360624
Push 6795 by jlund@mozilla.com at Mon, 23 Jan 2017 14:19:46 +0000
Bug 1304950 - Reduce timeslice to avoid races with the source ending. r=jwwang Media element capture pushes data to MSG ahead of currentTime which together with the direct listeners that we use in MediaRecorder we end up finishing the recording in less than the 250ms that this test uses as the recording timeslice. Lowering the timeslice here seems to fix this. I'm using 1 here since it's the minimum valid number. MozReview-Commit-ID: KAlRoHWHPSV
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip