This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
MacQuirks was targeted for OSX from 10.6.8 up to but not including 10.7.0. We
have now removed support for 10.6 so we can safely remove this code. This also
fixes bug 1282184 where DMD is apparently choking on memory allocated in the
interpose library.
MacQuirks was targeted for OSX from 10.6.8 up to but not including 10.7.0. We
have now removed support for 10.6 so we can safely remove this code. This also
fixes bug 1282184 where DMD is apparently choking on memory allocated in the
interpose library.
Because bug 1282866 removed Qt support but missed a bunch of things.
* * *
Bug 1285554 - more
--HG--
extra : rebase_source : c48d2485f1fdf1c961e08d91651bbca41e3a1a53
In all of the places touched by this patch, the smart pointer we're
appending is about to become unused, so simply .forget()'ing its
reference into the appropriate nsCOMArray works just fine.
For making our code clearer by the stronger type check, we should change the anonymous enum for NS_TEXTRANGE_* to enum class whose name is "TextRangeType" and whose type is "RawTextRangeType" which is an alias of uint8_t.
Additionally, this also adds some utility methods for them.
Note that some lines which are changed by this patch become over 80 characters but it will be fixed by the following patches.
MozReview-Commit-ID: 76izA1WqTkp
--HG--
extra : rebase_source : 27cd8cc8f7f8e82055dbfe82aba94c02beda5fa4
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
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
