All the Linux builds using GCC uses the binutils bundled with GCC. This
gives us some leeway to update the binutils used for clang builds (using
the binutils toolchain as of bug 1486998) separately.
Since we only ship builds using GCC, we're more free to upgrade
binutils for clang builds, without worrying about the next merge.
This upgrades to the last released version of binutils, and applies the
patch from https://sourceware.org/bugzilla/show_bug.cgi?id=23591 on top,
so that asan fuzzing builds don't fail.
The GPG key used to sign the upstream tarball is unfortunately not
connected to the web of trust. I verified the contents matched what's in
the Debian archive (which has a different tarball, because some files
are removed/modified in Debian for license reasons ; there were no
differences besides those).
Differential Revision: https://phabricator.services.mozilla.com/D4748
--HG--
extra : moz-landing-system : lando
SelectionChangeListener is an nsISelectionListener class. This is added only
to Selection for "normal" and added by nsFrameSelection::Init() after
AccessibleCaretEventHub. So, we can make Selection directly treat
SelectionChangeListener.
Differential Revision: https://phabricator.services.mozilla.com/D4757
--HG--
extra : moz-landing-system : lando
AccessibleCaretEventHub is an nsISelectionListener of Selection whose type is
"normal". This is added only when nsFrameSelection::Init() is called and
accessible caret is enabled. Additionally, nsFrameSelection::Init() is
always called immediately after creating nsFrameSelection.
Therefore, when AccessibleCaretEventHub is installed to Selection, this is
always second selection listener and won't be installed multiple times. So,
Selection can store pointer of AccessibleCaretEventHub directly only when
it's enabled and the Selection needs to notify it of selection change.
This patch makes Selection stores AccessibleCaretEventHub with RefPtr, then,
makes Selection::NotifySelectionListeners() call its OnSelectionChange()
immediately after AutoCopyListener.
Unfortunately, this patch includes making of MOZ_CAN_RUN_SCRIPT_BOUNDARY and
MOZ_CAN_RUN_SCRIPT a lot since some methods of AccessibleCaretEventHub are
marked as MOZ_CAN_RUN_SCRIPT and including AccessibleCaretEventHub.h into
Selection.h causes compile the compile errors.
Differential Revision: https://phabricator.services.mozilla.com/D4733
--HG--
extra : moz-landing-system : lando
We already trim the display of output lists for GENERATED_FILES scripts
that produce many outputs, so we should do the same for rust build
scripts. This makes the terminal output of the build and the nodes from
'tup graph' more readable.
MozReview-Commit-ID: AftmrA4qJlr
Differential Revision: https://phabricator.services.mozilla.com/D4797
--HG--
extra : moz-landing-system : lando
Introduce these new blocking state values:
const unsigned long STATE_COOKIES_BLOCKED_BY_PERMISSION = 0x10000000;
const unsigned long STATE_COOKIES_BLOCKED_TRACKER = 0x20000000;
const unsigned long STATE_COOKIES_BLOCKED_ALL = 0x40000000;
const unsigned long STATE_COOKIES_BLOCKED_FOREIGN = 0x80000000;
Summary: It is currently quite difficult to debug minified scripts. The JitSpew and profiler used to display only line numbers, so all of the output would be emitted as "script:1". Column number information is now collected by the gecko profiler as of bug 785922. The JitSpew should also emit column numbers so that it's easy to line up with the profiler output.
Reviewers: mgaudet
Reviewed By: mgaudet
Subscribers: jandem
Bug #: 1485738
Differential Revision: https://phabricator.services.mozilla.com/D4677
--HG--
extra : source : 3f831b709e370b14ccf9f06508760633cd6b312a
Use the unused 'p' bit in the version code to denote 64-bit builds, so
we have different version codes for 64-bit builds on aarch64 and x86-64.
Differential Revision: https://phabricator.services.mozilla.com/D4260
--HG--
extra : moz-landing-system : lando
make counter increased when trackers are found
Differential Revision: https://phabricator.services.mozilla.com/D4068
--HG--
extra : rebase_source : 90da79fbb83271b2f7a8460ebd02aa2abb635305
extra : source : c476aa79a8ca991dc8ea1e5c2eab98e442dad406
separate tracker counter API
Differential Revision: https://phabricator.services.mozilla.com/D4490
--HG--
extra : rebase_source : 2a786ca9d008e01e465d1d34951d07493c5c9d2b
extra : source : 9370432b26adcd6399e586190a47d4c8a8cdc56d
If we don't have a saved session, we do nothing. If somebody called setSession
beforehand, we continue using that session, otherwise we create a fallback
session in onAttachedToWindow().
If we have a saved session and nobody called setSession, we use the saved
session. If the saved session was closed and doesn't have a runtime, we use the
default runtime as a fallback.
If we have both a saved session and somebody already called setSession, we
transfer what can be transferred from the saved session, unless the saved
session is closed and the session from setSession is open.
If the saved session was open, we use its runtime as well going forward (since
transferring the state from an open session transfers the window and the runtime
as well), otherwise we keep the old mRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D4711
--HG--
extra : moz-landing-system : lando
Last time it was updated is bug 1436208, and the crashes we patched it
for back then has been fixed upstream a few months later.
For some reason, they renamed the executable from llvm-dsymutil to
dsymutil.
Differential Revision: https://phabricator.services.mozilla.com/D4741
--HG--
extra : moz-landing-system : lando
Added an extra check for package name for a better user experience, because the push notifications with "about" protocol
in the URL message were still firing the chooser dialog.
Differential Revision: https://phabricator.services.mozilla.com/D4578
--HG--
extra : moz-landing-system : lando
Instead of stopping the foreground service whenever ACTION_PAUSE was triggered,
I created a new event where we notify the service to clear its foreground state.
Cleared usages of the NotificationManager and the onGoing attribute of the
MediaNotification because they are redundant. As of Android 4.3 a service in the
foreground state will always force the notification to be persistent and callling
stopForeground(false) will clear the onGoing flag while maintaining the notification.
Differential Revision: https://phabricator.services.mozilla.com/D4567
--HG--
extra : moz-landing-system : lando
so that such requests don't inadvertently reuse connections done that
might have used TRR.
MozReview-Commit-ID: 2bO4VCGSgOO
Differential Revision: https://phabricator.services.mozilla.com/D4693
--HG--
extra : moz-landing-system : lando
This allows screen reader users to determine the context of various controls when tabbing through them.
Specific changes:
1. Describe the "Cookies and Site Data" group using the disk space indicator; e.g. "Your stored cookies, site data and cache are currently using 315 MB of disk space."
2. Associate the description for the "Content Blocking" group; i.e. "Block third-party content, like ads or code..."
3. Correct association of the label for the "Do Not Track" setting; i.e. 'Send websites a “Do Not Track” signal that you don’t want to be tracked'
4. Associate the label for the "Permissions" group.
5. Make each permission a labelled group so the user knows what the various "Settings…" buttons are for.
6. Associate the label for the "Data Collection and Use" group.
Differential Revision: https://phabricator.services.mozilla.com/D4638
--HG--
extra : moz-landing-system : lando
replaceTabsWithWindow calls replaceTabWithWindow to create a new window window with a first tab.
But unlike the later function, the former cited function don't take an object param (aOptions) containing informations such as the mouse position (which helps set the new window position).
To adress the issue, we added support for passing an option param to replaceTabsWithWindow which just transferts the param to replaceTabWithWindow.
Differential Revision: https://phabricator.services.mozilla.com/D4735
--HG--
extra : moz-landing-system : lando