1.PDfium would be built into the xul (bug 1368948) so PDFiumEngineShim could
call functions directly. However, I still keep loading dynamic library for
debugging purpose. Create a new preference for storing the library file path.
2.Remove redundant define and typedef which are written in PDFium head file.
3.Include an appropriate head file from PDFium.
4.Remove non-used PDFium APIs.
5.Use the singleton pattern to retrieve the instance of PDFiumEngineShim.
6.Don't destroy the library inside PDFiumEngineShim::CloseDocument because the
library has to deal with multi-document.
MozReview-Commit-ID: 97ZBFp1qU8V
--HG--
extra : rebase_source : a60ee37906a94788e0baabbb95bd8848eca096af
This class helps draw a PDF file to a given Windows DC.
MozReview-Commit-ID: IjZAIcN3bND
--HG--
extra : rebase_source : 035dfbf5380316aacae8e1e1591d81971c47b843
This class exposes an interface to PDFium library and takes care of loading and
linking to the appropriate PDFium symbols.
MozReview-Commit-ID: 32jZD6d0KFw
--HG--
extra : rebase_source : 1d0580cbc8dc8687656ce32654d679da54104a33
WindowsEMF could be initialized with the path of a file where the EMF data
should be stored. If pass null point to the constructor that means the EMF data
are store in memory. Consumers can call GetDC() to get a HDC. It can be drawn to
generate the EMF output. After finishing with the HDC, call FinishDocument() to
finish writing the EMF output. Then consumers can call Playback() to play the
EMF's drawing commands onto the given DC. Once consumers don't use WindowsEMF
anymore, call ReleaseEMFHandle() to release object's handle. If the EMF output
is in memory, it is deleted. If it is on disk, it is not.
Consumers also can initialize WindowsEMF with an existing EMF file. They can
only use Playback().
MozReview-Commit-ID: 8hUsx8b2CXz
--HG--
extra : rebase_source : 99e38e61a00bfae45ec9102b3b23a095a7f3af1e
ScreenHelperWin is the platform dependent part of the original
nsScreenManagerWin and nsScreenWin. It listens the WM_DISPLAYCHANGE
message and pushes updates to ScreenManager. See patch part 4. for how
ScreenManager works.
MozReview-Commit-ID: 20A3ZQKmH9a
--HG--
rename : widget/windows/nsScreenManagerWin.cpp => widget/windows/ScreenHelperWin.cpp
rename : widget/windows/nsScreenManagerWin.h => widget/windows/ScreenHelperWin.h
extra : rebase_source : a3058c237d38f72103251802ab5f5bbd672e9b70
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
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
Before posting native key message from PluginInstanceChild, we need to check if the key combination could be a shortcut key, i.e., we need to check if Ctrl or Alt key is pressed. ModifierKeyState is a good class for checking it but it should be defined in an independent header file.
This patch separates the definition of ModifierKeyState to mozilla/widget/WinModifierKeyState.h and implement MaybeMatchShortcutKey() for PluginInstanceChild.
MozReview-Commit-ID: ZjLnJx02Ou
--HG--
rename : widget/windows/KeyboardLayout.h => widget/windows/WinModifierKeyState.h
extra : rebase_source : 66e9351a36dfa88f080ea78972ac0cb347bb174d
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
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973