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 767691
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767690
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767689
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767688
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767687
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767686
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767685
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767684
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767683
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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 767682
Push 102668 by bmo:mratcliffe@mozilla.com at Wed, 14 Mar 2018 22:49:54 +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
8a711859f84977edec64f3fc3b9aca21577a80fc: Bug 1445537: Track frameloader swaps when monitoring for channel disconnections. r?aswan draft
Kris Maglione <maglione.k@gmail.com> - Wed, 14 Mar 2018 15:44:08 -0700 - rev 767681
Push 102667 by maglione.k@gmail.com at Wed, 14 Mar 2018 22:44:37 +0000
Bug 1445537: Track frameloader swaps when monitoring for channel disconnections. r?aswan When we swap <browser> frameloaders, the message managers on the parent side also change. And since a frameloader swap is usually followed by the original <browser> and its message manager being destroyed, this leads us to think the message manager has disconneced earlier than it actually does. MozReview-Commit-ID: LC9aaoynWzH
e568b670d12a6838989d8ac0556a697800fd7d54: Bug 1443771 - Add ESR name to the about dialog. It is not translated. r?felipe draft
Michael Kaply <mozilla@kaply.com> - Wed, 14 Mar 2018 17:41:26 -0500 - rev 767680
Push 102666 by mozilla@kaply.com at Wed, 14 Mar 2018 22:41:44 +0000
Bug 1443771 - Add ESR name to the about dialog. It is not translated. r?felipe MozReview-Commit-ID: FYjA7IrTGYt
4f6ce54bf69989a5916775c606c4bfa4343879ac: Bug 1406206 - Remove extraneous else block from cycle collection macros; r=ehsan draft
Kyle Machulis <kyle@nonpolynomial.com> - Wed, 14 Mar 2018 15:36:59 -0700 - rev 767679
Push 102665 by bmo:kyle@nonpolynomial.com at Wed, 14 Mar 2018 22:39:13 +0000
Bug 1406206 - Remove extraneous else block from cycle collection macros; r=ehsan clang-tidy is complaining about an extra else in NS_INTERFACE_MAP_ENTRIES_CYCLE_COLLECTION. Not hurting anything, but could be cleaned up anyways. MozReview-Commit-ID: 36Lkdhs3fyN
6bb134f5e0908240166887fd19522e2b0e4f1a50: Turn on OOP for all iframes just to see what happens. draft
Kyle Machulis <kyle@nonpolynomial.com> - Wed, 07 Mar 2018 16:59:11 -0800 - rev 767678
Push 102664 by bmo:kyle@nonpolynomial.com at Wed, 14 Mar 2018 22:38:51 +0000
Turn on OOP for all iframes just to see what happens. MozReview-Commit-ID: 8q26klnFMr1
89d728ff60e2ba7f7b20b0c3399c1c2831ffe681: Bug 1429896 - Turn on OOP IFrame Prefs draft
Kyle Machulis <kyle@nonpolynomial.com> - Fri, 23 Feb 2018 15:29:15 -0800 - rev 767677
Push 102664 by bmo:kyle@nonpolynomial.com at Wed, 14 Mar 2018 22:38:51 +0000
Bug 1429896 - Turn on OOP IFrame Prefs MozReview-Commit-ID: HzKTM3vqBJ2
cbfab1e2da5bb6fb68366c0c3e0c7512b161d19e: Bug 1429896 - Turn on OOP iframes draft
Kyle Machulis <kyle@nonpolynomial.com> - Fri, 23 Feb 2018 13:17:10 -0800 - rev 767676
Push 102664 by bmo:kyle@nonpolynomial.com at Wed, 14 Mar 2018 22:38:51 +0000
Bug 1429896 - Turn on OOP iframes MozReview-Commit-ID: EfC0TRRJzcs
e6f6db66e48169a5fdfbe5957ee3c748ae290959: Bug 1269468 - onRequestPostData returns requestPostData not whole payload draft
Tom Glowka <glowka.tom@gmail.com> - Wed, 14 Mar 2018 23:25:12 +0100 - rev 767675
Push 102663 by bmo:glowka.tom@gmail.com at Wed, 14 Mar 2018 22:36:53 +0000
Bug 1269468 - onRequestPostData returns requestPostData not whole payload For the sake of coherence with the rest of FirefoxDataProvider interface, to avoid future bugs like the one this commit refers to. MozReview-Commit-ID: EX8JQvoIeTb
aff23305600e1ae2e37ce680f12bc730bc68d0a5: Bug 1269468 - fix netmonitor Copy as cURL: adjusting requestData calls to current implementation of onRequestPostData draft
glowka <glowka.tom@gmail.com> - Fri, 09 Mar 2018 00:14:23 +0100 - rev 767674
Push 102663 by bmo:glowka.tom@gmail.com at Wed, 14 Mar 2018 22:36:53 +0000
Bug 1269468 - fix netmonitor Copy as cURL: adjusting requestData calls to current implementation of onRequestPostData MozReview-Commit-ID: AOYbsV4AljW
45641306d94e2052850e719d858a4635964537c1: Bug 1418077 - Remove nsIDOMHTMLFormElement. r?bz draft
Adrian Wielgosik <adrian.wielgosik@gmail.com> - Wed, 14 Mar 2018 21:42:25 +0100 - rev 767673
Push 102662 by bmo:adrian.wielgosik@gmail.com at Wed, 14 Mar 2018 22:34:16 +0000
Bug 1418077 - Remove nsIDOMHTMLFormElement. r?bz MozReview-Commit-ID: 9eQxvfIMB22
6c820384a44835405890c6c1227420f1cfc60e54: Bug 1445776 - Add development restart shortcut to Browser Console. r=bgrins draft
J. Ryan Stinnett <jryans@gmail.com> - Wed, 14 Mar 2018 17:02:07 -0500 - rev 767672
Push 102661 by bmo:jryans@gmail.com at Wed, 14 Mar 2018 22:31:38 +0000
Bug 1445776 - Add development restart shortcut to Browser Console. r=bgrins Adds the browser restart shortcut (Cmd / Ctrl + Alt + R) to the Browser Console window. Only enabled for local development builds. MozReview-Commit-ID: 2oTT55TYCx6
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip