I'm changing this to be unconditional so that it may ride the trains.
If we later decide that we need to hold it back for another release, we can
revert this in Beta.
I'm talking to data people about analyzing Fenix's tab retention probes. I'll
obviously be keeping an eye on those numbers as this change propagates.
Differential Revision: https://phabricator.services.mozilla.com/D114404
HangData is the only member left in the union and SLOW_SCRIPT is the only member left in the enum.
This patch also migrates the one remaining (invalid) use of PLUGIN_HANG in testing to work as a SLOW_SCRIPT instead.
Differential Revision: https://phabricator.services.mozilla.com/D113885
Marionette enables itself only when --marionette is passed in. Given that
command line arguments can only be passed in using the debug configuration, it
is safe to send this event all the time.
Differential Revision: https://phabricator.services.mozilla.com/D113829
The latest version of GBoard seems to call `InputConnection.closeConnection`
without calling `InputConnection.endBatchEdit`. Since we recycle
`InputConnection` object, we have to reset batch edit count on
`closeConnection`.
Also there is no way to write GV-junit and mochitests because we cannot check
whether current text transaction is batch mode or not.
Differential Revision: https://phabricator.services.mozilla.com/D113297
Marionette uses GVE and sometimes closes the last tab and calls |Quit| at the
same time. When the last tab is closed, GVE will try to open a new tab with the
same content in it, to avoid leaving the browser in the "zero tabs" state. This
causes a race condition where the browser is shutting down and a new tab is
being created, which trips an assertion in our widget code.
During real life usage of the browser, calling Quit only happens during errors.
Because of that, and the fact that we're not seing this crash in the wild,
it should be safe to just fix the problem in GVE instead of supporting this
edge case in GeckoView.
To support the Marionette case, we allow GVE to stay at zero tabs. Some menu
elements need to be disabled (like reload tab and the url bar).
This has the added benefit of being able to test the "no windows" case in GVE
which wasn't possible until now.
Differential Revision: https://phabricator.services.mozilla.com/D113202
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
This reverts commit e542e8826b92f70dbabaf577d80a32273c684d1b.
In hindsight, this was a pretty bad change. It introduces a third place where
the EventDispatcher can be shutdown (JavaScript) and doesn't do a good job at
communicating this across all consumers.
I introduced this change in Bug 1567341 to fix some leaks in xpcshell tests at
xpcom shutdown, and it was never meant to affect a normal browser use (turns
out, it does).
I ran the tests again in try and they are still green when reverting this
change, I suspect that the actual failures I was seeing were due to a separate
leak that I fixed while developing the patches.
Differential Revision: https://phabricator.services.mozilla.com/D112637
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
The default setting for the number of COOP+COEP processes is 1, which I believe
is causing various test failures. While this is not the final configuration,
I'd like to use this value (total content processes - number of e10s web content
processes) to test this out.
Differential Revision: https://phabricator.services.mozilla.com/D111729
deleteSurroundingText may create multiple text transactions. This test
failure occurs when multiple text transactions are dispatched to Gecko.
GeckoEditableSupport records text changes by Gecko then it notifies Java
of text changes. And it merges old text changes with new text changes by
AddIMETextChange to reduce JNI/Binder calls if possible.
This issue is that AddIMETextChange creates incorrect text change range
by merging text change ranges.
Actually, TextChangeData already has merge function now, so we should use it
instead of own merge function in GeckoEditableSupport.
Differential Revision: https://phabricator.services.mozilla.com/D111207
Now that we can report long URI errors to the app using `NavigationDelegate`,
I have updated the tests accordingly.
I also added a test to ensure that long `data:` URIs are still accepted when we
are not dealing with a toplevel document. We generate a PNG image filled with
randomness, which compresses poorly (and thus is "large") and yet is a valid PNG
file. We expect its `onload` event to fire.
Differential Revision: https://phabricator.services.mozilla.com/D109429
While I evaluated multiple approaches to this problem, I selected two:
The first is to handle the case in `GeckoSession.load` directly from within
Java, as this allows us to avoid a Java to Native string conversion, as well as
giving us better opportunities to report the exact nature of the failure back to
the embedding app.
We add a new error code specifically for this case.
In the case where no `NavigationDelegate` is registered, I used
`GeckoSession.load` throwing an exception as a crude way of notifying the app.
In the case where the load request originates from within web content, we deny
the request from within `nsWindow` to avoid requiring any conversion of the
URI spec from native into Java.
Differential Revision: https://phabricator.services.mozilla.com/D109427
