86919fbab7882bacdf7d680b89b6a4658c1b6ca1: Bug 1445153 - Remove remaining references to computedview in boxmodel component;r=pbro
Julian Descottes <jdescottes@mozilla.com> - Tue, 13 Mar 2018 08:51:34 +0100 - rev 464194
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1445153 - Remove remaining references to computedview in boxmodel component;r=pbro MozReview-Commit-ID: CxX09ZQ9jhk
ae1924aff61b6f4ef104723cd3a7df3f043bd4da: Bug 1443457 - Stop referencing the addon-sdk loader in devtools code r=jdescottes
Michael Ratcliffe <mratcliffe@mozilla.com> - Fri, 09 Mar 2018 15:36:45 +0000 - rev 464193
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1443457 - Stop referencing the addon-sdk loader in devtools code r=jdescottes MozReview-Commit-ID: 7lwCG8JT7cV
4f104b611240657502e6953e7725e9a39742da76: Merge mozilla-central to autoland
arthur.iakab <aiakab@mozilla.com> - Wed, 14 Mar 2018 12:16:00 +0200 - rev 464192
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Merge mozilla-central to autoland
e226de7caa882aedbdadf588adb2632991e63f9c: Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 12 Mar 2018 15:41:39 +0900 - rev 464191
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato uim is an old IM which uses key snooper to listen to key events rather than via filter key event API which should be called by applications. It's still used by Debian 9.x, so, we still need to support this. Unfortunately, we cannot detect if uim actually uses key snooper because it's switch by build option of uim. Currently, Debian builds uim as using key snooper. So, we should assume uim uses key snooper always. On the other hand, somebody *might* use uim built as not using key snooper, so, let's decide if uim uses key snooper with new pref, "intl.ime.hack.uim.using_key_snooper", but its default should be true. Note that ibus and Fcitx also have the mode to use key snooper (perhaps for backward compatibility with uim). However, it's not enabled in default settings and even if it's enabled, Firefox is in whitelist in the default settings of them for stop using key snooper. Therefore, we don't need to support key snooper mode for them unless we'll get some requests to support their key snooping mode. MozReview-Commit-ID: 6fTsfKrHzvo
e5cca677e835e18e0eb74499d5c0448497aa779c: Backed out changeset 2c8540f7800f (bug 1443457) for ESlint failure at /builds/worker/checkouts/gecko/devtools/server/tests/mochitest/test_getProcess.html
Coroiu Cristina <ccoroiu@mozilla.com> - Wed, 14 Mar 2018 11:41:12 +0200 - rev 464190
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Backed out changeset 2c8540f7800f (bug 1443457) for ESlint failure at /builds/worker/checkouts/gecko/devtools/server/tests/mochitest/test_getProcess.html
b1117fa567eb9067f2816a813046a129406f20cf: Backed out 2 changesets (bug 1443080) for spidermonkey build bustage at build/src/js/src/jit/BaselineCacheIRCompiler.cpp
Coroiu Cristina <ccoroiu@mozilla.com> - Wed, 14 Mar 2018 11:13:21 +0200 - rev 464189
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Backed out 2 changesets (bug 1443080) for spidermonkey build bustage at build/src/js/src/jit/BaselineCacheIRCompiler.cpp Backed out changeset 7d509bb8a35d (bug 1443080) Backed out changeset 53bdcd5937cd (bug 1443080)
2c8540f7800fcaae3599e6c64154ba9e5ac95f17: Bug 1443457 - Stop referencing the addon-sdk loader in devtools code r=jdescottes
Michael Ratcliffe <mratcliffe@mozilla.com> - Fri, 09 Mar 2018 15:36:45 +0000 - rev 464188
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1443457 - Stop referencing the addon-sdk loader in devtools code r=jdescottes MozReview-Commit-ID: 7lwCG8JT7cV
6afa399e604a399e09742f16211ae69f22b3ab75: Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 09 Mar 2018 12:39:40 +0900 - rev 464187
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato ibus and fcitx usually post key event to other IME process, then, if it causes some signals to updating composition string, they may not send the posted key event to us again. Then, IMContextWrapper dispatches neither eKeyDown nor eKeyUp event since mProcessingKeyEvent becomes non-nullptr only while OnKeyEvent() is called. So, IMContextWrapper need to store key event if OnKeyEvent() assumes that given key event is posted to different process. Then, if IMContextWrapper receives some signals, it should dispatch eKeyDown and eKeyUp event with stored key event. Note that we cannot compare the pointer of first event and following event directly even though usually both events are same address as far as I checked because according to the source code of ibus, fcitx and GDK, they use gdk_event_copy() to keep storing original event. According to the document of the API, it might just increment refcount. However, the actual implementation of the API always creates another instance and return it. So, it might be used same address by arena allocation or something accidentally. Anyway, we shouldn't compare them. Instead, we need to compare each information of two key events. Unfortunately, we also cannot compare them simply. Both ibus and fcitx set unused bits of GdkEventKey::state to true when they send back the event to us. Therefore, we should compare some of or all of the members by ourselves. I think that matching time must be enough in most cases since its value of native key events are properly set. However, for safer code, this patch also checks type, keyval and part of state. MozReview-Commit-ID: FZSwN61v0Sd
edc1455e7082f769a2c358a0b15c8950629dc4f3: Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 09 Mar 2018 00:46:52 +0900 - rev 464186
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato ibus and fcitx have asynchronous key event handling mode and it's enabled in default settings. That is, when they receive a key event from application via a call of gtk_im_context_filter_keypress(), they may post the key event information to other IME process, then does nothing but store the copy of the event with gdk_event_copy() and returns true for the result of gtk_im_context_filter_keypress(). When the other IME process handles the event, returns the result to them in our process. Then, they send the stored key event to us again. Finally, they actually handles the event in our process actually. Therefore, we may receive every key event twice. So, this causes dispatching eKeyDown event and eKeyUp event twice. Preceding key event is always marked as "processed by IME" since gtk_im_context_filter_keypress() returns true temporarily and following key event is dispatched as expected. So, we need to ignore the first event only when gtk_im_context_filter_keypress() returns true but the event is posted to different process. Unfortunately, we cannot know if the key event is actually posted to different process directly. However, we can know if active IM is ibus, fcitx or another one and if ibus or fcitx is in asynchronous key handling mode. The former information is provided by gtk_im_multicontext_get_context_id(). It returns a string which is set to the IM multicontext instance by creator. We'll get "ibus" if IM is ibus, get "fcitx" if IM is fcitx. The latter information is not provided. However, they consider the mode from env value. ibus checks IBUS_ENABLE_SYNC_MODE. fcitx checks both IBUS_ENABLE_SYNC_MODE and FCITX_ENABLE_SYNC_MODE. Additionally, we can know if received key event has already been posted to other IME process. They use undefined bit of GdkEventKey::state to store if the key event has already been posted (1 << 25, they called "ignored" flag). Although their approach is really hacky but we can refer the information at least for now. Finally, when we guess a key event is posted to other IME process, let's IMContextWrapper::OnKeyEvent() not dispatch eKeyDown nor eKeyUp event. Note that if it's handled synchronously as unexpected, it may causes dispatching one or more composition events and/or delete content event. So, in such case, we dispatch a keyboard event for processing key event anyway. There is only once case we'll fail to dispatch keyboard event. If we receive signals to dispatch composition events or delete content command event when IM receives the result from other IME process but it doesn't send the key event to us. This will be fixed by the following patch. MozReview-Commit-ID: 94PrlnmQ3uJ
552d61cb273abe05e86c9d64a7a0077ed1046856: Bug 1437438 - Add a performance counter to track scheduler activity - r=farre,froydnj
Tarek Ziadé <tarek@mozilla.com> - Tue, 06 Mar 2018 10:19:19 +0100 - rev 464185
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1437438 - Add a performance counter to track scheduler activity - r=farre,froydnj Adds a PeformanceCounter class that is used in DocGroup and WorkerPrivate to track runnables execution and dispatch counts. MozReview-Commit-ID: 51DLj6ORD2O
7d509bb8a35d278c15597bff0a0e7855479987e3: Bug 1443080 - Now that we use static call, some var instances are not needed anymore r=Ehsan
Sylvestre Ledru <sledru@mozilla.com> - Mon, 05 Mar 2018 09:33:02 +0100 - rev 464184
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1443080 - Now that we use static call, some var instances are not needed anymore r=Ehsan MozReview-Commit-ID: AiuJIY8Gssl
53bdcd5937cdb1ccf4388ee7a0f3fee0c3675c52: Bug 1443080 - Use the static call for static methods (not instance) r=Ehsan
Sylvestre Ledru <sledru@mozilla.com> - Mon, 05 Mar 2018 13:43:54 +0100 - rev 464183
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1443080 - Use the static call for static methods (not instance) r=Ehsan MozReview-Commit-ID: JwHh4bzxuTR
3606a48f01835004c941f85fbdc5bdb88038049c: Bug 1419226 - Part 2. Wait for MozAfterPaint instead of waiting for frames on file_deferred_start.html . r=hiro
Mantaroh Yoshinaga <mantaroh@gmail.com> - Wed, 14 Mar 2018 13:27:16 +0900 - rev 464182
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1419226 - Part 2. Wait for MozAfterPaint instead of waiting for frames on file_deferred_start.html . r=hiro This patch will : * Create test div element after waiting for document load, then wait for painting after it. * Change to waiting for MozAfterPaint event without workaround of waiting for excessive frames. MozReview-Commit-ID: 6Ytxln3tJi4
6b81e68d487bfac07262573dc3bbc1ba6410ef5f: Bug 1419226 - Part 1.Change observing target window of MozAfterPaint. r=mconley
Mantaroh Yoshinaga <mantaroh@gmail.com> - Wed, 14 Mar 2018 10:14:50 +0900 - rev 464181
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1419226 - Part 1.Change observing target window of MozAfterPaint. r=mconley Previous code, print preview waits for content window's MozAfterPaint. However gecko prevents send MozAfterPaint to content window[1]. So this code will not work correctly. However, software timer of firing MozAfterPaint ran this code.[2] This patch will * Change the observing content window to chrome window. * Add timer of MozAfterPaint event in order to ensure this event even if display list invalidation doesn't invalidate. Gecko create this timer in nsPresContext previously[2], but this bug will remove it [1] https://searchfox.org/mozilla-central/rev/919dce54f43356c22d6ff6b81c07ef412b1bf933/layout/base/nsPresContext.cpp#2452 [2] https://searchfox.org/mozilla-central/rev/919dce54f43356c22d6ff6b81c07ef412b1bf933/layout/base/nsPresContext.cpp#3466-3472 MozReview-Commit-ID: GcuKPjn0qhc
e0181f1b31ad422a8d347df8eb422248df97d050: Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 05 Mar 2018 22:03:58 +0900 - rev 464180
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato On Linux, dead key is implemented with "table-based input methods" which are available even on GtkIMContextSimple (i.e., available even in password fields). Therefore, IMContextWrapper handles dead key sequence as usual composition of IME. However, on the other platforms, we dispatch "Dead" eKeyDown and eKeyUp events for dead key. We started to mark keyboard events which are handled by IME as "processed by IME" since bug 1343451, i.e., we started to set mKeyNameIndex to KEY_NAME_INDEX_Process. However, we should keep previous behavior, i.e., keep setting it to KEY_NAME_INDEX_Dead. Fortunately, GDK's key event tells us whether the keyboard event is a dead key event with keysym. So, we can detect if we're in a dead key sequence simply. MozReview-Commit-ID: Dv336WptfXN
80b4777a6421d8df4bb27ac23fb607c318a3006c: Merge inbound to mozilla-central. a=merge
arthur.iakab <aiakab@mozilla.com> - Wed, 14 Mar 2018 12:00:13 +0200 - rev 464179
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Merge inbound to mozilla-central. a=merge
d4c2951dae436864ed6e7115e8805f7d45985630: Backed out changeset 2afa73fb650a (bug 1436549) for devtools failures on /boxmodel/test/browser_boxmodel_guides.js
Gurzau Raul <rgurzau@mozilla.com> - Wed, 14 Mar 2018 07:46:03 +0200 - rev 464178
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Backed out changeset 2afa73fb650a (bug 1436549) for devtools failures on /boxmodel/test/browser_boxmodel_guides.js
c407e9656999eec919da180ba4ddd0b4e456971c: Bug 1442804 - heap write analysis: nsTArray owns its header, r=bholley
Steve Fink <sfink@mozilla.com> - Tue, 06 Mar 2018 08:46:28 -0800 - rev 464177
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1442804 - heap write analysis: nsTArray owns its header, r=bholley
228f3feb90616a96a70b3cd90217c37325e996b7: Bug 1442804 - heap write analysis: whitelist GetAutoArrayBuffer, which returns a pointer into |this|, r=bholley
Steve Fink <sfink@mozilla.com> - Tue, 06 Mar 2018 08:45:56 -0800 - rev 464176
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1442804 - heap write analysis: whitelist GetAutoArrayBuffer, which returns a pointer into |this|, r=bholley
277393616f91d3a05a264b318c3ffb3780c6d5e5: Bug 1442804 - heap write analysis: explicitly whitelist stringbuffer canary field, r=bholley
Steve Fink <sfink@mozilla.com> - Tue, 06 Mar 2018 08:44:42 -0800 - rev 464175
Push 1728 by jlund@mozilla.com at Mon, 18 Jun 2018 21:12:27 +0000
Bug 1442804 - heap write analysis: explicitly whitelist stringbuffer canary field, r=bholley
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip