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
PluginInstanceChild::PluginWindowProcInternal() should use switch-case statement at checking each message because adding new message handler may make damage to the performance and switch-case statement is easier to read for Windows message handler.
MozReview-Commit-ID: KfL0LtHL6GV
--HG--
extra : rebase_source : 3d729cf0c34990019dcf52fad72c748f31ea4d71
Use plugin-utils.js's setTestPluginEnabledState to fix race.
MozReview-Commit-ID: 6eVTDJzdKR0
--HG--
extra : rebase_source : cd9d5d0a186b6b29c9d734cd941137ce15600244
js::Class op are often all null. And when they're not all null, they're often
duplicated among classes. By pulling them out into their own struct, and using a
(possibly null) pointer in js::Class, we can save 114 KiB per process on
64-bit, and half that on 32-bit.
* * *
imported patch separate-ClassOps-2
--HG--
extra : rebase_source : bd751bf247e9491c1966a123dbeffa573657dfb1
js::ClassExtension is often all null. When it's not all null, it's often
duplicated among classes. By pulling it out into its own struct, and using a
(possibly null) pointer in js::Class, we can save 17 KiB per process on
64-bit, and half that on 32-bit.
--HG--
extra : rebase_source : eb78ade09ce268e886d091f6cbc38d7e5e912527
Previously, every test and support file would be synced to the objdir
when running any test. Now that only those support files and tests requested
are synced, we note support files required beyond those in a test's
directory in ini manifests.
MozReview-Commit-ID: EmlDz9d4lqt
js::ObjectOps is often all null. When it's not all null, it's often duplicated
many times among classes. By pulling it out into its own struct, and using a
(possibly null) pointer in js::Class, we can save 208 KiB per process on
64-bit, and half that on 32-bit.
--HG--
extra : rebase_source : 5be8fe45f652392571b8a6d7b63777cbafba6ae4
This was in a previously reviewed patch. I dropped the change because I
thought the underlying warning had been fixed. I was wrong.
MozReview-Commit-ID: J9B34YhJ3z0
--HG--
extra : source : ea446df75d17331a7c0736ef3303bf9a07d8d9f0
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists on fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: BgLmpUa09c6
--HG--
extra : rebase_source : bee12f3e67aca3bfd320ee729ea6213dc48576b8
I also add some missing data to the content version, namely the duration of time that ContentParent::SendLoadPlugin takes.
MozReview-Commit-ID: 8qSZopvY1D7
--HG--
extra : rebase_source : ca717c149a52ed1ece9ac0678dca0c284ab26c5d
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: Gcq3Qna02iB
--HG--
extra : rebase_source : 2ccaa22eb85280cc8d322df87fb759e8dff67cf1
The main change is that we move AutoJSExceptionReporter up to before the first
place where we might throw an exception, so we report those exceptions before
returning. The change to use AutoEntryScript consistently is because all of
these callsites can run JS in practice, and it seems reasonable to allow them
to.
mContentParent is really just to be used while handling a synchronous
ContentParent::RecvLoadPlugin call when async plugin init turned on.
In any other context, using it will be unsafe.
This patch adds comments and assertions to ensure that this value isn't set
otherwise, and converts the one use of mContentParent outside of async plugin
init to use an alternative mechanism for identifying the content process.
MozReview-Commit-ID: Esgt1kj0MCt
--HG--
extra : rebase_source : 166b913b401582c6948e4b61efc102dc1b9c8d2f
dom/plugins/test/testplugin/nptest_macosx.mm:278:10: warning: will never be executed [-Wunreachable-code]
dom/plugins/test/testplugin/nptest_macosx.mm:307:10: warning: will never be executed [-Wunreachable-code]
dom/plugins/test/testplugin/nptest.cpp:697:7: warning: will never be executed [-Wunreachable-code]
dom/plugins/test/testplugin/nptest.cpp:2300:15: warning: will never be executed [-Wunreachable-code]
Modify the Mac sandbox to allow temporary files to be created in a
parent-specified subdirectory of NS_OS_TEMP_DIR. This is similar to the
Windows approach. The parent provides a UUID in a preference which is
used by the content process to form the subdirectory name.
MozReview-Commit-ID: 6BONpfZz8ZI
--HG--
extra : rebase_source : ad18e091918356a1a40c13f1453972b4512ad476
When turned on e10s, plugin process creates from chrome process. So content
process doesn't know current sandbox level. To rewrite wmode attribute on
contnet process by sandbox level >= 2, we should store sandbox level to
nsPluginTag.
MozReview-Commit-ID: DCQ5g7uCbJF
--HG--
extra : rebase_source : 7064f469e873ea1301e28faeab0bbb27613978db
Be warned. Do not attemp to change the .js "test" source code in ./js
They are meant to check
- the outdated 0666 octal constant is still parsed correctly,
- the outdated 0666 octal constant raises syntax error flag
in strict mode, etc.
So leave them alone.
They were disabled in bug 657569 because of a miscompilation from MSVC,
but back then, we were using one of 2005, 2008 or 2010 (not entirely
sure which). Even if it was the latter, there has been two releases of
MSVC since, if stopping at the one we're currently using.
