Chromium dispatches a keypress event when pressing Enter or Shift+Enter.
Actually, when user press them in <pre> element of HTML editor, ﾂ･n is inserted.
It makes sense to treat the key combinations as inputting text.
MozReview-Commit-ID: Hvx87MZtZkn
--HG--
extra : rebase_source : 196b63843ebcb6e4b398f6b21a4f5f1d020b8db3
UI Events declares that keypress event should be fired when the keypress event
causes some text input. However, we're keeping our traditional behavior for
historical reasons because our internal event handlers (including event
handlers of Thunderbird) handles keypress events for any keys. Therefore,
for minimizing the side effect, we should stop kicking keypress event handlers
in the default event group in web content.
This patch adds new pref for enabling the standard behavior in web content.
Additionally, creates WidgetKeyboardEvent::IsInputtingText() for sharing the
check logic between TextEventDispatcher and TextEditor/HTMLEditor.
MozReview-Commit-ID: 3rtXdLBPeVC
--HG--
extra : rebase_source : 2fc3c9a09840d0d03800c9a42bb83ca76a8db2d5
TextInputHandler::HandleCommand() has two bugs. One is, checking whether
the key event has caused composition events. Even if it caused composition
events, we decided to dispatch keypress event for emulating native behavior.
Therefore, this patch removes the check of
|currentKeyEvent->CanDispatchKeyPress()|.
The other is, for making content handle dispatching keypress event as given
command, it needs to dispatch a keypress event whose key combination will
cause the command. However, HandleCommand() needs to set native key event
since content may not refer key combination for some edit actions, they just
refer command which is computed with native key event with NativeKeyBindings.
Therefore, even if current native key event has already caused dispatching
some events, HandleCommand() needs to set
WidgetKeyboardEvent::mNativeKeyEvent to current native key event for
NativeKeyBindings. Although it must be rare case, given key could be
not related to the command or not key could cause the command. In this
case, and perhaps in all cases, we should set all commands of dispatching
keypress event before dispatching it. Howevever, this needs more work,
so, we shouldn't do it in this bug to making it possible to uplift.
Therefore, this patch makes always set mNativeKeyEvent to current native
key event. So, just warning it when command is caused without native
key event.
MozReview-Commit-ID: 2MvDTw4ruAu
--HG--
extra : rebase_source : 02a4ca980530aa16fa0e1aecd6d18fa42873c1dc
extra : source : 1e3137db3fe9822f34b98d59fb928497caca466a
Titlebar button on Gtk+ >= 3.20 can have defined its size as min-width and min-height
and can leave CSS styles border/padding empty. To render the button icon at center we need to
calculate button widget border from gap between icon and button.
This is done by GetToolbarButtonMetrics() which also stores final values to
ToolbarButtonGTKMetrics cache.
MozReview-Commit-ID: 5sMJATWHUNX
--HG--
extra : rebase_source : b0bda7c78106088a819b98c197cbb0cd099e47df
We need to use scaling factor of the monitor on which application is actually positioned.
Previously we used ScreenHelperGTK::GetGTKMonitorScaleFactor() which use the first monitor.
This does not work on hidpi+normal dpi monitors setup.
MozReview-Commit-ID: 1dVYOe48tPJ
--HG--
extra : rebase_source : af804d3104da91be459b219b261949d84b4f7c26
The GetSystemFontInfo() cannot return scaled value of the font by default monitor
scale factor. We need to scale it in nsLookAndFeel::GetFontImpl
by aDevPixPerCSSPixel like implementation for Windows does.
MozReview-Commit-ID: 5okD8vUu9UK
--HG--
extra : rebase_source : 39f3dec4acd434501860a8b716a42c45aadf3b61
Emulate what gtk+/gtkwindow.c gtk_window_present_with_time() does - use gdk_x11_display_get_user_time() on X11
and gtk_get_current_event_time() on Wayland to get event timestamp.
MozReview-Commit-ID: GEU6ZrQxq6v
--HG--
extra : rebase_source : db2f3ac03ae4ec9f9c1655cf682bff60a96dd3da
It looks like the work in bug 1291457 was all that was necessary to get working
window shadows for accelerated popups. It seems that macOS is able to compute
the correct shadow style consistently for whatever is drawn in the
NSOpenGLContext during the first paint of the window (inside the drawRect call
during the orderFront call that opens the window).
We only ran into problems when we animated the contents of the window in a way
that affects the shadow style; we're no longer doing that after bug 1291457.
MozReview-Commit-ID: 62mfWuAsrg2
--HG--
extra : rebase_source : bf8121451474629f0194ccbb422147d5f05ff5b3
extra : source : 57b4a3dff2a5799c5c994a5b577b76c98ebc8226
Looking at the docs for [NSWindow title] I don't think it's supposed to return
nil under any circumstances...
But it does in our automation, for some reason, with the patches for bug 1439875
which make our fullscreen code run a bit earlier.
MozReview-Commit-ID: AX4qzjzsqST
--HG--
extra : rebase_source : a01f2ba6b42b4067e7a4886c4814e85f317a4a6f
Call PreventNativeKeyBindings() for all key events to prevent triggering
an assertion in PuppetWidget.
MozReview-Commit-ID: 3x96p9baTze
--HG--
extra : rebase_source : 1f1477074e49ca7be9b3f3956289adf4f288a223
Firefox in Flatpak sandboxed environment does not get the list
of installed applications on the system because application should
know about the environment as little as possible. Introducing
nsFlatpakHandlerApp which forwards requests for opening downloaded files
to the system by utilizing gtk_show_uri fuction.
This changeset also removes nsIGIOMimeApp::Launch method from the interface
because it can be fully replaced with LaunchWithUri from nsIHandlerApp
interface.
The TMPDIR where files are downloaded when user choose to open them
needs to be accessible from sandbox and host. The default settings
TMPDIR=/tmp is accessible only to the sandbox.
To workaround for is to set TMPDIR environment variable to
$XDG_CACHE_HOME/tmp before executing Firefox.
MozReview-Commit-ID: CSBv0QcETpd
--HG--
extra : rebase_source : 8155c33fa9c402d2668bdfb07094ba6758fe6203
New Windows devices are coming out that have GPU Device ID strings of
the form
ACPI\VEN_QCOM&DEV_007C&SUBSYS_CLS08998&REV_007C
as reported in the bug description. Since the VEN_ ID is not numeric,
this change interprets the QCOM string so that it can be whitelisted
and then whitelists it.
MozReview-Commit-ID: 2ABRzvHKn6v
--HG--
extra : rebase_source : 6951d3bfc060abc298c93dd31db07715d6857cc5
Currently, TSFTextStore::GetTextExt() refers mComposition for doing its own
hack. However, this means that it refers composition in TIP. However,
query event is computed with content information. So, even if TSFTextStore
dispatched eCompositionCommit event, it may not be handled by content yet.
In this case, we need information relative to last composition string.
So, TSFTextStore::GetTextExt() should refer IsHandlingComposition() and
last composition string information stored by mContentForTSF.
MozReview-Commit-ID: KMqrDmnUldU
--HG--
extra : rebase_source : cea97c9e9117028913cf45e4dc1e83e2b4f102e9
If remote process hasn't handled dispatched commit event yet, TSFTextStore
needs to dispatch query content event relative to latest composition string
information. So, TSFTextStore::mContentForTSF should cache composition start
and composition string length until pending composition events are handled
by content actually.
MozReview-Commit-ID: ARM851nNZGz
--HG--
extra : rebase_source : d4f1ddb197d3168f2db52849b2982779c388e2e8
Currently, ContentCacheInParent uses selection when it handles query content
event whose input offset is relative one after sending eCompositionCommit(AsIs)
event but it's not yet handled by the remote process. However, in this case,
selection may not be modified with committed string.
So, when mPendingCommitCount is not 0, ContentCacheInParent should compute
absolute offset with the latest composition string information. For doing
this, it needs to keep storing mCompositionStart until eCompositionCommit(AsIs)
is handled in the remote process actually.
MozReview-Commit-ID: 2Dc69HNIbvh
--HG--
extra : rebase_source : 4be432ad363022e4b3f2e3c82c8d229dc9af889d
When composition events are handled by content actually, widget receives
NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED notification. If focused content
is in a remote process, this is notified only when all sending composition
events are handled in the remote process. So, when widget receives the
notification can there is no composition in IME, that means that nobody is
composing composition at that time.
This patch adds TextEventDispatcher::IsHandlingComposition() which returns
false only when nobody has composition and makes TSFTextStore refer this
method because TSFTextStore needs to know if focused content has composition
in any cases.
MozReview-Commit-ID: F1ZZgFJAArD
--HG--
extra : rebase_source : 65e7f592e0ffd1c516e4dab16ab4ca8d7171f954
Make the clipboard data getter function more explicitly named and also create a counterpart to release clipboard data.
MozReview-Commit-ID: 3pWsQgCFDuG
--HG--
extra : rebase_source : c4eae554f5a24d998801550ac91b0859ac8e116e
It's possible for parcels derived from the session to outlast the
session lifecycle. This patch makes us return null when trying to
retrieve window objects using stale parcels.
MozReview-Commit-ID: 3Vp6T3uCEBt
--HG--
extra : rebase_source : 5e6b5d71786b326a0f47781cdb8dd5ea90ae71d6
nsWindow needs configuration change when rendering on Wayland:
- Always draw to mContainer on Wayland as we can't create custom subsurface for
mShell GdkWindow and listen events on mContainer then.
- GTK_WINDOW_TOPLEVEL can't be positioned on Wayland so create popup windows
as GTK_WINDOW_POPUP to control window position on Wayland.
- Create ePopupTypeMenu GdkWindow as GDK_WINDOW_TYPE_HINT_UTILITY instead of
GDK_WINDOW_TYPE_HINT_POPUP_MENU to create it as subsurface (Bug 1423598).
- Don't do pointer grab on Wayland (see Bug 1377084 for reference).
MozReview-Commit-ID: 6InzhTONtrD
--HG--
extra : rebase_source : 356112c2e8f80569ca4b2e41fa0747d71da21d89
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
Wayland compositors do not support GDK_DECOR_BORDER so use CSD decorations exclusively.
MozReview-Commit-ID: 8gzDcw2AumI
--HG--
extra : rebase_source : 4d319155d220420a768de619e7043dd56f6ee667
To have any effect we need to call gdk_window_set_decorations() on top-level GdkWindow only.
When rendering to mContainer the mGdkWindow belongs to mContainer so we need to get the window
from mShell explicitly.
MozReview-Commit-ID: KLKlVJbgg3
--HG--
extra : rebase_source : c17310949e067dca540bf269f12db135e6582ebc
When drawing to mContainer we still need to honor mShell as top-level window.
It means we have to listen property-notify-event there (as it's window specific),
get _NET_FRAME_EXTENTS here and use at nsWindow::SetWindowClass().
MozReview-Commit-ID: HYbNS0Lfyjy
--HG--
extra : rebase_source : f03cb4657a36238fd93b47b94ace48a325648296
This patch adds following Microsoft's IMEs into the black list which set
their open state to "closed" when input scope is set to IS_URL and sets
input scope for the URL bar to IS_DEFAULT.
Additionally, this adds a new pref to disable this hack because a lot of
users will affect this hack but perhaps, somebody may not like this if
they use tablet.
The new black listed IMEs:
- Microsoft Bopomofo
- Microsoft ChangJie
- Microsoft Phonetic
- Microsoft Quick
- Microsoft New ChangJie
- Microsoft New Phonetic
- Microsoft New Quick
- Microsoft Pinyin
- Microsoft Pinyin New Experience Input Style
- Microsoft Wubi
- Microsoft IME for Korean (except on Win7)
- Microsoft Old Hangul
MozReview-Commit-ID: BwJKFcu80B8
--HG--
extra : rebase_source : 75aeed04504b476520102984ab6e7875c98b36c8
Track the Gecko ready state in TextInputController through
GeckoSession's NativeQueue, and only pass through input calls when Gecko
is ready.
MozReview-Commit-ID: KugQ6whg2QA
--HG--
extra : rebase_source : 6ea266d9746d22c58cdd21c7122fa7f20ec730fc
There may be some pending input events in the queue of thread when content starts a dnd operation. Spec says that input events should be suppressed when there is a dnd operation. Add a flag in ESM and turn on/off when start/finish a dnd operation. Checking the flag in PresShell::HandleEvent because we may start a dnd operation with pointermove and we want to suppress the mousemove as well.
MozReview-Commit-ID: 43NZrA7SW4c
We don't add build-time dependency on Wayland libraries; that allows Wayland enabled Firefox
builds to run on systems without Wayland support.
We also can't dlsym() Wayland symbols directly from libwayland-client.so library as we miss
global data entries referenced by code at wayland-client.h then.
As a partial solution (for glibc systems only) we create dummy libwayland-client.so library
implementation and place it *after* Gtk+ 3.0 libraries at linking time.
It fixes build-time dependencies (we link against our libwayland-client.so library).
Run-time dependency is resolved by ld.so - when Gtk+ 3.0 libraries are linked with
system libwayland-client.so library, wayland symbols are pulled from there instead
from our dummy libwayland-client.so library.
When Gtk+ 3.0 is not linked with system libwayland-client.so it means we're running
on system without Wayland support. Our dummy libwayland-client.so implementation
is used (symbols are pulled run-time from there) and Firefox Wayland support is
disabled then.
MozReview-Commit-ID: IyaePwp4MxV
--HG--
extra : rebase_source : 852955d001657176e0bf69c099580be862d0b448
It's possible for parcels derived from the session to outlast the
session lifecycle. This patch makes us return null when trying to
retrieve window objects using stale parcels.
MozReview-Commit-ID: 3Vp6T3uCEBt
--HG--
extra : rebase_source : fceda356bf812d80d81f4e35cbc3f74ad6151d77
We implement PointerEvent.getCoalescedEvents as
1. Clone the widget events we coalesced.
2. Convert them to dom::PointerEvent when user calls getCoalescedEvents.
MozReview-Commit-ID: 8IKw4PbUsDD
We call PDFiumParent::Close twice under certain conditions. Once in
PDFiumProcessParent::Delete, and once in PDFiumProcessParent's dtor. So we may
hit MOZ_ABORT which tell us that we are trying to close a closed channel.
This patch prevents hitting this abort by:
1. Only close the channel in PDFiumProcessParent::Delete, remove another call
in PDFiumProcessParent's dtor. (Please see the change in
PDFiumProcessParent.cpp).
2. Remove PDFiumParent::AbortConversion and relative code. We can just use
PDFiumParent::EndConversion instead. When calling PDFiumParent::Close, we
actually close the IPC channel *synchronously*, which means there is no need
to register a callback by PDFiumParent::AbortConversion to receive
actor-destroy callback.
MozReview-Commit-ID: 9i5j6t54J3h
--HG--
extra : rebase_source : 5f74ebc1ecc29e9983c30ca2dd63e0b49bd24a50
WindowSurfaceWayland is Wayland implementation of WindowSurface class.
One WindowSurfaceWayland object manages drawing of one nsWindow so
those are tied 1:1. It implements base Lock() and Commit() interfaces
from WindowSurface. At Wayland side it represents one wl_surface object.
To perform visualiation of nsWindow, WindowSurfaceWayland contains
one wl_surface and two wl_buffer (by WindowBackBuffer) objects
(as we use double buffering). When nsWindow drawing is finished to
wl_buffer, the wl_buffer is attached to wl_surface and it's sent to
Wayland compositor.
MozReview-Commit-ID: 9NoamtF87e6
--HG--
extra : rebase_source : e942b28f1eaa4b1c24c6c4df6894db8d3d789e7e
wl_buffer is a main Wayland object with graphics data. wl_buffer basically represent one complete window screen.
When double buffering is involved every window (GdkWindow in our case) utilises two wl_buffers which are cycled.
One is filed with data by application and one is rendered by compositor.
WindowBackBuffer class manages one wl_buffer. It owns wl_buffer object, owns WaylandShmPool (which provides shared memory)
and ties them together.
MozReview-Commit-ID: v8Hlezo7oD
--HG--
extra : rebase_source : 40bffbbae2ee0c8f67d442ee2c5a62be43fafb44
We allocate shared memory (shm) by mmap(..., MAP_SHARED,...) as an interface between wayland based application
and wayland compositor. We draw our graphics data to the shm and handle to wayland compositor by wl_buffer/wl_surface.
WaylandShmPool acts as a manager of the allocated memory. Allocates it, holds reference to it and releases it.
MozReview-Commit-ID: CY6oEIl4Vxa
--HG--
extra : rebase_source : c43da8728e11e133cb021b1832382c1a39695a1a
Refactor ncClipboard::GetData() for better readability, add nsClipboard::SetTransferableData()
to send clipboard data to nsITransferable.
According to Gtk people [1] we can't mix free()/g_free() and malloc()/g_malloc() calls.
Existing nsClipboard code mixes that on some places which can lead to issued on glib built
with specific flags (ENABLE_MEM_PROFILE or ENABLE_MEM_CHECK).
[1] https://mail.gnome.org/archives/gtk-list/2000-July/msg00002.html
MozReview-Commit-ID: GvkUGSttVGO
--HG--
extra : rebase_source : 99801e1dc97e24a8d68fe7f3585562bb541c6628
Move GeckoEditableClient and GeckoEditableListener to inside
TextInputController, next to TextInputController.Delegate. This
consolidates the three internal interfaces used for IME in one place.
The patch also changes the last notifyIMEContext parameter to an int
flag to indicate private browsing or user action. This allows for future
expansion without adding more parameters to notifyIMEContext.
MozReview-Commit-ID: BjscdNr9TkO
--HG--
extra : rebase_source : 87166a55e5978eda4a7c3065db9b68658e33af35
Remove InputConnectionListener, which was replaced by
TextInputController.Delegate, and remove IME_STATE_PLUGIN, which is not
used anymore.
MozReview-Commit-ID: GCbJXWNCmTk
--HG--
extra : rebase_source : c90bc79585ce4c5b9c0de5e07b0ea52531b65e04
Use the new TextInputController API in GeckoView to process key events
and input method interactions.
MozReview-Commit-ID: H0oyCDkGHul
--HG--
extra : rebase_source : a0ab70e77aa05b7d3aa05982c47299a0222f3ee5
Add TextInputController and add a getter for it in GeckoSession.
TextInputController is used to process key events and to interact with
the input method manager.
MozReview-Commit-ID: 1j2Moqukf8U
--HG--
extra : rebase_source : 03fee51ba3e2034b8689c4fa6fe58f7432dc1ad4
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
Bug 1421974 introduced new mechanism to hide system titlebar by enabling client-side decorations for main Firefox window. It also causes a regression when the CSD window setup is enabled when system titlebar is hidden by window manager.
This patch fixes that and enables the CSD window setup only for case when it's actualy used.
MozReview-Commit-ID: AqfHR2bGr3K
--HG--
extra : rebase_source : 625366530922872af82e182db10f5069ebfa7dc4
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
As a startup optimization, we tried to open the GeckoSession window
synchronously in certain situations, but apparently that's conflicting
with some other code to cause deadlocks.
MozReview-Commit-ID: 88uhr7leVy1
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
This is to make the header file more concise.
MozReview-Commit-ID: 7RFkppBdvbU
--HG--
extra : rebase_source : 781e3cadc60739297f37e826fef5f37a5c60a02d
extra : intermediate-source : 317d238af4025e64b8af61488fada9ec3d0b05c7
extra : source : 59d7baf15160231a53c459a3912e2c1430a1fa0e
While aborting conversion, we need to make sure there is no coversion task
executing in the PDFium process before destroying it.
MozReview-Commit-ID: 3Iqhe8KmYv2
--HG--
extra : rebase_source : 70d9f0b2e2986499e3061823e0c29830aa81d232
extra : source : 753ed705666fd4c55da456fb80604e4552d6bd52
We integrate PrintTargetEMF with the PDFium process to convert PDF into EMF in
this patch.
MozReview-Commit-ID: 5F0setrL94n
--HG--
extra : rebase_source : 1e52adbbe7502ca081c7029a15e4b3f486beb284
extra : source : 28f1671230fa70125e6971c9a287cb0658b89496
This is to make the header file more concise.
MozReview-Commit-ID: 7RFkppBdvbU
--HG--
extra : rebase_source : de0a2fc73ea43fedd90b1a0f2ae79d68749a00f7
extra : intermediate-source : 317d238af4025e64b8af61488fada9ec3d0b05c7
extra : source : 59d7baf15160231a53c459a3912e2c1430a1fa0e
While aborting conversion, we need to make sure there is no coversion task
executing in the PDFium process before destroying it.
MozReview-Commit-ID: 3Iqhe8KmYv2
--HG--
extra : rebase_source : c4597de6c13d35024090ec1e851ad1db5b790c7a
extra : source : 753ed705666fd4c55da456fb80604e4552d6bd52
We integrate PrintTargetEMF with the PDFium process to convert PDF into EMF in
this patch.
MozReview-Commit-ID: 5F0setrL94n
--HG--
extra : rebase_source : 3dfc6ce64f4cdc7d5d7e95d1f064d956af909a26
extra : source : 28f1671230fa70125e6971c9a287cb0658b89496
To move EMF conversion job to a dedicated process, I will implement a new
PrintTarget subclass, named PrintTargetEMF, to coordinate tasks among the
content process, chrome process and PDFium process. All the code that we
change in nsDeviceContextSpecWin is no longer needed.
MozReview-Commit-ID: GgKZoB92WYE
--HG--
extra : rebase_source : 4b1999bd83306dce162f76bd5e46015113a52e2b
To move EMF conversion job to a dedicated process, I will implement a new
PrintTarget subclass, named PrintTargetEMF, to coordinate tasks among the
content process, chrome process and PDFium process. All the code that we
change in nsDeviceContextSpecWin is no longer needed.
MozReview-Commit-ID: GgKZoB92WYE
--HG--
extra : rebase_source : 16c3a3e730bd2395f98b558962ec8d0a5723198b
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 : c64c4d39ccca16271959ade57edc2a8a087141b8
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
This is to make the naming more consistent with SavePageToBuffer.
MozReview-Commit-ID: 5miYvv9yFFR
--HG--
extra : rebase_source : d0a433e55a1a919a4207aee5f2fee9e75bd0a36e
With the help of these new function, we can serialize/deserialize EMF content
in/out a share memory object.
MozReview-Commit-ID: Dm45xEXmMqS
--HG--
extra : rebase_source : a84834075aa58099104ba9cdaa375da4b973c23b
extra : source : 61f81b148f8b1d1569d7cf279575b38f4570171f
All the functions added in Part 2 are utilities for sharing EMF/PDF contents
between processes.
MozReview-Commit-ID: 3qKosXH56kY
--HG--
extra : rebase_source : 677bf9f30399f28e1e094843448c133b0c2391a7
extra : source : b61b651ed6f668e32176353d346b25d23e2cd932
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 : 92276c366e3e8faa9be7a43fa64c2c5c56a7014b
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
This is to make the naming more consistent with SavePageToBuffer.
MozReview-Commit-ID: 5miYvv9yFFR
--HG--
extra : rebase_source : 5fa0594338ccae196866a1eb2e811e30b41c9290
With the help of these new function, we can serialize/deserialize EMF content
in/out a share memory object.
MozReview-Commit-ID: Dm45xEXmMqS
--HG--
extra : rebase_source : 02b571735de70b499aea30bfdb3c0a35fece3332
extra : source : 61f81b148f8b1d1569d7cf279575b38f4570171f
All the functions added in Part 2 are utilities for sharing EMF/PDF contents
between processes.
MozReview-Commit-ID: 3qKosXH56kY
--HG--
extra : rebase_source : f28b808f7007633fbeea3dbea78c19541bc73667
extra : source : b61b651ed6f668e32176353d346b25d23e2cd932
We will create several new files in the following patches for IPC and a new
subprocess. Several already existed files will be shifted into new build units,
we will meet several compile errors because of it.
This patch fixes those compile error in advance.
MozReview-Commit-ID: 5hd0sNYfBu0
--HG--
extra : rebase_source : d4cca529623586188ffebffd858f53188d12bb50
We will create several new files in the following patches for IPC and a new
subprocess. Several already existed files will be shifted into new build units,
we will meet several compile errors because of it.
This patch fixes those compile error in advance.
MozReview-Commit-ID: 5hd0sNYfBu0
--HG--
extra : rebase_source : 0d85c823e4ead4f09175f2cc83df811b2b4081ec
This patch makes 'Shift', 'Alt', 'Contorl' and 'AltGraph' been suppressed for content
when fingerprinting resistance is enabled. Chrome can still get these events.
The reason behind this is that websites can still observe key combinations to
tell which keyboard layout is using even we spoof the keyboardEvent.code,
keyboardEvent.keyCode and modifier states. For example, the AZERTY France
keyboard, the digit keys of it requires the user press the Shift key. So, it is
easy to differentiate AZERTY and QWERTY keyboard by observing whether a Shift key
generates its own before the digit keys. There are similar issues for 'Alt' and
'AltGraph' as well.
MozReview-Commit-ID: 3CwCgvey4lK
--HG--
extra : rebase_source : 225a34ab188f6cca288a6c0e9874261df7db629f
Masatoshi Kimura
Martin Stransky
Masayuki Nakano
arthur.iakab
Gurzau Raul
Andrea Marchesini
Kris Maglione
Nick Alexander
Cosmin Sabou
Narcis Beleuzu
Brindusan Cristian
Valentin Gosu
Ryan Hunt
Sebastian Hengst
Noemi Erli
Jan Horak
Dorel Luca
Nika Layzell
Markus Stange
Emilio Cobos Álvarez
Rob Wu
Michael Kaply
Louis Chang
Jim Chen
Hiroyuki Ikezoe
Jon Kunkee
Brendan Dahl
Tiberius Oros
Ryan VanderMeulen
Kartikaya Gupta
David Parks
Margareta Eliza Balazs
Mike de Boer
Csoregi Natalia
Nicolas Silva
Chris Peterson
Jonathan Watt
Cameron McCormack
Paolo Amadini
David Anderson
Sylvestre Ledru
Ciure Andrei
cku
Milan Sreckovic
Eugen Sawin
Henri Sivonen
Kyle Machulis
Aaron Klotz
Botond Ballo
Olli Pettay
Jan Steffens
Andreea Pavel
Andrew McCreight
Florian Quèze
Stone Shih
Jeff Gilbert
Stephen A Pohl
Moritz Brunner
Samathy Barratt
shindli
Eric Rahm
Tim Huang
Bob Owen
Bogdan Tara