We register the nsIWebProgressListener at the root docshell(GetSameTypeRootTreeItem) to handle video element embedded in iframe.
MozReview-Commit-ID: D4CavLDAnKD
--HG--
extra : rebase_source : 93032297272bbfc8570dce0c8c13ea9f0d45f7a8
In geckoview_example multiprocess mode, preload child process during
startup to make e10s startup faster.
MozReview-Commit-ID: GinwBZlrnps
--HG--
extra : rebase_source : a43ef4708d311c9a100aafba0c84ee4a2e27090b
We need to wait for GeckoThread to load the Gecko libs in the main
process before we can launch any child processes, so that the child
process doesn't try to extract libs, which can conflict with any
extraction going on in the main process.
MozReview-Commit-ID: 2gUd2R1TUBI
--HG--
extra : rebase_source : d48b9e2e744669a89f2b761cf6936f28948c17c3
Avoid going through GeckoAppShell and move the start child process JNI
call directly to GeckoProcessManager.
MozReview-Commit-ID: KU62TiHVQJX
--HG--
extra : rebase_source : 0e8546da502257e1c59bc00b79f50c79a314f3e6
Refactor the code in GeckoProcessManager and GeckoServiceChildProcess so
that, we can have a ChildConnection object that's bound but not started.
This way we can bind the connection to preload Gecko child process, but
hold off starting until told by Gecko main process.
Some code is simplified. For example, `IChildProcess.stop` is removed in
favor of killing the child process directly.
MozReview-Commit-ID: 4XgmTuT0IAs
--HG--
extra : rebase_source : 94fe748556c66f639d1f8e5bb26c28ea3ed950b3
Normally when we interpolate values for CSS properties we convert empty values
(such as the empty "from" value created for a by-animation) to a suitable zero
value. However, when we use discrete interpolation that step never occurs and in
some rare cases that means we end up setting the empty value on the target
attribute directly which will have an incorrect result (e.g. setting "" for the
height property will have no effect, whereas setting "0px" will).
This patch makes us perform the empty value to zero value conversion when
performing discrete animation.
Unfortunately it is not possible to test this behavior with shorthands since
there are currently no shorthand properties that are additive.
MozReview-Commit-ID: JFT1tis1RAR
--HG--
extra : rebase_source : cc444b6d4d5571c8ab231d88c4d349ea0713baaa
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
The difference between GetXULRunnerStubPath and XRE_GetBinaryPath was
removed in bug 552864.
--HG--
extra : rebase_source : 20060486de82c04bc888fade5be1f42675bc5d07
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 32f5080ecb8165cffd601799e72d278b482b0871
There's an intermittent which might be spurious because ASN.1 signatures might
sometimes be less than 70 bytes, but the actual floor is probably 68 (32 + 32
+ 4).
It's a sanity check, so I've adjusted it down and also am now emitting the
offending key bytes if this triggers again.
MozReview-Commit-ID: 1wwU9Q3BUPF
--HG--
extra : rebase_source : 2877deb770f8bf4bcf31dae40f75016892dc9d53
This replaces MOZ_MTLOG with CSFLog, which is already set up to handle having
a shared LazyLogModule used from difference source files.
MozReview-Commit-ID: KNUKL92aWcw
--HG--
extra : rebase_source : 6d9eb3421c364f941c4cdf6d40217d2b853faacb
This removes the duplicate definition of logTag and fixes a preprocessor related
unified build error.
MozReview-Commit-ID: LP5frg0QZul
--HG--
extra : rebase_source : 64f2d77816c8d3681a7cf795317e8bdcb73c6713
I want to be able to configure the resource path via `set_resources_path`.
Source-Repo: https://github.com/servo/servo
Source-Revision: b1c2d7195dd01a131c10d2bc2ad457a51c3fa118
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c23fb710a0acc994fc4f02ea58bce46393dde018
Although, Firefox for Android doesn't use urlbarBindings.xml for declaring its
awesome bar, for consistency with widget code for desktop OSes,
GeckoInputConnection should treat "mozAwesomebar" inputmode value as "url"
since Android doesn't have any special input type for "search" and we should
keep current behavior.
MozReview-Commit-ID: DpUnUx4E2Sp
When "mozAwesomebar" is set to inputmode value, that means that the Smart
Location Bar gets focus. In that case, we should notify IME of input scopes
as "URL" because on-screen keyboard for URL has some useful additional keys
but they are not hindrances even when users want to type non-URL text.
On the other hand, MS-IME for Japanese and Google Japanese Input changes their
open state to "closed" if we notify them of URL input scope. A lot of users
complain about this behavior. Therefore, we should notify only them of
"Default" input scope even when "mozAwesomebar" has focus.
MozReview-Commit-ID: DIgqpR7TXQx
Smart Location Bar (a.k.a URL bar) has some features, loading inputted URL
directly, searching bookmark items and history items, and search inputted words
with registered search engine.
So, it does not make sense its inputmode is "url". E.g., neither showing URL
specific software keyboard nor switching IME open state automatically for
typing URL may not be expected in most cases.
Unfortunately, there is no proper inputmode value for Smart Location Bar.
Therefore, this patch uses "mozAwesomebar" value and accepts the value only in
chrome documents. This value should be handled by each native IME handler
properly.
MozReview-Commit-ID: 7vUnbpg91F2
