clang-cl defines it on its own, although the value is slightly different
from __FUNCSIG__ (it doesn't contain the ABI, which doesn't really
matter). We've only been setting it this was on clang-cl by extension of
setting it for msvc.
Depends on D19616
Differential Revision: https://phabricator.services.mozilla.com/D19617
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Previously, this code looked parameters under `gecko.v2`, but that doesn't work
for projects using the out-of-tree taskgraph code, or Thunderbird. This moves
the parameter loading slightly later to vary the index used based on trust domain.
Differential Revision: https://phabricator.services.mozilla.com/D19028
--HG--
extra : moz-landing-system : lando
Profiler was previously fetching process name at the time of shutdown
serialization, at which point that name could have already been destroyed.
Now the child process just forwards the name as soon as it is given, so
the profiler can store it for later.
Differential Revision: https://phabricator.services.mozilla.com/D19732
--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
We support CTAP2 devices on one specific platform, making it hard for RPs to
decide whether or not Firefox will support the tokens they're asking for. This
adds a non-standard method to divine that information while Firefox moves toward
CTAP2 support.
Differential Revision: https://phabricator.services.mozilla.com/D19826
--HG--
extra : moz-landing-system : lando
The element has never existed in the new process, so it gets a missing
error rather than a stale error in that case.
Depends on D19692
Differential Revision: https://phabricator.services.mozilla.com/D19829
--HG--
extra : moz-landing-system : lando
The scrollTo() and scrollBy() functions in the PanZoomController may be
used to scroll the root document in GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D18898
--HG--
extra : moz-landing-system : lando
Adds telemetry for the state of intermediate preloading, as well as what errors
occur during the process.
Dana- will solicit data review today, too.
Differential Revision: https://phabricator.services.mozilla.com/D19507
--HG--
extra : moz-landing-system : lando
Move functionality out of XULDocument::AddElementToDocumentPost:
1) Convert all XUL link elements into HTML link elements which have
code to handle when they are added to the DOM.
2) Move handling of the end of a linkset element into nsXULElement's DoneAddingChildren callback.
3) Move document direction reset to where the root element is created.
Differential Revision: https://phabricator.services.mozilla.com/D19739
--HG--
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
For HTTP loads from the preloaded document, no process swap was occuring
if the preloaded document was loaded in a 'web' process. This caused
test failures, and has potentially undesireable behaviour.
This patch just moves the check for preloaded document swaps to before
the check for http parent process interception, forcing a swap like
normal.
Depends on D19691
Differential Revision: https://phabricator.services.mozilla.com/D19692
--HG--
extra : source : f7ab0e6e739bd54b66b8aaa6219c7dba78f37eb1
Issues were occuring where a process swap would be decided upon during
on-examine-response, but before the swap could be handled by the
channel, the channel was redirected.
This new code takes the mildly hacky approach of simply using a separate
observer notification which is fired at the correct time. A better
solution may be to use a dedicated service for responding to these
events, however that was not implemented for this initial patch.
Depends on D18607
Differential Revision: https://phabricator.services.mozilla.com/D19691
--HG--
extra : source : 3d24e8e81c02af9d1edec7571afecefb0d2f1eb4
This has some minor fixes to ensure we create the object in the callee's realm
for MCreateThisWithTemplate and MCreateThisWithProto. It also fixes Baseline to
actually create a template object for Ion for cross-realm calls.
Differential Revision: https://phabricator.services.mozilla.com/D19760
--HG--
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
Thomas Daede
Julian Descottes
Luca Greco
Mike Hommey
Tom Prince
Gerald Squelart
Jan Henning
J.C. Jones
Oriol Brufau
Jared Wein
Shane Caraveo
Nika Layzell
Randall Barker
Eitan Isaacson
Brendan Dahl
Aaron Klotz
Dorel Luca
Bogdan Tara
Jan de Mooij
Gurzau Raul