This class isn't being used right now, and MozURL is a much better alternative if interaction with rust URLs is required.
MozReview-Commit-ID: ADdYRrrTnr6
--HG--
extra : rebase_source : b36aa26c20e7daaadab1f3360bab0ed4681eb7f8
This is currently needed to also test windows L10n repacks on try, because without it we try and sign stub installer bits that were never generated. The assumption is also that we want the stub installer to be testable on try anyway.
MozReview-Commit-ID: LPqU7EPwlVL
--HG--
extra : rebase_source : 5d020a80aa30322c0d528eddcd3bc8f1023730ec
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : 071a9cb1769f013717357458df24e2fd9570ccf4
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : fe3c9480cee468aa2a24fd34e569b58e4f2c9c9a
This patch bundles a color font named "EmojiOne Mozilla", and turn on
the necessary code for including the bundled font, on Linux and Windows.
With that, users of Linux and Windows <=8.0 is able to see color Emoji
on Firefox without support from System.
The font bundled is the v0.2.1 version, generated from the project repo
in
https://github.com/mozilla/emojione-colr
with artwork from the original EmojiOne font and Twemoji,
under CC BY 4.0 license.
Test files, about:license page, and the packager instruction are
modified accordingly.
MozReview-Commit-ID: 2mmxnA0vS3u
Add a switch to enable the rust mp4parser code through confvars.sh
and set this for browser targets. Configure will only pass this
through as a CPP define if the rust toolchain is available.
The MOZ_RUST check is hoisted to an outer conditional to
make it cleaner to add other features.
Thanks to zhoubcfan@163.com for the typo fix in configure.in.
Add a switch to enable the rust mp4parser code through confvars.sh
and set this for browser targets. Configure will only pass this
through as a CPP define if the rust toolchain is available.
The MOZ_RUST check it hoisted to an ourter conditional to
make it easier to add other features.
A new configure option --with-devtools (which sets MOZ_DEVTOOLS) is added to
control whether all DevTools, just the server, or no DevTools are included.
This defaults to just the server.
Applications should also include /devtools within their moz.build tree, so that
DIST_SUBDIR is in effect for all DevTools files if it is used by the app.