The class name clashes with mozilla::net::OfflineObserver and ends up crashing in nsTraceRefcnt::GetBloatEntry because the two classes have a different size.
The original changeset that is being backed out had comment:
Bug 1023941 - Part 3: Static-link the CRT into plugin-hang-ui.exe.
MozReview-Commit-ID: G0DmyyKqGWg
--HG--
extra : rebase_source : a7e5f38a7bb70d595c3fdbb26bc5e7f86b4c5926
And mCharCode shouldn't be compared with NS_VK_*, nsIDOMKeyEvent::DOM_VK_*. Additionally, when it's compared with a character constant, cast isn't necessary.
MozReview-Commit-ID: JMT614copjG
--HG--
extra : rebase_source : 69ee3c589e5a71c814ec9a40ac3aab39c789c11d
And also WidgetKeyboardEvent::mKeyCode should be compared with NS_VK_* rather than nsIDOMKeyEvent::DOM_VK_*.
MozReview-Commit-ID: IKjQ1nr8XYe
--HG--
extra : rebase_source : 83125cd2523f6b70759f621470aad23b00aae8ae
This function is roughly copied from browser/base/content/test/general/head.js.
It has been widely used in browser chrome mochitests, and should be fine to
have it available to all mochitests via SimpleTest.
MozReview-Commit-ID: DhIfgJiUhXK
--HG--
extra : rebase_source : 95ab1cd6c1ab5f6c0d8f0171865722ca76b41c6e
It looks like VC++ doesn't like comparisons of nsCOMPtr to 0 after this
change, but those are bad style anyway, so I removed them from
TestCOMPtr.cpp instead of trying to make them work.
nsWindow for Windows cannot decide if a preceding WM_*KEYDOWN or WM_*KEYUP which is a preceding message of WM_*CHAR is consumed because nsWindow cannot know if WM_*CHAR message came from same window which received the preceding WM_*KEYDOWN or WM_*KEYUP. Therefore, PluginInstanceChild should do that.
MozReview-Commit-ID: 1uuZ0nTJ5Xb
--HG--
extra : rebase_source : b99f8057d5e93035a769af2506292ff7d2cb8f4a
On Windows, applications cannot handle IME messages asynchronously. Therefore, we cannot put off to send IME messages to plugin even if there are some pending keyboard events which were posted to the parent process.
This patch makes PluginInstanceChild consume all key events which are returned from the parent process during IME composition. And when an IME composition is committed, mark pending key events as outdated.
MozReview-Commit-ID: 7P3LEJ6pDir
--HG--
extra : rebase_source : 42e304c45cd980f339b29526ab65854d196198ad
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
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
