bindgen, for whatever reason, is much happier with C:/path/to/file
than "normal" Windows paths. If we provide normal Windows paths,
clang-sys will complain that it's unable to find libclang.dll/clang.dll,
even though we've clearly given it the correct paths by passing in an
appropriate value for LIBCLANG_PATH.
We'll want to define LLVM_CONFIG in mozconfig.common for building Stylo
by default. But if we do that, builds where we don't have an
appropriate clang available will complain that they can't find
llvm-config. So we should only check if we're building Stylo.
We currently have an --enable-stylo option, which when passed builds
Stylo and enables Stylo at runtime. With an upcoming move to building
Stylo everywhere by default, but only enabling it on specific platforms,
we need something more sophisticated than a binary yes/no.
The recent WebRender support offers a model worth emulating: we modify
things so there are four possibilities:
* nothing passed (the default);
* --disable-stylo (explicitly not building);
* --enable-stylo=build (build, but do not enable by default);
* --enable-stylo (build and enable)
The last option corresponds exactly to what we have today, so there's no
change in functionality. This patch makes the default and
--disable-stylo the same; splitting the default and --disable-stylo into
separate cases enables us to change the default behavior at some point
in the future.
Add getChromeUri/setChromeUri APIs to GeckoView, to allow each
GeckoView's chrome URI to be set individually. This lets us remove
GeckoInterface.getDefaultChromeURI. This patch also changes the default
chrome URI to the GeckoView default, and let Fennec specify its chrome
URI (browser.xul) inside GeckoApp.
MozReview-Commit-ID: Gkwbp8VyLcu
Instead of calling GeckoInterface.setAccessibilityEnabled, let
GeckoAccessibility dispatch an "Accessibility:Enabled" event to let
BrowserApp know whether accessibility is enabled or not.
MozReview-Commit-ID: 9ntRP5Pc3lX
Move checkUriVisited, markUriVisited, and setUriTitle from
GeckoApp/GeckoAppShell to GlobalHistory. Make them static and directly
accessible from native code, so that we can remove those methods from
GeckoInterface.
MozReview-Commit-ID: JrmlfeKibaW
Move shortcut creation code in GeckoApp to GeckoApplication, and make
the methods static so that we can call them without a GeckoInterface
instance. This lets us remove GeckoInterface.createShortcut.
MozReview-Commit-ID: AUnQGI02Bk
Move GeckoAppShell.launchOrBringToFront to GeckoApp, so that we can use
GeckoActivityMonitor to check whether BrowserApp is the current
foreground Activity. This lets us remove GeckoInterface.isForegrounded.
MozReview-Commit-ID: CgjnaNK8OGW
GeckoAppShell.enableSensor/disableSensor/loadPluginClass don't make use
of the GeckoInterface instance, so get rid of the getGeckoInterface()
call. r=me for trivial patch.
MozReview-Commit-ID: 24PwdQqO0oq
Add and use WakeLockDelegate within GeckoView code to replace the
notifyWakeLockChanged method in GeckoInterface. Fennec will use the
default implementation in GeckoView, while GeckoView users are free to
override the default implementation through
GeckoAppShell.setWakeLockDelegate.
MozReview-Commit-ID: I8S8q2RZRMu
Use the current Activity to derive GeckoApp instances in tests, so we
no longer need GeckoApp.getEventDispatcher() at all.
Also refactor some code for getting an Activity from Context in
FindInPageBar and FormAssistPopup.
MozReview-Commit-ID: H1QNbtt9dB1
Add AddonManager.getActiveAddons() which can be called during
startup to get a limited amount of information about active addons
without forcing an unwated read of the extensions database.
MozReview-Commit-ID: Fj6z5eYgYYC
--HG--
extra : rebase_source : 24980d599d21ef5bdd42e58f5247567779fbf3e5
extra : source : e032b0944c80a3ab260982f3c219ce4039f61f17
Legacy XUL themes are treated specially for chrome registration when a
lightweight theme is enabled. In those cases, all XUL themes are marked as
disabled for the purposes of UI, but chrome for the default theme still needs
to be loaded. So we need to treate the `selectedTheme` as enabled for chrome
registration purposes regardless of its database disabled state.
MozReview-Commit-ID: EZLckFhftqt
--HG--
extra : rebase_source : e9ab9e9f0d4bdf84e31aa1c7ca77f3a5f0d49fca
MSVC uses a slow, locale-aware isxdigit() implementation which
only serves to waste time here, so we need to inline this manually.
This helps improve the performance of JSON parsing on Windows.
Removes unused gonk code
Changes use of Array.prototype.indexOf(val) != -1 to Array.prototype.includes(val)
Some very minor indentation and logging cleanup
This patch uses the profiler_suspend_sample_thread method which was added in
part 1.
With this patch, we no longer manually run code to pause the target thread,
instead using the profiler's provided code to do so. In addition, we no longer
manually walk the stack to collect native stack frames, instead relying on the
profiler's cross-platform stack walking logic.
This helps remove some of the code from ThreadStackHelper which was redundant
with the profiler. Much of the pseudostack code in ThreadStackHelper is also
redundant, and should hopefully be eliminated in a follow-up.
MozReview-Commit-ID: 4RjLHt6inH9
This patch performs a refactoring to the internals of the profiler in order to
expose a function, profiler_suspend_and_sample_thread, which can be called from a
background thread to suspend, sample the native stack, and then resume the
target passed-in thread.
The interface was designed to expose as few internals of the profiler as
possible, exposing only a single callback which accepts the list of program
counters and stack pointers collected during the backtrace.
A method `profiler_current_thread_id` was also added to get the thread_id of the
current thread, which can then be passed by another thread into
profiler_suspend_sample_thread to sample the stack of that thread.
This is implemented in two parts:
1) Splitting SamplerThread into two classes: Sampler, and SamplerThread.
Sampler was created to extract the core logic from SamplerThread which manages
unix signals on android and linux, as well as suspends the target thread on all
platforms. SamplerThread was then modified to subclass this type, adding the
extra methods and fields required for the creation and management of the actual
Sampler Thread.
Some work was done to ensure that the methods on Sampler would not require
ActivePS to be present, as we intend to sample threads when the profiler is not
active for the Background Hang Reporter.
2) Moving the Tick() logic into the TickController interface.
A TickController interface was added to platform which has 2 methods: Tick and
Backtrace. The Tick method replaces the previous Tick() static method, allowing
it to be overridden by a different consumer of SuspendAndSampleAndResumeThread,
while the Backtrace() method replaces the previous MergeStacksIntoProfile
method, allowing it to be overridden by different consumers of
DoNativeBacktrace.
This interface object is then used to wrap implementation specific data, such as
the ProfilerBuffer, and is threaded through the SuspendAndSampleAndResumeThread
and DoNativeBacktrace methods.
This change added 2 virtual calls to the SamplerThread's critical section, which
I believe should be a small enough overhead that it will not affect profiling
performance. These virtual calls could be avoided using templating, but I
decided that doing so would be unnecessary.
MozReview-Commit-ID: AT48xb2asgV
The primary patch in bug 1308876 causes frames to be reflowed less often
with NS_FRAME_IS_DIRTY, particularly when multiple passes of reflow are
required for the frame or one of its ancestors (which is generally the
case for a document that ends up not having scrollbars). This change
causes this assert to fire on various SVG tests such as
layout/reftests/svg/svg-integration/conditions-outer-svg-01.xhtml .
This happens because the outer SVG with conditional processing (in this
test, systemLanguage="x") is reflowed due to its parent resizing,
without NS_FRAME_IS_DIRTY set. This is a relatively normal thing to
happen during reflow; we just didn't have any tests that exercise it.
This patch adds a crashtest that triggers the assertion through the same
mechanism, but with a dynamic change, rather than depending on the
non-dirty reflow triggered by bug 1308876. (I confirmed locally that
this test does trigger the assertion without this patch, when run in the
crashtest harness.)
I think fundamentally the assertion isn't valid, and we should instead
be testing the condition that it asserts.
MozReview-Commit-ID: D8hjAbjKyuL
--HG--
extra : transplant_source : %98C%3A%B1%93jb%E7%3D%81%19%97%A6%04%0F%88%8B%D2%A35