536a33be81497f58536859a0ffbe9b80f69ac7c1: Bug 1407383 - [wdspec] Remove usage of mozlog to prevent process lock. draft
Henrik Skupin <mail@hskupin.info> - Mon, 05 Mar 2018 22:32:57 +0100 - rev 763587
Push 101479 by bmo:hskupin@gmail.com at Tue, 06 Mar 2018 06:29:05 +0000
Bug 1407383 - [wdspec] Remove usage of mozlog to prevent process lock. Due to misbehavior of the threading module in how threads are forked, the mozlog module and specifically the Lock instance in StructuredLogger can cause a hang of random duration when trying to require the lock. Given that mozlog isn't used anywhere workaround this problem by removing all instances of it. MozReview-Commit-ID: 10yrUIb0XW4
72cbd3ccd9be2f4e65d40fd5bff4899d6e20b062: Bug 1407383 - [wdspec] Remove unused imports from fixtures module. draft
Henrik Skupin <mail@hskupin.info> - Mon, 05 Mar 2018 22:33:48 +0100 - rev 763586
Push 101479 by bmo:hskupin@gmail.com at Tue, 06 Mar 2018 06:29:05 +0000
Bug 1407383 - [wdspec] Remove unused imports from fixtures module. MozReview-Commit-ID: LgAI7fOhyqB
f5a845fcc239fe705e50a0686ba5ab2be6fa0c7f: Bug 1443397 - Modernize several rect and region related functions in Windows widget to use typed types. r?jimm draft
Xidorn Quan <me@upsuper.org> - Tue, 06 Mar 2018 17:20:41 +1100 - rev 763585
Push 101478 by xquan@mozilla.com at Tue, 06 Mar 2018 06:28:57 +0000
Bug 1443397 - Modernize several rect and region related functions in Windows widget to use typed types. r?jimm Mostly just convert nsInt{Rect,Region} to LayoutDeviceInt{Rect,Region}. One exception is to change the parameter of nsWindow::OnResize from nsIntRect to LayoutDeviceIntSize, because it really only needs that. MozReview-Commit-ID: 963Mzd5Wed6
29c2091bea29c3935c6f3cc3108f153256bce01f: Bug 1443397 - Modernize several rect and region related functions in Windows widget to use typed types. r?jimm draft
Xidorn Quan <me@upsuper.org> - Tue, 06 Mar 2018 17:20:41 +1100 - rev 763584
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
Bug 1443397 - Modernize several rect and region related functions in Windows widget to use typed types. r?jimm MozReview-Commit-ID: 963Mzd5Wed6
829eda55dbf2f22830f978b254d5c7d1eeadb3e3: Bug TBD: Apply size constraints on nsXULWindow too. draft
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 01 Mar 2018 17:40:23 +0100 - rev 763583
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
Bug TBD: Apply size constraints on nsXULWindow too. MozReview-Commit-ID: BwL4sEDlVKl
cf453218b166b064987262d418c14709356d6459: fixup! Bug 1439875: Size the XUL window before doing layout. r?smaug draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 28 Feb 2018 19:40:23 +0100 - rev 763582
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
fixup! Bug 1439875: Size the XUL window before doing layout. r?smaug
7a7acc66cf08d6498882ded875fd83f15540d083: Bug 1439875: Update browser_windowopen_reflows.js to not wait for a resize that no longer exists. r?florian draft
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 26 Feb 2018 14:09:20 +0100 - rev 763581
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
Bug 1439875: Update browser_windowopen_reflows.js to not wait for a resize that no longer exists. r?florian MozReview-Commit-ID: Jln9ejZh2b6
95e0a1ae71780ea6841282509b1e632a11195215: Bug 1439875: Fire MozBeforeInitialXULLayout before sizing the window. r?florian,smaug draft
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 22 Feb 2018 16:27:46 +0100 - rev 763580
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
Bug 1439875: Fire MozBeforeInitialXULLayout before sizing the window. r?florian,smaug This gives the chance to code that relies on setting the XUL window attributes to run before we actually size the window. This should prevent the resizing on OSX and fix some other untested stuff that the first commit probably broke... MozReview-Commit-ID: DhCWgmCppek
bea5e07fd8e2ff9f192f5ddc6e65935c0c35dc6a: Bug 1439875: Fix extension windows. r?kmag draft
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 22 Feb 2018 10:39:04 +0100 - rev 763579
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
Bug 1439875: Fix extension windows. r?kmag Now we're loading the sizemode attribute earlier, doing this on load stops working. MozReview-Commit-ID: ToiJiYrvFw
72a33cc3bd8530c9c5f1b8e02c0a8c4218d2735f: Bug 1439875: Size the XUL window before doing layout. r?smaug draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 21 Feb 2018 12:47:05 +0100 - rev 763578
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
Bug 1439875: Size the XUL window before doing layout. r?smaug The only subtle thing is the mCenterAfterLoad stuff, which is gated after a mChromeLoaded. Other than that it follows the same pattern as bug 345560. MozReview-Commit-ID: 8qDiA2yn9DB
ba82c78d0ebf077ba9b08574eefc32da3c1537d3: Bug 1442521 - Make width/height attr on <window> mean the inner size in nsXULWindow. r?smaug draft
Xidorn Quan <me@upsuper.org> - Fri, 02 Mar 2018 22:42:57 +1100 - rev 763577
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
Bug 1442521 - Make width/height attr on <window> mean the inner size in nsXULWindow. r?smaug It seems that the layout system assumes those attributes are for size of the <window> element, i.e. inner window size, not outer window size. See for example nsContainerFrame::SyncWindowProperties. It reads {min,max}{width,height} attributes from the element via nsIFrame::GetXUL{Min,Max}Size, and passes them into SetSizeConstraints. The latter inflates the sizes with window decoration size before calling into widget code. It can also be seen that various XUL size related methods on nsBox and nsIFrame put the same assumption. The test test_windowminmaxsize.xul apparently puts the same assumption as the layout system on the meaning of those properties. (Another test test_resize_move_windows.xul, which tests effectiveness of features of window.open, also fails if we size the window earlier than current in bug 1439875, and doesn't fail with this patch on top. It may indicate that it makes use of the same assumption, but I can't really figure out how it does so.) MozReview-Commit-ID: IdMwDc59Ltg
64a018f7e10f8a11f05ac0a12fe4dc497d19885d: mybase draft
Xidorn Quan <quanxunzhen@gmail.com> - Wed, 04 Feb 2015 08:24:16 +1100 - rev 763576
Push 101477 by xquan@mozilla.com at Tue, 06 Mar 2018 06:21:11 +0000
mybase MozReview-Commit-ID: AIse40brXhE
562ebfb7febc066d1e50b6d74da5370e7d2edecf: Bug 1443088 - Don't use SSE2 flag on non-Intel platform. r?jgilbert draft
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Tue, 06 Mar 2018 14:46:12 +0900 - rev 763575
Push 101476 by bmo:m_kato@ga2.so-net.ne.jp at Tue, 06 Mar 2018 06:14:24 +0000
Bug 1443088 - Don't use SSE2 flag on non-Intel platform. r?jgilbert gcc for arm/aarch64 target doesn't allow -msse2 command line option and it causes option error, not warning. So it should not add this option for non-Intel platform. MozReview-Commit-ID: 9E6SGBMkT94
860643ed99c4fd962cacc7774683a8bfcd501874: Bug 1443368 - Update cubeb-pulse-rs to commit 22cdde3. r?kinetik draft
Dan Glastonbury <dan.glastonbury@gmail.com> - Tue, 06 Mar 2018 15:49:08 +1000 - rev 763574
Push 101475 by bmo:dglastonbury@mozilla.com at Tue, 06 Mar 2018 05:52:04 +0000
Bug 1443368 - Update cubeb-pulse-rs to commit 22cdde3. r?kinetik Pull for change to replace assert in get_server_info callback with proper handling for null pointer. MozReview-Commit-ID: 996HQw3FyYQ
acd01d5135d615274a9f8fe49e7513dbead2b76a: Bug 1259692 - Make TSFTextStore dispatch eKeyDown or eKeyUp event when TIP processes a WM_KEYDOWN or WM_KEYUP message r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 28 Feb 2018 21:53:23 +0900 - rev 763573
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1259692 - Make TSFTextStore dispatch eKeyDown or eKeyUp event when TIP processes a WM_KEYDOWN or WM_KEYUP message r?m_kato TSF doesn't send WM_KEYDOWN nor WM_KEYUP to us while it handles a key message with ITfKeystrokeMgr::KeyDown() or ITfKeystrokeMgr::KeyUp(). Therefore, TSFTextStore needs to store handling key event message during calling those methods and if it does something, we need to dispatch eKeyDown event or eKeyUp event before dispatching any events. However, we shouldn't dispatch WidgetKeyboardEvent during a document lock because TSF/TIP do not assume that document is broken during a document lock. Therefore, TSFTextStore needs to put it as a pending action into the queue. So, this patch wraps this with TSFTextStore::MaybeDispatchKeyboardEventAsProcessedByIME(). It checks if there is a document lock when it's called. If it's locked (and not yet dispatched keyboard event for the handling key message), it adds pending action to dispatch keyboard event later. Otherwise, (and not yet dispatched one), it dispatches keyboard event directly. MozReview-Commit-ID: 9rJTJykVLyf
730d4022dcdb19bffdc58bd4a8d804ac39431e04: Bug 1343451 - part 5: Make GeckoEditableSupport dispatch dummy eKeyDown and eKeyUp event during composition always r?jchen draft
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 27 Feb 2018 17:24:35 +0900 - rev 763572
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 5: Make GeckoEditableSupport dispatch dummy eKeyDown and eKeyUp event during composition always r?jchen On Android, GeckoEditableSupport has already dispatched eKeyDown event and eKeyUp event even during composition. I.e., the pref which will be enabled by bug 354358 has already been set to true only on Android. On the other hand, GeckoEditableSupport does not dispatch them if content listens to "input", "compositionstart", "compositionupdate" or "compositionend". So, different from the other platforms, we cannot test this behind pref ("dom.keyboardevent.dispatch_during_composition") even in Nightly. Therefore, this patch enables new behavior only when it's Nightly build or early Beta. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents to NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process. MozReview-Commit-ID: Fuy0Ir2xiO5
21ce620ed7be56059d0b8ed1a54d2c5395a44ed7: Bug 1343451 - part 4: Make TextInputHandler dispatches eKeyDown event with marking it as "processed by IME" r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 23 Feb 2018 23:09:43 +0900 - rev 763571
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 4: Make TextInputHandler dispatches eKeyDown event with marking it as "processed by IME" r?m_kato First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event before sending IME. This is different behavior from Gecko on the other platforms and it means TextInputHandler does not know if the eKeyDown event will be handled by IME. Therefore, we need to make TextInputHandler dispatch an eKeyDown event dispatch when it needs to dispatch another event. Therefore, this patch makes TextInputHandler not dispatch an eKeyDown even from its HandleKeyDown() unless it's already has composition (because if it's already had composition, any eKeyDown event except modifier keys should be marked as "processed by IME" for compatibility with the other browsers). For dispatching eKeyDown event only once for a native keydown event, this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent() to check whether eKeyDown event has already been dispatched for the event and if it's not so, dispatches eKeyDown event. Note that on macOS, dead keys are implemented as IME. However, we need to treat dead keys as is. Therefore, if current keydown event is a dead keydown event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching eKeyDown event and its following eKeyDown event as "processed by IME". MozReview-Commit-ID: 7epk8wdAznd
6b21afa369f500aa762c24019299ae1122bb45ea: Bug 1343451 - part 3-2: Make IMContextWrapper dispatch eKeyDown event or eKeyUp event if IME handles native key event but we have not dispatched DOM event for it yet r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 22 Feb 2018 20:56:08 +0900 - rev 763570
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 3-2: Make IMContextWrapper dispatch eKeyDown event or eKeyUp event if IME handles native key event but we have not dispatched DOM event for it yet r?m_kato Currently, IMContextWrapper doesn't dispatch eKeyDown event and eKeyUp event if it's handled by IME. However, for conforming to UI Events, it should not eat given keyboard events completely. This patch makes IMContextWrapper dispatches eKeyDown event or eKeyUp event before dispatching first event of composition events or content command event. MozReview-Commit-ID: H2jHpViTH5Q
a260eb0b40164652d44cef2585936034563897da: Bug 1343451 - part 3-1: Make KeymapWrapper::InitKeyEvent() mark given key event as "processed by IME" if it has been handled by IME r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 22 Feb 2018 19:52:53 +0900 - rev 763569
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 3-1: Make KeymapWrapper::InitKeyEvent() mark given key event as "processed by IME" if it has been handled by IME r?m_kato For conforming UI Events spec, KeymapWrapper::InitKeyEvent() should initialize mKeyCode and mKeyNameIndex with NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process if given keyboard event has already been handled by IME. For making it know if given keyboard event has been handled by IME, this patch adds additional bool argument to it and its callers. Note that this patch changes keyCode value and key value of "keydown" event if it's fired before "compositionstart" since Chromium does so on Linux. MozReview-Commit-ID: FC3tfyeeopU
74f75febda63dda554b2151bbc06f9d8a147c617: Bug 1343451 - part 2: KeyboardLayout and NativeKey should use native key code value to check if the key event was handled by IME r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 01 Mar 2017 15:58:50 +0900 - rev 763568
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 2: KeyboardLayout and NativeKey should use native key code value to check if the key event was handled by IME r?m_kato On Windows, VK_PROCESSKEY key message is sent if the key event is handled by IME (in IMM mode or IMM-IME). Therefore, we can set WidgetKeyboardEvent::mKeyCode to NS_VK_PROCESSKEY and WidgetKeyboardEvent::mKeyNameIndex to KEY_NAME_INDEX_Process simply when we receive VK_PROCESSKEY. MozReview-Commit-ID: 9B8Q7rwfXYD
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip