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 is based on Karl Tomlinson's (:karlt) demo from Bug 1419456. We use gtk_window_set_titlebar()
to set invisible widget. The widget takes place of GtkHeaderBar which leads Gtk+ to render CSD shadows
and handle window resizing, it does not render any titlebar.
gtk_window_set_titlebar() works on unrealized windows only and mShell is already realized at time
of nsWindow::SetDrawsInTitlebar() call so we need to update recent GtkWidget setup.
In that case we create GdkWindow for mContainer (instead of mShell), create a temporary GtkWindow,
reparent mContainer (which owns mGdkWindow) to it, unrealize mShell and set up the titlebar
for mShell toplevel window.
As a workaround for Gtk+ Bug 791081 we also allocate some valid size for mShell before it's newly realized
with the updated titlebar.
MozReview-Commit-ID: A3KwRoOzoko
--HG--
extra : rebase_source : ded644762d3be9e79e3d407f57b2f9098021fb96
Remove unused classes and make classes that are not used outside of the
package package-private.
MozReview-Commit-ID: 9FxcL5QsM1Q
--HG--
extra : rebase_source : d9ed39d06a0e2aadec131d06c92cb11ef342a320
Let's make TextInputHandler::HandleCommand() handle other
commands which are caused by Backspace, Delete, Tab, ArrowUp,
ArrowDown, ArrowRight, ArrowLeft, PageUp, PageDown, Home, End
and Escape keys with various modifiers.
This patch makes Korean users can do most key operation in
editor even with composing Hangul character.
Note that this patch has a hack for cancelOperation: command.
The command is typically fired for Escape key press. However,
it's also fired for Command + Period. Unfortunately, this
behavior is really odd if subclass of NSResponder implements
|void cancelOperation:(id)sender|. If it's implemented,
Cocoa doesn't call its |void keyDown:(NSEvent)theEvent|.
Instead, it calls only |void doCommandBySelector:(SEL)aSelector|
and |void cancelOperation:(id)sender| when Command + Period is
pressed. Therefore, we cannot dispatch keydown nor keypress
event for this key combination if we implement it. Therefore,
this patch doesn't implement the method but handle it in
doCommandBySelector even though the super class of ChildView
cannot handle the command with this path.
MozReview-Commit-ID: 4hS23SiwNJv
--HG--
extra : rebase_source : 38ac1ea494b5f786ecd5c9327efbacd460b59faf
Currently, we handle insertNewline: of NSResponder with
TextInputHandler::InsertNewline(). However, its
implementation is useful for handling some other
commands. So, let's rename it to HandleCommand() and
make it take Command as its argument for handling
specific behavior of each command.
MozReview-Commit-ID: GgzQdTlVtYl
--HG--
extra : rebase_source : e1d1c8617897d29eb10ba62708e3549a77c6ee59
Use GeckoSession/LayerSession or GeckoView in Fennec code instead of
using LayerView.
MozReview-Commit-ID: Iod7XsqKy1e
--HG--
extra : rebase_source : 5917540422698f5526ca373f17c4358a712cdcef
The browser.tabs.drawInTitlebar check at nsLookAndFeel is redundant, breaks Thunderbird and dynamic titlebar rendering change. Let's use browser.tabs.drawInTitlebar at browser level and when enabled configure titlebar visibility by moz_gtk* media atoms.
MozReview-Commit-ID: IhCYmXgVME7
--HG--
extra : rebase_source : 6f152e5c3d7d5abbb134c9f5adcb76fd6ed335cb
With this patch print IPC no longer requires the child process to create files.
Instead files are opened by the parent and a file descriptor is sent to the
child. This will allow us to sandbox child processes more aggressively.
MozReview-Commit-ID: GQWTYLV01kj
--HG--
extra : rebase_source : 9b91e9b01708d73915a49684c2cec96457650e45
Enables override window manager default with those values:
MOZ_GTK_TITLEBAR_DECORATION=none - Firefox does not mess with decoration
MOZ_GTK_TITLEBAR_DECORATION=client - Firefox tries to disable titlebar rendering and draws shadows by client side decorations.
MOZ_GTK_TITLEBAR_DECORATION=system - Firefox tries to disable titlebar rendering and leave system (window manager) to draw window decorations.
MozReview-Commit-ID: G60QS3g1TD0
--HG--
extra : rebase_source : fd7b5d2b0282fbd54046947d210b1288a0610a23
This is to make the header file more concise.
MozReview-Commit-ID: 7RFkppBdvbU
--HG--
extra : rebase_source : 29776b51e0ca9d0671bda208b84977b44d97bb22
extra : intermediate-source : 317d238af4025e64b8af61488fada9ec3d0b05c7
extra : source : 59d7baf15160231a53c459a3912e2c1430a1fa0e
This allows us to fire MozMouseHittest events from tests and then read
the hittest result from the compositor APZTestData. The MozMouseHittest
event was chosen in particular because the existing uses of it are
similar in nature - it is a dummy event that is used to determine what
elements a particular coordinate targets. It is also an event that is
never generated by the OS and so using this event gives us more control
over what ends up in the APZTestData.
MozReview-Commit-ID: KHjIX7EpK2A
--HG--
extra : rebase_source : f7d7d729c1935eefd49ed06d8644ff9ef537f2e1
We need apply various titlebar/border configuration which is based on active
window manager and desktop type. The XDG_CURRENT_DESKTOP shell variable contains active
desktop environment which we use at GetCSDSupportLevel().
Unfortunately Ubuntu adds "ubuntu:" prefix at XDG_CURRENT_DESKTOP so we can't do
plain string compare but rather search for DE substring at GetCSDSupportLevel().
MozReview-Commit-ID: GmAZ30p47eI
--HG--
extra : rebase_source : eeef51e7326bb8be6418554b07ce5791e988f02f
DBus strings can contain only [a-z][A-Z][0-9]_ chars. Encode profile name (used as part of interface name) by base64 and adjust it to avoid crashes (Bug 1418985).
MozReview-Commit-ID: J2SQHYRcWDW
--HG--
extra : rebase_source : 6ef46a1b390796021030fe0dc2e0294262eaea0c
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 : b82fe3b7231d9c4a171d6a19cd22c0c7ff47b4bf
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 : 576e077f804785da20923620d9c4e3041936e835
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 : 1687d72a8fe88223f17c954c23022236dfe029a0
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
This is to make the naming more consistent with SavePageToBuffer.
MozReview-Commit-ID: 5miYvv9yFFR
--HG--
extra : rebase_source : 07d1f72b33f962622a843355da6d3067a286483a
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 : 8203924d873509ccb2d869bf1b427afb6afb718e
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 : 0531cfa563094c1a3a6dac4895ed1b8edfd285e0
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 : b6b8b069f8f2167ef87266ba9c95e8fe53cca6f6
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: 6OzoPyxlhCp
--HG--
extra : rebase_source : 9bcfc96cd27cb088f8d9671780304c2ac3772fdf
After fixing bug 1420849, remote process started to ignore composition events
after it synthesizes eCompositionCommit event after requesting to commit
composition. However, remote process still keeps returning composition events
when it receives from the main process. So, if the main process has already
sent eCompositionCommit(AsIs) event when it's requested to commit composition
from the remote process, ContentCacheInParent::OnEventNeedingAckHandled()
receives both eCompositionCommitRequestHandled and eCompositionCommit(AsIs)
events for *a* composition. Therefore, mPendingCompositionCount may be
decremented twice for a composition. This causes hitting MOZ_DIAGNOSTIC_ASSERT.
So, ContentCacheInParent need to manage if sent composition events are ignored
or not. Then, ContentCacheInParent::OnEventNeedingAckHandled() stops
decrementing mPendingCompositionCount when it receives eCompositionCommit(AsIs)
events which are ignored by the remote process.
This patch manages it with |mIsChildIgnoringCompositionEvents| and changes
|bool mIsPendingLastCommitEvent| to |uint8_t mPendingCommitCount| for
making ContentCache be able to manage multiple pending commit events if
its remote process is too busy.
MozReview-Commit-ID: CYQDeZXl7TJ
--HG--
extra : rebase_source : 6de1e2f1302d556d45d19c73b4d1ea3f86b65373
When ContentCacheInParent::RequestIMEToCommitComposition() returns true,
the remote process will synthesize eCompositionCommit event. This causes
destroying TextComposition event in the remote process (by
IMEStateManager::DispatchCompositionEvent()). Then,
IMEStateManager::DispatchCompositionEvent() will recreate new TextComposition
instance when it receives new composition event. Then, it may request
to commit composition to the main process via PuppetWidget accidentally.
So, after PuppetWidget::RequestIMEToCommitComposition() synthesizes
eCompositionCommit, PuppetWidget should discard following composition events
until it receives eCompositionStart since they are unnecessary for the content
and they are for the old composition, i.e., outdated events.
MozReview-Commit-ID: BNRcoYxABpd
--HG--
extra : rebase_source : caea469afeed8cc373aeca33199ac0d570052569
Remove NPZC references from LayerView, and add an NPZC getter in
LayerSession. Use the new APIs in GeckoView to forward events to NPZC.
MozReview-Commit-ID: 1UcJkpW0XuM
--HG--
extra : rebase_source : 6f50d1ca9398a2549678cc4e0fbb2578d284f63a
Clean up the NativePanZoomController object including,
1) Remove references to LayerView because NPZC will be created and used
by LayerSession.
2) Rename `mDestroyed` to `mAttached` because NPZC now needs to support
cases where it's used before being attached, in addition to after being
destroyed.
3) Move origin of synthesized event coordinates from the screen to the
surface in native code, so we don't need to do the same thing in Java.
4) Invoke all callbacks from native code on the UI thread.
MozReview-Commit-ID: Fu4XIY59yKw
--HG--
extra : rebase_source : cb4d432cb940cfa92f3c0a931f1f2d2991932462
There is some overscroll handling code in NativePanZoomController that
should be moved, along with other overscroll code in LayerView, to
LayerSession. LayerSession now provides a getter for
OverscrollEdgeEffect, which is cleaned up to have a public API with
documentation.
MozReview-Commit-ID: LkKHFS8OkR7
--HG--
extra : rebase_source : dc6b680b1cc7d7e2dd221091a63a208971d63c80
ContentCacheInParent::mPendingCommitLength is never initialized until it
receives eCompositionCommit(AsIs) event from widget or receives the latest
content from the remote process when there is a composition.
The bug is, immediately after dispatching eCompositionStart and first
eCompositionChange event, MS Pinyin tries to query the character at caret,
but ContentCacheInParent::HandleQueryContentEvent() tries to resolve
related position of an eQueryTextRect event with the uninitialized
mPendingCommitLength. Therefore, the query almost always fails and MS Pinyin
gives up to show its candidate window.
This patch just initializes the member with 0.
MozReview-Commit-ID: JyYNqi8hoTa
--HG--
extra : rebase_source : bdc504f83abdbb21e11ea69290908ed501e9a65f
For protecting main process, we should stop crashing main process in release
build even when we detect our bug. However, we should keep crashing with
MOZ_DIAGNOSTIC_ASSER which is enabled only on Night and Developer Edition.
MozReview-Commit-ID: 5BQ46IFzXXj
--HG--
extra : rebase_source : 1a894bb23b6b9f386b19eba95d14cd8db80fb2c6
Now, TextComposition::RequestToCommit() manages if it has already requested
IME to commit or cancel composition and this is important for redundant
requests. Therefore, ContentCacheInParent::RequestIMEToCommitComposition()
shouldn't call nsIWidget::NotifyIME() directly.
MozReview-Commit-ID: 69VpgyK9Jk5
--HG--
extra : rebase_source : 5b86c11669c7a69ceb0a2af155765834621ee968
According to the log in crash reports, eCompositionCommitRequestHandled is
sent to ContentCacheInParent twice or more for a composition. This causes
breaking mPendingCompositionCount and mPendingEventsNeedingAck management.
Currently, nsIWidget::NotifyIME() should be called only by
TextComposition::RequestToCommit(). Therefore, the method should manage if
it should request it actually. If the composition has already received
eCompositionCommit(AsIs) event, it shouldn't request it because parent process
may have already stated new composition and it shouldn't be broken by request
for old composition.
MozReview-Commit-ID: 2ekSa6EIeRP
--HG--
extra : rebase_source : d23aa29ce7871e83b99cec8c15aff0c580e08fb4
This is a simple bug of ContentCacheInParent. When
ContentCacheInParent::RequestIMEToCommitComposition() returns true,
PuppetWidget::RequestIMEToCommitComposition() will send
eCompositionCommitRequestHandled pseudo event message back to the main process.
This causes counting down mPendingEventsNeedingAck in
ContentCacheInParent::OnEventNeedingAckHandled(). Therefore, in the normal
path, ContentCacheInParent::OnCompositionEvent() increments it for receiving
the pseudo event message.
However, if the tab parent has already lost focus,
RequestIMEToCommitComposition() returns true without requesting native IME to
commit composition. So, ContentCacheInParent::OnCompositionEvent() cannot
increment mPendingEventsNeedingAck for coming
eCompositionCommitRequestHandled. Therefore, RequestIMEToCommitComposition()
needs to increment mPendingEventsNeedingAck by itself when it won't request
IME to commit composition but it returns true.
MozReview-Commit-ID: 4Alwfy8avB
--HG--
extra : rebase_source : 2588221568440beecc2b992910fa53729b8abe1c
The property in question is the offset from the content process to the
chrome process, but it gets called various things for historical
reasons. Let's be consistent and just call it the chrome offset
everywhere.
Also, in some places this was needlessly getting turned into a
nsIntPoint via ToUnknownPoint(), only to be turned back into a
LayoutDeviceIntPoint at all the use sites. So this patch also updates
some function signatures to avoid the needless conversion.
No functional changes.
MozReview-Commit-ID: AuhEUfa64Uj
--HG--
extra : rebase_source : 20e1895fefd944f98307a8437f977252ee2c3185
Use the LayerSession coordinates APIs instead of manually calculating
coordinates using viewport metrics and toolbar height, which is prone to
error.
MozReview-Commit-ID: 4ebI3BHEOXR
--HG--
extra : rebase_source : 264f03f3032f101687c2a39d1cf052ac1805f12b
Add getter/setter for DynamicToolbarAnimator in LayerSession in lieu of
LayerView. It is then LayerSession's responsibility to keep track of how
changes in the toolbar affects other things like the window and viewport
bounds.
MozReview-Commit-ID: HmRqxZ7EUCZ
--HG--
extra : rebase_source : 80648a17ed10672400daa4bcce0de49f4ee76557
One fix I forgot to make in bug 1416310 is to change the code to reset
the flag in LayerView. I think it's better if we just moved the whole
thing to native code, since we don't really use the flag in Java.
MozReview-Commit-ID: 9cbcYb89LhC
--HG--
extra : rebase_source : a209669d6657a60c198f59f4a0e4d959478485c3
Adding MATE as FLAT as it does not support the shadow borders around the window.
GDK_DECOR_BORDER decoration mode means that the window manager renders borders around the window.
We want the border rendering for CSD_SUPPORT_FULL only which means the border looks like shadows. We don't wand WM to render solid/bold borders around main toplevel window.
MozReview-Commit-ID: BdwHi0LJRGC
--HG--
extra : rebase_source : 7b7d6733e62ae3188fe6cdeecca17de05b3d6873
Remove GeckoLayerClient.java since it's no longer used, and update
auto-generated JNI bindings. r=me for trivial patch.
MozReview-Commit-ID: CiNPLLkh3VJ
--HG--
extra : rebase_source : 0cddae4f8914dd6f6a0631a7e69701828476f2b8
Use LayerSession::Compositor or NativePanZoomController to call back
into Java from nsWindow.
MozReview-Commit-ID: 9JUKAE5XQK1
--HG--
extra : rebase_source : 9d6861b9d641e6abb6b6f94f5f9c4b3661ff071c
Patch gets rid of `LayerView.getMatrixForLayerRectToViewRect`, and just
uses `LayerView.getZoomFactor` directly when calculating the matrix in
GeckoInputConnection. This also lets us avoid the `isCompositorReady`
call on a non-UI thread. To get the correct offset, we need the screen
bounds from Gecko, so it's passed to Java as the first element in the
rect array. Using bounds from Gecko lets us avoid having to deal with
things like the dynamic toolbar animator ourselves.
MozReview-Commit-ID: 6I61SZGyQyO
--HG--
extra : rebase_source : d576fb7ef9a42de10b14db662e5c4833f16f6312
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
The idea is the following:
Behind-window vibrancy is mostly rendered by the window server. For a given
vibrant region of a window, the window server renders a vibrancy "backdrop",
which is a blurred version of everything that's behind that region, modified
with a color tint and blended in some way. Then it puts our actual window
contents on top of that background.
The backdrop's shape is usually a rectangle. If we don't want it to be a
rectangle, we need to tell the window server about the shape that we want it to
be. We can't just "draw" a different shape in our own rendering, because our
own rendering is merely placed on top of the backdrop - but here we want to
modify the shape of the backdrop itself.
NSVisualEffectView lets us set a mask image on the view. If this view is the
content view of a window, then the view will automatically communicate the mask
image to the window server.
Traditionally, our popup windows have had a ChildView as their content view. If
we now want an NSVisualEffectView to be the content view of the window, then we
need to nest the ChildView inside that NSVisualEffectView.
But this NSVisualEffectView is only needed when the window is vibrant and the
vibrancy backdrop needs to have a certain shape. This is the case for our menus
which need to have rounded corners. If the window transitions to being
non-vibrant, or not needing a special shape, then we can go back to the way our
window's NSView hierarchy has worked traditionally. So we need to reparent
NSViews during those transitions.
MozReview-Commit-ID: Bo2VzjhhR0A
--HG--
extra : rebase_source : 9eb463cc68c16c3b9281b57455330969c5e2642c
The idea is the following:
Behind-window vibrancy is mostly rendered by the window server. For a given
vibrant region of a window, the window server renders a vibrancy "backdrop",
which is a blurred version of everything that's behind that region, modified
with a color tint and blended in some way. Then it puts our actual window
contents on top of that background.
The backdrop's shape is usually a rectangle. If we don't want it to be a
rectangle, we need to tell the window server about the shape that we want it to
be. We can't just "draw" a different shape in our own rendering, because our
own rendering is merely placed on top of the backdrop - but here we want to
modify the shape of the backdrop itself.
NSVisualEffectView lets us set a mask image on the view. If this view is the
content view of a window, then the view will automatically communicate the mask
image to the window server.
Traditionally, our popup windows have had a ChildView as their content view. If
we now want an NSVisualEffectView to be the content view of the window, then we
need to nest the ChildView inside that NSVisualEffectView.
But this NSVisualEffectView is only needed when the window is vibrant and the
vibrancy backdrop needs to have a certain shape. This is the case for our menus
which need to have rounded corners. If the window transitions to being
non-vibrant, or not needing a special shape, then we can go back to the way our
window's NSView hierarchy has worked traditionally. So we need to reparent
NSViews during those transitions.
MozReview-Commit-ID: Bo2VzjhhR0A
--HG--
extra : rebase_source : 0434a17e2cddc94715db6a5fd17bc27e2cddd05c
This is a regression by bug 1403690. After landing this, some xpcshell tests
cause crash with stylo.
mozilla::java::GeckoAppShell::GetShowPasswordSetting doesn't work on xpcshell
test. If JNI isn't available such as xpcshell, we shouldn't use this method.
MozReview-Commit-ID: AUrT93SkQ2H
--HG--
extra : rebase_source : 2147a42633ea98e3a4d891af832f28c105d5dcf8
