2016-07-14 16:16:42 +00:00
|
|
|
# -*- Mode: python; indent-tabs-mode: nil; tab-width: 40 -*-
|
2013-02-25 21:20:02 +00:00
|
|
|
# vim: set filetype=python:
|
|
|
|
# This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
# License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
2017-04-14 09:54:36 +00:00
|
|
|
with Files("**"):
|
|
|
|
BUG_COMPONENT = ("Core", "Widget: Win32")
|
|
|
|
|
2017-05-30 02:29:22 +00:00
|
|
|
with Files("*CompositorWidget*"):
|
|
|
|
BUG_COMPONENT = ("Core", "Graphics")
|
|
|
|
|
2013-02-25 21:20:02 +00:00
|
|
|
TEST_DIRS += ['tests']
|
2013-03-19 18:47:00 +00:00
|
|
|
|
2013-04-16 19:24:43 +00:00
|
|
|
EXPORTS += [
|
|
|
|
'nsdefs.h',
|
2013-10-23 23:05:43 +00:00
|
|
|
'WindowHook.h',
|
|
|
|
'WinUtils.h',
|
2013-04-16 19:24:43 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
EXPORTS.mozilla.widget += [
|
|
|
|
'AudioSession.h',
|
2016-07-01 08:15:16 +00:00
|
|
|
'CompositorWidgetChild.h',
|
|
|
|
'CompositorWidgetParent.h',
|
2016-07-19 18:56:07 +00:00
|
|
|
'InProcessWinCompositorWidget.h',
|
Bug 1399787 - Part 3. Create a top level protocol for the PDFium process. r=jwatt
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : b6459a187de8e066e7574d2b8757d09fbcfcddba
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
2017-10-13 08:58:07 +00:00
|
|
|
'PDFiumChild.h',
|
2017-01-10 09:43:16 +00:00
|
|
|
'PDFiumEngineShim.h',
|
Bug 1399787 - Part 3. Create a top level protocol for the PDFium process. r=jwatt
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : b6459a187de8e066e7574d2b8757d09fbcfcddba
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
2017-10-13 08:58:07 +00:00
|
|
|
'PDFiumParent.h',
|
2017-10-16 08:22:07 +00:00
|
|
|
'PDFiumProcessChild.h',
|
2017-11-29 09:15:31 +00:00
|
|
|
'PDFiumProcessParent.h',
|
2017-01-10 09:43:16 +00:00
|
|
|
'PDFViaEMFPrintHelper.h',
|
2016-07-01 08:15:16 +00:00
|
|
|
'WinCompositorWidget.h',
|
2016-04-09 06:15:31 +00:00
|
|
|
'WinMessages.h',
|
2016-04-09 06:45:06 +00:00
|
|
|
'WinModifierKeyState.h',
|
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 11:09:37 +00:00
|
|
|
'WinNativeEventData.h',
|
2013-04-16 19:24:43 +00:00
|
|
|
]
|
|
|
|
|
2013-12-16 00:00:54 +00:00
|
|
|
UNIFIED_SOURCES += [
|
2013-04-23 21:54:15 +00:00
|
|
|
'AudioSession.cpp',
|
2016-07-01 08:15:16 +00:00
|
|
|
'CompositorWidgetChild.cpp',
|
|
|
|
'CompositorWidgetParent.cpp',
|
2013-04-23 21:54:15 +00:00
|
|
|
'GfxInfo.cpp',
|
|
|
|
'IEnumFE.cpp',
|
2015-07-23 03:31:28 +00:00
|
|
|
'IMMHandler.cpp',
|
2015-04-17 13:59:00 +00:00
|
|
|
'InkCollector.cpp',
|
2016-07-19 18:56:07 +00:00
|
|
|
'InProcessWinCompositorWidget.cpp',
|
2013-04-23 21:54:15 +00:00
|
|
|
'JumpListItem.cpp',
|
2014-10-08 20:19:14 +00:00
|
|
|
'KeyboardLayout.cpp',
|
2017-11-23 09:59:04 +00:00
|
|
|
'LSPAnnotator.cpp',
|
2013-04-23 21:54:15 +00:00
|
|
|
'nsAppShell.cpp',
|
|
|
|
'nsClipboard.cpp',
|
2013-06-23 16:48:24 +00:00
|
|
|
'nsColorPicker.cpp',
|
2013-04-23 21:54:15 +00:00
|
|
|
'nsDataObj.cpp',
|
|
|
|
'nsDataObjCollection.cpp',
|
|
|
|
'nsDragService.cpp',
|
|
|
|
'nsIdleServiceWin.cpp',
|
|
|
|
'nsImageClipboard.cpp',
|
|
|
|
'nsLookAndFeel.cpp',
|
|
|
|
'nsNativeDragSource.cpp',
|
|
|
|
'nsNativeDragTarget.cpp',
|
|
|
|
'nsNativeThemeWin.cpp',
|
|
|
|
'nsSound.cpp',
|
|
|
|
'nsToolkit.cpp',
|
|
|
|
'nsUXThemeData.cpp',
|
|
|
|
'nsWindow.cpp',
|
2013-10-22 13:27:35 +00:00
|
|
|
'nsWindowBase.cpp',
|
2013-04-23 21:54:15 +00:00
|
|
|
'nsWindowDbg.cpp',
|
|
|
|
'nsWindowGfx.cpp',
|
2013-10-23 23:05:43 +00:00
|
|
|
'nsWinGesture.cpp',
|
2017-03-09 11:32:31 +00:00
|
|
|
'ScreenHelperWin.cpp',
|
2013-10-23 23:05:43 +00:00
|
|
|
'TaskbarPreview.cpp',
|
|
|
|
'TaskbarPreviewButton.cpp',
|
|
|
|
'TaskbarTabPreview.cpp',
|
|
|
|
'TaskbarWindowPreview.cpp',
|
|
|
|
'WidgetTraceEvent.cpp',
|
|
|
|
'WindowHook.cpp',
|
|
|
|
'WinIMEHandler.cpp',
|
2016-11-20 02:24:46 +00:00
|
|
|
'WinPointerEvents.cpp',
|
2014-10-06 20:11:24 +00:00
|
|
|
'WinTaskbar.cpp',
|
2016-03-16 04:47:48 +00:00
|
|
|
'WinTextEventDispatcherListener.cpp',
|
2013-10-23 23:05:43 +00:00
|
|
|
'WinUtils.cpp',
|
2013-04-23 21:54:15 +00:00
|
|
|
]
|
|
|
|
|
2013-12-16 00:00:54 +00:00
|
|
|
# The following files cannot be built in unified mode because of name clashes.
|
|
|
|
SOURCES += [
|
|
|
|
'JumpListBuilder.cpp',
|
|
|
|
'nsBidiKeyboard.cpp',
|
|
|
|
'nsFilePicker.cpp',
|
|
|
|
'nsWidgetFactory.cpp',
|
2016-08-23 22:18:55 +00:00
|
|
|
'WinCompositorWidget.cpp',
|
2015-06-16 18:51:29 +00:00
|
|
|
'WindowsUIUtils.cpp',
|
2014-10-08 20:19:14 +00:00
|
|
|
'WinMouseScrollHandler.cpp',
|
2013-12-16 00:00:54 +00:00
|
|
|
]
|
|
|
|
|
2013-04-23 21:54:15 +00:00
|
|
|
if CONFIG['NS_PRINTING']:
|
2013-12-16 00:00:54 +00:00
|
|
|
UNIFIED_SOURCES += [
|
2013-10-23 23:00:23 +00:00
|
|
|
'nsDeviceContextSpecWin.cpp',
|
2017-10-19 02:04:30 +00:00
|
|
|
'nsPrintDialogUtil.cpp',
|
2017-10-19 02:04:13 +00:00
|
|
|
'nsPrintDialogWin.cpp',
|
2013-04-23 21:54:15 +00:00
|
|
|
'nsPrintOptionsWin.cpp',
|
|
|
|
'nsPrintSettingsWin.cpp',
|
|
|
|
]
|
Bug 1399787 - Part 3. Create a top level protocol for the PDFium process. r=jwatt
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : b6459a187de8e066e7574d2b8757d09fbcfcddba
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
2017-10-13 08:58:07 +00:00
|
|
|
|
2017-10-19 02:04:30 +00:00
|
|
|
if CONFIG['MOZ_ENABLE_SKIA_PDF']:
|
|
|
|
DIRS += ['/modules/pdfium']
|
Bug 1399787 - Part 3. Create a top level protocol for the PDFium process. r=jwatt
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : b6459a187de8e066e7574d2b8757d09fbcfcddba
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
2017-10-13 08:58:07 +00:00
|
|
|
IPDL_SOURCES += [
|
|
|
|
'PPDFium.ipdl',
|
|
|
|
]
|
2017-10-19 02:04:30 +00:00
|
|
|
UNIFIED_SOURCES += [
|
Bug 1399787 - Part 3. Create a top level protocol for the PDFium process. r=jwatt
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : b6459a187de8e066e7574d2b8757d09fbcfcddba
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
2017-10-13 08:58:07 +00:00
|
|
|
'PDFiumChild.cpp',
|
2017-10-19 02:04:30 +00:00
|
|
|
'PDFiumEngineShim.cpp',
|
Bug 1399787 - Part 3. Create a top level protocol for the PDFium process. r=jwatt
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : b6459a187de8e066e7574d2b8757d09fbcfcddba
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
2017-10-13 08:58:07 +00:00
|
|
|
'PDFiumParent.cpp',
|
2017-10-16 08:22:07 +00:00
|
|
|
'PDFiumProcessChild.cpp',
|
|
|
|
'PDFiumProcessParent.cpp',
|
2017-10-19 02:04:30 +00:00
|
|
|
'PDFViaEMFPrintHelper.cpp',
|
|
|
|
'WindowsEMF.cpp',
|
|
|
|
]
|
2013-04-23 21:54:15 +00:00
|
|
|
|
|
|
|
if CONFIG['NS_ENABLE_TSF']:
|
2013-10-24 23:23:05 +00:00
|
|
|
SOURCES += [
|
2015-07-24 05:07:39 +00:00
|
|
|
'TSFTextStore.cpp',
|
2013-04-23 21:54:15 +00:00
|
|
|
]
|
2013-08-22 06:56:01 +00:00
|
|
|
|
2013-10-02 17:17:55 +00:00
|
|
|
include('/ipc/chromium/chromium-config.mozbuild')
|
|
|
|
|
2013-11-19 02:47:14 +00:00
|
|
|
FINAL_LIBRARY = 'xul'
|
2013-11-27 13:55:07 +00:00
|
|
|
|
2017-06-20 03:34:43 +00:00
|
|
|
if CONFIG['MOZ_ENABLE_SKIA_PDF']:
|
|
|
|
LOCAL_INCLUDES += [
|
|
|
|
'/gfx/skia/skia/include/config',
|
|
|
|
'/gfx/skia/skia/include/core',
|
2017-07-06 02:25:46 +00:00
|
|
|
'/modules/pdfium/pdfium/public',
|
2017-06-20 03:34:43 +00:00
|
|
|
]
|
2017-08-09 06:28:16 +00:00
|
|
|
TEST_DIRS += ['gtest']
|
2017-06-20 03:34:43 +00:00
|
|
|
|
2013-11-28 14:17:25 +00:00
|
|
|
LOCAL_INCLUDES += [
|
|
|
|
'/layout/generic',
|
2013-12-04 01:06:16 +00:00
|
|
|
'/layout/xul',
|
2013-11-28 14:17:25 +00:00
|
|
|
'/toolkit/xre',
|
2014-10-23 17:16:45 +00:00
|
|
|
'/widget',
|
2017-06-07 21:33:11 +00:00
|
|
|
'/widget/headless',
|
2013-11-28 14:17:25 +00:00
|
|
|
'/xpcom/base',
|
|
|
|
]
|
|
|
|
|
2013-11-27 13:55:07 +00:00
|
|
|
DEFINES['MOZ_UNICODE'] = True
|
|
|
|
|
2015-01-23 03:41:20 +00:00
|
|
|
for var in ('MOZ_ENABLE_D3D10_LAYER'):
|
2013-11-27 13:55:07 +00:00
|
|
|
if CONFIG[var]:
|
|
|
|
DEFINES[var] = True
|
2014-02-10 14:03:53 +00:00
|
|
|
|
|
|
|
RESFILE = 'widget.res'
|
2014-07-24 15:55:33 +00:00
|
|
|
|
|
|
|
CXXFLAGS += CONFIG['MOZ_CAIRO_CFLAGS']
|
2016-01-25 19:48:02 +00:00
|
|
|
|
|
|
|
OS_LIBS += [
|
|
|
|
'rpcrt4',
|
|
|
|
]
|
2017-11-08 03:52:10 +00:00
|
|
|
|
|
|
|
if CONFIG['_MSC_VER']:
|
|
|
|
# C5038: Suppress initializer list order warnings from wrl.h
|
|
|
|
SOURCES['WindowsUIUtils.cpp'].flags += ['-wd5038']
|