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
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
C5038 is a new warning in VS2017, similar to gcc and clang's -Wreorder, which is enabled by -Wall. We should enable C5038 so Windows developers can see these warnings locally instead of when gcc and clang fail with warnings-as-errors on Try.
https://blogs.msdn.microsoft.com/vcblog/2017/07/21/diagnostic-improvements-in-vs2017-15-3-0/
We need to suppress C5038 warnings from Windows Runtime Library header files (wrl.h) included in ANGLE and widget/windows:
z:\build\build\src\vs2017_15.4.2\SDK\Include\10.0.15063.0\winrt\wrl\wrappers\corewrappers.h(515): error C5038: data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::sync_' will be initialized after data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::status_'
...
And suppress C5038 warnings in upstream webrtc code:
media/webrtc/trunk/webrtc/modules/video_capture/windows/BaseFilter.cpp(176): error C5038: data member 'mozilla::media::BaseFilter::mClsId' will be initialized after data member 'mozilla::media::BaseFilter::mState'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(169): error C5038: data member 'mozilla::media::BasePin::mFilter' will be initialized after data member 'mozilla::media::BasePin::mLock'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(170): error C5038: data member 'mozilla::media::BasePin::mLock' will be initialized after data member 'mozilla::media::BasePin::mName'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(172): error C5038: data member 'mozilla::media::BasePin::mDirection' will be initialized after data member 'mozilla::media::BasePin::mQualitySink'
MozReview-Commit-ID: BMDVkvQXNoq
--HG--
extra : rebase_source : 0d5ede9530d0d0750b8fffdc1cdfdc646ec8f22a
Add a `screenOriginChanged` callback to GeckoDisplay.Listener, which
informs Gecko of changes in the origin of the display. The origin
translates to coordinates for web APIs like screenX/screenY and certain
other calculations.
Also, make GeckoDisplay listen to layout changes in the view tree (by
overriding gatherTransparentRegion as an optimization), and call
`screenOriginChanged` accordingly.
MozReview-Commit-ID: C72EHCkbV3T
--HG--
extra : rebase_source : 240c5c8fb3c2938ae966f40e86f7c5a0ca66526c
Make GeckoSession inherit from LayerSession, and connect its Compositor
to native code as part of the GeckoSession routine.
MozReview-Commit-ID: wQaH1A0a7z
--HG--
extra : rebase_source : ee4ae96e974d15c8cb9ad569ea9abf0ace4d0fa5
Make native code use LayerSession::Compositor instead of
LayerView::Compositor. Also, make some callbacks happen on the UI thread
to make the Java code cleaner.
MozReview-Commit-ID: KhuHel7Zfdn
--HG--
extra : rebase_source : 040442539fd7cc1af8e13e4be1d9ebfb1625f778
We don't actually use the screen size through GeckoLayerClient anymore.
Getting rid of it lets us get rid of the Context field in
GeckoLayerClient as well.
MozReview-Commit-ID: GM1jlhAZm4T
--HG--
extra : rebase_source : 04827eb61d6304d4782a7a935d5528013255726f
Extracts out the creation of an NSEvent from a WidgetKeyEvent in
TextInputHandler.mm into generic helper method. The helper is used by headless
to create a fake NSEvent to then build edit commands from key events.
Fixes:
- test_selectevents.html
- test_bug756984.html
- test_movement_by_characters.html
- test_movement_by_words.html
- test_backspace_vs.html
- test_bug1094000.html
- ... many key event tests
MozReview-Commit-ID: 1Jur5MHOrkp
--HG--
extra : rebase_source : fbe320aff8fd2e1b36f3b46e02336e9fc89c48d0
Add BrowserLocaleManager.refreshLocales, a native function which calls OSPreferences::Refresh, and BrowserLocaleManager.getLocale, which returns the current locale string. Use these in place of observing modification of the intl.locale.os pref.
The core of this change is in gfxContext.*:
- change gfxContext::CurrentMatrix() and gfxContext::SetMatrix() to
return and take a Matrix respectively, instead of converting to
and from a gfxMatrix (which uses doubles). These functions therefore
will now match the native representation of the transform in gfxContext.
- add two new functions CurrentMatrixDouble() and SetMatrixDouble() that
do what the old CurrentMatrix() and SetMatrix() used to do, i.e.
convert between the float matrix and the double matrix.
The rest of the change is just updating the call sites to avoid round-
tripping between floats and doubles where possible. Call sites that are
hard to fix are migrated to the new XXXDouble functions which preserves
the existing behaviour.
MozReview-Commit-ID: 5sbBpLUus3U
Create nsRemoteClient pointer as a base class pointer to X11/DBus implementations.
MozReview-Commit-ID: 3CpkDey6rLU
--HG--
extra : rebase_source : f7f6fd7e179e23d4bfabe528092710bcbe9a1892
I add some resolution icons for HiDPI by bug 1415014. So we should detect
these resolution icons. Also, Thunderbird has default256.png, so we should
support it, too.
MozReview-Commit-ID: 6BEgV0usnE2
--HG--
extra : rebase_source : ec1b954e1ee4664f365376202fe6f9158c6a9e3b
Original patch author is Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: Jnqz35iNsQb
--HG--
extra : rebase_source : b3be56afc3330a98a981af0d8b85a28164953e1c
Fix a bug where GeckoView becomes unresponsive to dispatched events
after restoring states, due to the native queue not being restored.
r=me for small, tested patch.
MozReview-Commit-ID: K1cVjjNaZK1
--HG--
extra : rebase_source : b1329c84d82f5bdc06767bf310ca87e52ff6ec9b
Rename GeckoView to GeckoSession. Strip out parts of it that depended on
being a subclass of View. Also strip out parts of it that dealt with
switching EventDispatcher and NativeQueue, because now there's only one
copy of each for each GeckoSession.
MozReview-Commit-ID: J699twtpmTS
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoView.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoSession.java
extra : rebase_source : 60e045f6f1e6a70dcabc03f5a32cae5576c2edd8
Right now, `GeckoView.Window.open()` consists of opening a new Gecko
nsWindow and attaching it to the opening GeckoView. This patch separates
the attaching step into an `Window.attach()` function that was renamed
from `Window.reattach()`. Going forward, `Window.open()` and
`Window.close()` will correspond to opening and closing a session, which
`Window.attach()` will correspond to attaching a display to a session.
MozReview-Commit-ID: 94Un74pwizY
--HG--
extra : rebase_source : a7d9c6c3227de4b05e800d77a184f1deae9af5f8
This will be re-landed with a real fix for print-selection after we branch for 58.
MozReview-Commit-ID: JjhBEiEviVB
--HG--
extra : rebase_source : 15b9a2eccdc5ce001bacb776e15f98f4d368c436
Basically, widget code shouldn't access API in dom/events as far as possible
since it's difficult to care widget code when other developers to change under
dom/.
This patch backouts the patch for bug 1402461 which made GeckoEditableSupport
depend on EventStateManager in dom/events. Now, necessary information is in
InputContextAction and same condition should be shared with Windows.
MozReview-Commit-ID: LMlrizswxUj
--HG--
extra : rebase_source : c13604eac143ec5994c65571bff09887d5c0c221
Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB. For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.
Therefore, InputContextAction should declare two causes. One is unknown but
occurred during handling non-keyboard event. The other is unknown but occurred
during handling keyboard event.
However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event. Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling. Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.
IMEStateManager uses this new API to adjust the cause of changes of input
context.
Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.
MozReview-Commit-ID: 5JsLqdqeGah
--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=747634
Before 3.16.3, GDK cannot override classname by --class command line option
when program uses gdk_set_program_class(). So if 3.16.3+, we should call
gdk_set_program_class() to set program class name of default.
MozReview-Commit-ID: KvNc3U6xHr7
--HG--
extra : rebase_source : aae14973022bb29eb89787b67323a845763c0650
In the future, GeckoAppShell will only be part of the service process
library, and will not be part of the app process library. Therefore, we
should minimize GeckoAppShell usage in any GeckoView code that will
likely end up in the app process library.
In particular, AndroidGamepadManager and Clipboard are made to accept
Context as arguments, instead of using
GeckoAppShell.getApplicationContext() for getting the Context.
MozReview-Commit-ID: G9SC815H5Ku
Remove the native GeckoView loadUri call because it's Fennec-only.
Replace the call with a Fennec-only "Tab:OpenUri" event.
MozReview-Commit-ID: 7xZW9aceoPL
Removing the previous cpp files moved AndroidBridge.cpp to a different
compilation unit, and that caused some problems with other code that
depended on AndroidBridge being in or not in their compilation unit.
This patch fixes those (unwanted) dependencies.
MozReview-Commit-ID: DJsk3iENsx2
Remove AndroidJavaWrappers. Convert nsJNIString usages to use
jni::String and AndroidMotionEvent usages to use java::sdk::MotionEvent.
Move key code constants to GeckoEditableSupport.cpp.
MozReview-Commit-ID: CwcGGADWCNv
Remove AndroidJNIWrapper. It was primarily used by JNI.jsm and WebRTC.
Usages in WebRTC are replaced with equivalent uses of JNI templates.
MozReview-Commit-ID: DPSeMOtH2wF
We assume CLOCK_MONOTONIC as timebase for events on Wayland and use that to translates GDK event times to gecko timestamps.
MozReview-Commit-ID: LWd2KWTQeha
--HG--
extra : rebase_source : 1839d35989b9c29c60dd33d445db79afc75af9ab
Create ConstructCommandLine() to be shared between X11 and DBus implementation.
MozReview-Commit-ID: CJIe7B7DWwo
--HG--
extra : rebase_source : b42df1cca45e03b7e826b83f532829f6d8bd6e89
Rename shellHasCSD to drawToContainer for better understanding and always mark our rendering widget by gtk_widget_set_app_paintable() to make sure Gtk+ does not draw default background for it.
MozReview-Commit-ID: 4mhxrG7C34i
--HG--
extra : rebase_source : 312e956e317c85196d27213dd86bd30b73a25b02
For X11 only builds get display from DISPLAY env variable or from command line argument. For Wayland enabled buils use standard gdk_display_manager_open_display() path which respects GDK_BACKEND.
When command line argument --display is given pass it to child process by MOZ_GDK_DISPLAY env variable.
MozReview-Commit-ID: F9jEaJ9SU1p
--HG--
extra : rebase_source : 31cf96bcdfe5c525625aa3742aa74ec674265fe1
We can use kPMDataFormatXMLCompressed parameter when storing the page format
data. As result, this preference data will be 20 times smaller.
MozReview-Commit-ID: HMQzhodQyA
--HG--
extra : rebase_source : 941a30cb346b6c15f5a02f527063a437ae0c6121
As per the TODO, a size change on an image is supported now, so there should be
no need to delete and re-create the image key when the window overlay image
changes size. And since the cleanup function is not invoked from anywhere else
it can also be removed.
MozReview-Commit-ID: JSmK5YmXjlX
--HG--
extra : rebase_source : 0078ccfed9a381c82bcb906a87bdf58d8e9c78e1
The window buttons are drawn as part of the AddWindowOverlayWebRenderCommands
function which is invoked in the full-transaction codepath. It should be possible
to have the empty transaction codepath simply update the image (without building
a full WR display list) and do a recomposite. That would be more performant but
it requires some plumbing to build and ship across a IpcResourceUpdateQueue on
empty transactions.
MozReview-Commit-ID: 2Mrb0wELD6E
--HG--
extra : rebase_source : 9a94c32f94403050835bf3445176f4fe2c1579fa
Make CSD setup and titlebar drawing available when users enable it by preference and also it's available on running system.
MozReview-Commit-ID: 4BLgzVWwX1R
--HG--
extra : rebase_source : 15293821b9962bd9d0ee22331e7fad9027a47a7a
clang complains if we don't have a declaration for Context::sClassRef;
Accessors.h had one, but it's not in the right place to prevent clang
from complaining. Moving it closer to where Context itself is declared
seems like a reasonable thing to do.
ATOK started to be TIP of TSF since 2011. Older than it, i.e., ATOK 2010 and
earlier have a lot of problems even for daily use. Perhaps, the reason is
Win 8 has a lot of changes around IMM-IME support and TSF, and ATOK 2010 is
released earlier than Win 8.
ATOK 2006 crashes while converting a word with candidate window.
ATOK 2007 doesn't paint and resize suggest window and candidate window
correctly (showing white window or too big window).
ATOK 2008 and ATOK 2009 crash when user just opens their open state.
ATOK 2010 isn't installable newly on Win 7 or later, but we have a lot of
crash reports.
Note that ATOK 2006 is the first version supporting Win XP x64. So, ATOK 2005
must not support x64 apps.
Unfortunately, we cannot block loading DLLs of them. Therefore, IMEHandler
should disassociate IMC from active window when user changes active keyboard
layout to the legacy ATOK and not associate IME with any window when
SetInputContext() is called even with "enabled". Additionally, when user
changes active keyboard layout from the legacy ATOK to one of the other
keyboard layouts, IMEHandler should associate IMC with current window for
new active IME.
MozReview-Commit-ID: RVYwmYxzO7
--HG--
extra : rebase_source : c237a3aca6ceb6a1f7251bd9421e4b905be5bc6c
Some odd touchpad utils give focus to window under mouse cursor when user tries
to scroll the content with swiping or something.
This is really odd behavior because some windows like popup windows doesn't
want focus. However, such ones do actually. For making easier to check such
device's behavior, we should have a pref to emulate such behavior.
MozReview-Commit-ID: 6euwpHn7blf
--HG--
extra : rebase_source : cc23f08f422f25f2851404696e06e069c7936186
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
Most cases where the pointer is stored into an already-declared variable can
trivially be changed to MakeNotNull<T*>, as the NotNull raw pointer will end
up in a smart pointer.
In RAII cases, the target type can be specified (e.g.:
`MakeNotNull<RefPtr<imgFrame>>)`), in which case the variable type may just be
`auto`, similar to the common use of MakeUnique.
Except when the target type is a base pointer, in which case it must be
specified in the declaration.
MozReview-Commit-ID: BYaSsvMhiDi
--HG--
extra : rebase_source : 8fe6f2aeaff5f515b7af2276c439004fa3a1f3ab
The two happening at the same time can lead to the APZ autoscroll being
cancelled due to APZ receiving a main-thread scroll offset update.
To achieve this:
- The content process assumes APZ is handling the autoscroll until
told otherwise.
- If the parent process knows APZ won't handle an autoscroll, it
tells the content process via its response to the Autoscroll:Start
message. This covers all cases where APZ doesn't handle the
autoscroll, except the case where APZCTreeManager itself rejects
the autoscroll and it lives in the compositor process rather than
the parent process.
- If APZCTreeManager rejects an autoscroll and it lives in the
compositor process, it sends an 'autoscroll-rejected-by-apz' message
to the content process.
MozReview-Commit-ID: L62v4COai6W
--HG--
extra : rebase_source : bc4c6417e77461634263defb88e67ed5036c454e
This patch will
* Move native print dialog code to the PrintDialogService of widget.
* Toolkit call PrintDialogService instead of calling the native print dialog.
* Change SetWindowText/CreateWindow to SetWindowTextW/CreateWindowW
in order to treat localized string correctly.
MozReview-Commit-ID: DOgp3STaJ4t
--HG--
rename : toolkit/components/printingui/win/nsPrintDialogUtil.cpp => widget/windows/nsPrintDialogUtil.cpp
rename : toolkit/components/printingui/win/nsPrintDialogUtil.h => widget/windows/nsPrintDialogUtil.h
extra : rebase_source : 9b428f528156a70f5a127b1eeec60f6f593387a0
In order to move print native dialog code to windows widget, this patch will
create skeleton of PrintDialogService to windows widget.
Toolkit code(i.e. nsIPrintingPrompotService) will call this PrintDialogService.
Note that this PrintingDialogService suppose running on main process, so we
should call this interface from main process(i.e. nsPrintingPromptService, not
nsPrintingProxy).
MozReview-Commit-ID: 3P6kac9I9W4
--HG--
extra : rebase_source : 5b5ecd104cf4cecd1b68a3d6d4b33aca9fea9548
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: DTVePe1R563
--HG--
extra : rebase_source : 23bea31b34ed95301f840726a1f70378764fdea4
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 2d8BgLyOS5u
--HG--
extra : rebase_source : ff4aa230b22a3ae478211330b09f239f36705e12
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 18U3GBrTyVW
--HG--
extra : rebase_source : 7a203d5c4d1856d24f08c2ea42ad4519d283ab73
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: HzzXDqE0s5n
--HG--
extra : rebase_source : d929e03d7ab84229101b9c11cdb35396547860e4
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: GA3CDhCeqfD
--HG--
extra : rebase_source : 0bdccafcfbd84475442503abb6b2e11b6670c37d
Our minimum requirement is api-16+ and ICS or later's default font is Roboto. But nsLookAndFeel::GetFontImpl still returns Droid Sans. We should return Roboto.
MozReview-Commit-ID: 5VNzQXXp4fa
--HG--
extra : rebase_source : b045c1580faa3204f26d3aa0be89700f2b1abb57
In the GTK < 3.20 the size of radio and checkbox toggle is determined by indicator
spacing and indicator size. By GTK 3.20+ it is replaced by standard box model
(padding, margin, border). The patch fixes that while keeping the functionality
for older GTK. The values are also cached by similar way as scrollbar metrics
are cached now.
The focus is no longer rendered by GTK but by Mozilla code, so the extra
size for toggles has been removed from GetExtraSizeForWidget and toggles
no longer render focus indicator.
MozReview-Commit-ID: 1Wg5AgHy1Vz
--HG--
extra : rebase_source : 81437f45b7d32555942d21fccc9de4a561d85111
The functions changed are given signed arguments (that are converted to unsigned).
Changing them to signed resolves the warnings and preserves the original values.
MozReview-Commit-ID: BxIAECFiuQR
--HG--
extra : rebase_source : c48cef46f3ad5a060ad1f33d1c97744bfa8a82d7
inline functions are supposed to be declared in the header file, so the compiler can inline them.
gcc complains about this, but clang/msvc apparently do not.
We also needed to move the DeadKey struct and class into the header, as the function calls a
method on the DeadKey class, and you can't do that on a forward declared class.
MozReview-Commit-ID: 8NxP59AXuZi
--HG--
extra : rebase_source : 9fd74d2c571bdeb4244cb63baf508946a2f19aa6
This is a follow up patch of bug 1408086. The previous patch starts to append
log of 2 sets of composition events to app notes of crash report when
ContentCacheInParent::OnEventNeedingAckHandled() meets unexpected state and
crash itself. However, now, we know the unexpected state occurs when TabParent
receives eCompositionCommitRequestHandled message from its remote process.
The event comes when ContentCacheInParent::RequestIMEToCommitComposition()
returns true. So, we need to know what occurs in the method before the crash.
This patch defines each case of RequestIMEToCommitComposition() with an enum
class, RequestIMEToCommitCompositionResult and make
RequestIMEToCommitComposition() append one of its value to the array.
Then, ContentCacheInParent discards unnecessary log of this when it discards
log of old composition events. Finally, appends the log to the app notes of
crash report.
MozReview-Commit-ID: 9sJyl4SvUXu
--HG--
extra : rebase_source : f7e90a157d3819523d3d8932d9f8af5d94e2db1f
The intention of these macros here is merely to log a warning and enable
a developer to notice the inconsistency. Pass the result to Unused.
MozReview-Commit-ID: 9IOuwQ3InVm
--HG--
extra : rebase_source : 83f265a5e042dee0c2ad66d45b67906f1b0422aa
This patch declares a new default action, "horizontal scroll", this scrolls
content horizontally with deltaY of wheel events and ignores deltaX and deltaZ.
This is used for default action with Shift key in default setting except on
macOS. On macOS, legacy mouse's vertical wheel operation with Shift key causes
native horizontal wheel event. Therefore, we don't need to use this new
default action on macOS. Additionally, old default action with Shift key,
navigating history, is moved to with Alt key. This makes same settings between
macOS and the others. So, this is better for users who use macOS and another
OS and web app developers who check wheel events only on macOS or other
platform(s).
For simpler implementation, default action handlers moves deltaY values to
deltaX values temporarily *only* while they handle wheel events. This is
performed by AutoWheelDeltaAdjuster and restored after handling it
automatically.
So, in other words, even if default action is "horizontal scroll", web apps
receives wheel events whose deltaY is not zero but its content will be
scrolled horizontally. This is same as Chromium, so, this behavior shouldn't
cause any incompatible behavior with it.
MozReview-Commit-ID: E4X3yZzLEAl
--HG--
extra : rebase_source : e20d854c6b0a181ad4c9e7304bd9ad14256481ff
Fixes problem with the initial computed value of font-family
being empty and not matching the later value in
test_value_storage.html.
MozReview-Commit-ID: HOHvMZPP1GD
Many tests rely on the minimum size of widgets to
be set. Also, the precise size seems to matter for some
tests that have hard coded offsets.
MozReview-Commit-ID: BglZD1cKdY9
This better emulates a window manager and triggers the
required activated/deactivated events on the proper windows as
they are closed or hidden.
MozReview-Commit-ID: 1A2JTp8i4VE
Push pointer event pref before testing test_assign_event_data.html and remove redundant assertions since the pushed pref will be restore after testing.
MozReview-Commit-ID: 22nTMLGoMFj
Gecko set job using by PMPrintSettingsSetJobName regardless of job name length.
But IPP allow job-name length up to 255 bytes. (RFC 2911, Section 4.3.1)
This patch will shorten print job name. It is workaround until fixed the
Core Printing[1].
[1] https://openradar.appspot.com/34428043
MozReview-Commit-ID: 6nCwZuD43O9
--HG--
extra : rebase_source : c9c3830890f1f4d84e148fbe281589c23e7803d2
Since GTK 3.18.2, GTK allows setting job name with more than 255 bytes.
As result, CUPS received the IPP error. (RFC 2911, Section 4.3.1)
This patch will shorten print job name, if runtime GTK version is older than 3.18.2.
MozReview-Commit-ID: EfB87Bvo6hX
--HG--
extra : rebase_source : a070e99c783c471a7bf7d00efb3cc997ff617a5e
This avoids a lot of mismatches between nsAString and char16_t*, thus removing
many getter_Copies() and ToNewUnicode() and get() calls, and generally making
things simpler.
Note: the patch removes GetDefaultPrinterNameFromGlobalPrinters() by simply
inlining it at its two callsites, which is easy with the changed types.
--HG--
extra : rebase_source : 9ab9b3694f093fc9b22c7f8e2394a98674d76c11
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : e7e0a3f83001813239338bc5b3895252e1fb3ea6
We have a lot of crash reports in OnEventNeedingAckHandled() due to unexpected
state (hit MOZ_RELEASE_ASSERT). However, it's unclear what occurs and we're not
sure there are how many cases to crash because the stack trace is too short
because the method is called when TabParent receives event handled message from
the remote process. I.e., it doesn't show what happens immediately before the
crash.
This patch puts 2 sets of composition events to app notes of crash report when
it needs to crash. This *might* make damage to the performance. If so, after
fixing the crashes, we should back this out. Fortunately, we have a lot of
reports from either Nightly or Beta.
MozReview-Commit-ID: 9tDrEIf72MG
--HG--
extra : rebase_source : 523c183466740e08d6c8cc3836b6b52310c1e53a
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67