Commit Graph

6 Commits

Author SHA1 Message Date
Farmer Tseng
d754d0f933 Bug 1352368 - Remove some old Windows defines from WinMessages.h r=jwatt
These defines cause include ordering issues that can result in build errors if
WinMessages.h is included before certain Windows headers.

To solve this issue this commit simply removes those defines since nowadays we
require Visua Studio 2015 to build and no longer need them.

MozReview-Commit-ID: GHMU05GUwHM

--HG--
extra : rebase_source : fcaadb93be6ff43f36ba98f164018d93c98a4e22
2017-04-01 00:44:26 +08:00
Jim Mathies
3c4ae3ad20 Bug 1342245 - Add support for accessibility.force_disabled=-1 (force enabled) on Windows. r=aklotz
MozReview-Commit-ID: 7cl6AI5ZFs9

--HG--
extra : rebase_source : e91751f0871a344c8d034e6852c311ac259efd01
2017-02-24 08:58:40 -06:00
Masatoshi Kimura
a35278e9a7 Bug 1325368 - Assume Win7 or later when testing Windows version. r=jimm
MozReview-Commit-ID: 718G0htR17H

--HG--
extra : rebase_source : e6f7a3584f03c802218a1de526345e1df1e67cf8
2017-01-29 16:42:46 +09:00
Masayuki Nakano
0b9b9bf032 Bug 1257759 part.9 Implement nsWindow::OnKeyEventInPluginProcess() on Windows r=jimm
Implementing nsWindow::OnWindowedPluginKeyEvent() on Windows.  This patch makes NativeKey class dispatches eKeyDownOnPlugin and eKeyUpOnPlugin when the method is called.

MozReview-Commit-ID: L8yRZvDaQKR

--HG--
extra : rebase_source : 387ce72dcea23a92bd8c774fc54a8bff8da6c844
2016-04-15 17:02:36 +09:00
Masayuki Nakano
b332dc9ff4 Bug 1257759 part.5 PluginInstanceChild should post received native key event to chrome process if the key combination may be a shortcut key r=jimm
When PluginInstanceChild receives native key events, it should post the events to the chrome process first for checking if the key combination is reserved.  However, posting all key events to the chrome process may make damage to the performance of text input.  Therefore, this patch starts to post a key event whose key combination may be a shortcut key.  However, for avoiding to shuffle the event order, it posts following key events until all posted key events are handled by the chrome process.

For receiving response from widget, this patch defines nsIKeyEventInPluginCallback.  It's specified by nsIWidget::OnWindowedPluginKeyEvent() for ensuring the caller will receive the reply.  Basically, the caller of nsIWidget::OnWindowedPluginKeyEvent() should reply to the child process.  However, if the widget is a PuppetWidget, it cannot return the result synchronously.  Therefore, PuppetWidget::OnWindowedPluginKeyEvent() returns NS_SUCCESS_EVENT_HANDLED_ASYNCHRONOUSLY and stores the callback to mKeyEventInPluginCallbacks.  Then, TabParent::HandledWindowedPluginKeyEvent() will call PuppetWidget::HandledWindowedPluginKeyEvent().

MozReview-Commit-ID: G6brOU26NwQ

--HG--
extra : rebase_source : 8140456de278956d2d594e85c7b397ae366b4962
2016-04-19 20:09:37 +09:00
Masayuki Nakano
f19611cb89 Bug 1257759 part.2 Separate Windows' message and related definitions from nsWindowDefs.h to mozilla/widget/WinMessages.h r=jimm
This patch separates Windows' message definition and related definitions from nsWindowDefs.h to mozilla/widget/WinMessages.h because the definitions are useful in plugin module but nsWindowDefs.h cannot be included from plugin module since it depends on some headers in under widget.

MozReview-Commit-ID: KNUAffLMKT1

--HG--
rename : widget/windows/nsWindowDefs.h => widget/windows/WinMessages.h
extra : rebase_source : ae9390e700ca97a0a4eea3b2977d4d5568ce9408
2016-04-09 15:15:31 +09:00