This patch takes the approach of taking a reference, so that we can land
it into the tree more quickly & fix issues we have.
This isn't a final solution by any means, we should also do something
along the lines of the StableState approach, but it should be sufficient
for now.
Depends on D19177
Differential Revision: https://phabricator.services.mozilla.com/D19178
--HG--
extra : moz-landing-system : lando
This bit of code annoyingly runs before we know whether we really need an
emulator or not, so the error blocks testing even with a real device.
Differential Revision: https://phabricator.services.mozilla.com/D19700
--HG--
extra : moz-landing-system : lando
Modifying the manual font size settings while the GeckoFontScaleListener is
active is theoretically possible, but probably not the most sensible way of
using that API. Therefore, we prohibit it and throw an exception in that case.
There is one complication, though: The very same API is used by the font scale
listener itself in order to modify the font size settings according to the
system font scale. Therefore, we have to move the GeckoFontScaleListener into
the GeckoView package itself, so that we can provide a package-private internal
API that bypasses the above usage checks.
This means that going forward, Fennec needs to use the official GeckoView API
to communicate with the font scale listener, too. As we've moved out the Shared-
Preferences watching in part 5, this doesn't pose any insurmountable
difficulties.
Because for a short while I encountered some strange crashes where getRuntime()
in GeckoApplication apparently returned null while trying to initialise the
listener, I'm tying its initialisation to creation of the runtime, just to be on
the safe side.
Differential Revision: https://phabricator.services.mozilla.com/D18507
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoFontScaleListener.java
extra : moz-landing-system : lando
Some callers might prefer to manually set the font size in analogy to WebView's
WebSettings.setTextZoom(), respectively allow their users to do so.
Subsequently, we're also going to switch the GeckoFontScaleListener to operate
on those settings.
Because the effects of font inflation are more difficult to quantify than a
plain text zoom, we just check that operating the runtime setting sets the
corresponding Gecko pref. Besides, there already are further platform (ref)tests
checking the actual operation of font inflation itself.
Differential Revision: https://phabricator.services.mozilla.com/D17749
--HG--
extra : moz-landing-system : lando
With the dependencies on Fennec's GeckoPreferences and GeckoSharedPrefs gone, we
can now move the class into GeckoView in preparation for hooking it up to the
GeckoViewRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D18506
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java
extra : moz-landing-system : lando
For easier testing in Fennec, we want to continue watching the respective
SharedPreferences key and toggle the listener in response to *that* instead of
directly wiring it into our Settings menu (GeckoPreferences), however because
that functionality is Fennec-specific, we move that logic out of the font scale
listener itself.
In conjunction with this, we also decouple the enabled state of the listener
from its attached state.
The enabled state can now be toggled at all times, but unless the listener is
also attached to a context, it simply won't have any practical effect.
Differential Revision: https://phabricator.services.mozilla.com/D17746
--HG--
extra : moz-landing-system : lando
In practice, everything in the GeckoFontScaleListener will run on the UI thread,
so get rid of the `synchronized` methods and just enforce the threading
assumptions in the public API.
Differential Revision: https://phabricator.services.mozilla.com/D18505
--HG--
extra : moz-landing-system : lando
Going forward, we want to be able to toggle the enabled state at all times, and
being able to do this before calling initialize() seems a bit inconsistent.
Hence, we rename it to the more neutral-sounding attachToContext().
Differential Revision: https://phabricator.services.mozilla.com/D17745
--HG--
extra : moz-landing-system : lando
The GeckoFontScaleListener is intended to live as long as the app (and there-
fore Gecko) remains alive and consequently keeps a reference to the
*application* context, so the linter warning can be safely suppressed.
Also reorder imports to match coding style.
Differential Revision: https://phabricator.services.mozilla.com/D17743
--HG--
extra : moz-landing-system : lando
The one exception is refcounted types, because std::move(RefPtr<T>) does not
coerce to T*, which is what the current IPC methods accept.
This does not rewrite all Recv/Answer methods to take advantage of move
semantics.
Differential Revision: https://phabricator.services.mozilla.com/D19669
--HG--
extra : moz-landing-system : lando
Modify the Debugger API implementation to ensure that debugger code's promise
activity (resolving promises; running reaction jobs) cannot interfere with the
debuggee's.
Specifically, ensure that there is an `AutoDebuggerJobQueueInterruption` in
scope at every site in the Debugger implementation that might invoke a debugger
hook function. This saves the debuggee's job queue, emplaces a fresh empty
queue, lets the hooks run, drains the queue, and then restores the debuggee's
original queue.
Since we must already mark sites that could invoke hooks with
`EnterDebuggeeNoExecute`, we ensure our job queue protection coverage is
complete statically by having `EnterDebuggeeNoExecute`'s constructor require a
reference to an `AutoDebuggerJobQueueInterruption`.
Differential Revision: https://phabricator.services.mozilla.com/D17547
--HG--
extra : moz-landing-system : lando
Define a new RAII class, AutoDebuggerJobQueueInterruption, to save and restore
the current ECMAScript job queue, to protect the debuggee's job queue from
activity that occurs in debugger callbacks. Add a new method to the JS::JobQueue
abstract base class, saveJobQueue, to support AutoDebuggerJobQueueInterruption.
Comments on AutoDebuggerJobQueueInterruption provide details.
Implement saveJobQueue for SpiderMonkey's internal job queue and for Gecko's job
queue in CycleCollectedJSContext.
Differential Revision: https://phabricator.services.mozilla.com/D17546
--HG--
extra : moz-landing-system : lando
While the behavior of ECMAScript Promises and their associated job queue is
covered by the ECMAScript standard, the HTML specification amends that with
additional behavior the web platform requires. To support this, SpiderMonkey
provides hooks the embedding can set to replace SpiderMonkey's queue with its
own implementation.
At present, these hooks are C-style function-pointer-and-void-pointer pairs,
which are awkward to handle and mistake-prone, as passing a function the wrong
void* is not a type error. Later patches in this series must add new hooks,
making a bad situation worse.
A C++ abstract base class is a well-typed alternative. This introduces a new
`JS::JobQueue` abstract class, and adapts SpiderMonkey's internal job queue and
Gecko's customization to use it. `GetIncumbentGlobalCallback` and
`EnqueuePromiseJobCallback` become virtual methods.
Within SpiderMonkey, the patch gathers the various fields of JSContext that
implement the internal queue into their own type, js::InternalJobQueue. Various
jsfriendapi functions become veneers for calls to methods specific to the
derived class. The InternalJobQueue type itself remains private to SpiderMonkey,
as it uses types like TraceableFifo, derived from Fifo, that are not part of
SpiderMonkey's public API.
Within Gecko, CycleCollectedJSContext acquires JS::JobQueue as a private base
class, and a few static methods are cleaned up nicely.
There are a few other hooks defined in js/public/Promise.h that might make sense
to turn into virtual methods on JobQueue. For example,
DispatchToEventLoopCallback, used for resolving promises of results from
off-main-thread tasks, is probably necessarily connected to the JobQueue
implementation in use, so it might not be sensible to set one without the other.
But it was left unchanged to reduce this patch's size.
Differential Revision: https://phabricator.services.mozilla.com/D17544
--HG--
extra : moz-landing-system : lando
This patch moves the channel pointer from the WebSocketEvents into the
classes that wrap them (EventTargetDispatcher and
WrappedWebSocketEvent) to fix leaks.
EventTargetDispatcher uses a weak pointer. This is needed to prevent a
leak if the ChannelEvent dispatch fails, because it would create a
cycle of strong references between the WebSocketEvent, the channel,
the channel event queue, and EventTargetDispatcher. It is safe because
the ChannelEventQueue ensures that the channel remains alive.
WrappedWebSocketEvent uses a strong pointer. This won't create a leak
because the runnable is not owned by the channel. It is needed for
safety because it can't rely on the ChannelEventQueue mechanism for
keeping the channel alive.
The WPT whitelisting moves them into two subdirectories that still
seem to leak sometimes, but the top level websockets/ directory seems
okay now.
Depends on D19586
Differential Revision: https://phabricator.services.mozilla.com/D19587
--HG--
extra : moz-landing-system : lando
In the next patch, I want to change the signature of Run(), so I need
to create a new base class for these inner WebSocket events.
For now, this class is the same as ChannelEvent, except that it does
not have the GetEventTarget method, which is never called.
Depends on D19585
Differential Revision: https://phabricator.services.mozilla.com/D19586
--HG--
extra : moz-landing-system : lando
Later patches change the WrappedChannelEvent ctor, so I'm removing
this unused method to avoid having to fix it up.
Differential Revision: https://phabricator.services.mozilla.com/D19585
--HG--
extra : moz-landing-system : lando
As we add more specific methods to RemotePageManager some of them will have to
call the main process to get the results. This adds a standard mechanism for
doing so. Calling sendRequest will return a promise that is resolved or rejected
when the main process responds.
Differential Revision: https://phabricator.services.mozilla.com/D19412
--HG--
extra : moz-landing-system : lando
Evaluation of debuggee code should always begin with an empty microtask queue.
In xpcshell tests, this is not guaranteed, as it is in the web platform. This
patch changes those devtools server xpcshell tests that break this rule in a
detectable way to run the debuggee code as a separate HTML task.
In an actual browser environment, debuggee JavaScript runs as an HTML task.
Since HTML requires a microtask checkpoint at the end of each task, this means
that a debuggee task begins execution with an empty microtask queue, free of
microtasks from other tabs or the browser machinery itself. Hence, while the
debugger is pausing debuggee code, it is safe for it to save the debuggee's
microtask queue, so that those jobs do not make progress. (Which is fortunate,
because it *must* do so, lest the debuggee's microtasks run during the pause!)
In an xpcshell test, however, there is no guarantee that debuggee code begins
execution with a fresh microtask queue: the test may call `eval` or
`evalInSandbox` at any time. If such an evaluation hits a breakpoint, `debugger`
statement, etc. that invokes a Debugger hook, supervisory microtasks from the
test harness code may be set aside along with the debuggee's microtasks. If the
hook code then blocks waiting for those microtasks to run, the test will hang.
Differential Revision: https://phabricator.services.mozilla.com/D18904
--HG--
extra : moz-landing-system : lando
This was added in bug 476393 in order to work around a problem with the Java plug-in.
We no longer support that plug-in.
The comment also mentions NSTexturedBackgroundWindowMask which we stopped using in bug 1335191.
Differential Revision: https://phabricator.services.mozilla.com/D19558
--HG--
extra : moz-landing-system : lando
This method could only return something non-null in embedding situations,
in which our ChildView was a subview of somebody else's NSView that conforms
to the mozView protocol. Such a situation hasn't existed for about 10 years.
Differential Revision: https://phabricator.services.mozilla.com/D19555
--HG--
extra : moz-landing-system : lando
As we add more specific methods to RemotePageManager some of them will have to
call the main process to get the results. This adds a standard mechanism for
doing so. Calling sendRequest will return a promise that is resolved or rejected
when the main process responds.
Differential Revision: https://phabricator.services.mozilla.com/D19412
--HG--
extra : moz-landing-system : lando
Currently we only check and remove the --allow-downgrade command line argument
if the run is actually a downgrade. When we don't the --allow-downgrade argument
makes it to Firefox's default command line handler which doesn't know how to
handle it and so ignores it and the next argument on the command line.
Flipping the ordering of the check makes sure we always remove the argument.
Differential Revision: https://phabricator.services.mozilla.com/D19569
--HG--
extra : moz-landing-system : lando
1. The unsetting of LD_LIBRARY_PATH is removed, because it's no longer
necessary and interferes with environments where it's necessary to find
"system" libraries like GTK; see bug 1472589 comment #1 through #4.
2. The Snap package manifest adds a dependency on the libcurl package,
so that the crash reporter can send the report. This uses the GnuTLS
variant because we're already pulling in GnuTLS as a dependency of some
other packages (FFmpeg and CUPS, but also the non-GnuTLS cURL packages
depend on it anyway via OpenLDAP).
Differential Revision: https://phabricator.services.mozilla.com/D18625
--HG--
extra : moz-landing-system : lando