Screenshots is a system add-on imported from https://github.com/mozilla-services/screenshots/.
This is the initial build system patch for building screenshots. ESLint is ignored since Screenshots currently use their own version (this may change in the future).
MozReview-Commit-ID: 4OEcaduaeWE
The version we update to is the current result from the
macosx64-cctools-port toolchain job.
(gotten with `mach artifact toolchain --from-build macosx64-cctools-port --nounpack`
and uploaded to tooltool)
--HG--
extra : rebase_source : 5d980012de2dfab0556ccb7ed27c434047054523
They are, in fact, the same version already, built from the same version
of clang-static-analysis-linux64.json, but one comes from a now expired
try build, and the other from a build on mozilla-central, that can still
be traced down:
https://tools.taskcluster.net/task-inspector/#Ro1bUCv4Svu2OWuQsOF_hA/0
--HG--
extra : rebase_source : 776314cecb3cba7043a02f4e1f2f4feb4b51731c
This patch creates a new print preview browser to host the simplified cloned-document
when Simplify Page option is used on preview. Also, this patch keeps track of what browser
should be presented, based on whether the 'Simplify page' checkbox is checked.
MozReview-Commit-ID: 77pLXhdbpPp
--HG--
extra : rebase_source : 7201f230299c571d6c3a86ce650d6852c43e0943
MozReview-Commit-ID: Kp8x5o66nrY
I want AccessibleHandler.dll to use different UUIDs based on release channel.
The way I was doing it before wasn't working correctly because I also wanted
local builds to have their own set of UUIDs vs our regular Nightly/Beta/Release
builds.
I also want the beta channel to have its own set of UUIDs that are distinct
from release.
I'm using MOZ_UPDATE_CHANNEL to distinguish between the channels when
NIGHTLY_BUILD and BETA_OR_RELEASE are insufficient.
--HG--
extra : rebase_source : 8cb28a22a3cac16fb743a8fe81db5e120c1fdf6d
The tests in browser_tabCloseProbes.js were closing tabs without waiting for them
to be fully open, and when they're not fully open, closing occurs without animation.
This was intermittently breaking the test for the probe that checks that we add
a count to the right histogram when closing with animation.
MozReview-Commit-ID: 5Qz7mZvtbkB
--HG--
extra : rebase_source : 0d794faebc8e751bfcd15476ae849018dfb1f6c1
Current state:
--------------
Session cookies - those that have no Expires or Max-Age directive, sent as a
header or set via document.cookie - are meant to live for the duration of a
session. SessionStore is a feature that aims to enable users to resume where
they left off last time they closed the browser. So SessionStore will persist
and restore those cookies that the cookie service only keeps in memory.
SessionCookies.jsm registers observers with the cookie service and is thus
notified of cookie additions, deletions, and modifications as-it-happens. It
has its own internal storage that we could easily serialize and write to disk
together with the rest of the session data.
The hangs shown in various profiles stem from the fact that since the inception
of SessionStore as an add-on around Firefox 2, cookies have been tacked to
windows. This means that whenever we collect session data for a specific
window (i.e. tabs, their shistory entries, etc.) we have to iterate *all* its
tabs and *all* their shistory entries to enumerate the hosts contained in that
window. We will then ask the internal cookie store in SessionCookies.jsm to
give us all cookies for these hosts and then store them together with the
window. This way we filter out cookies from tabs/hosts that have no active
documents (BFCache counts as "active").
Changes in this patch:
----------------------
Instead of trying to only retain cookies from “active” documents, i.e. those
contained somewhere in the shistory of a tab, we now simply save all session
cookies of the session. This will surely reduce user complaints about us
"logging them out" too fast because we discard cookies from tabs they
open only once in a while, although those definitely belong to the
browsing session.
Instead of storing the cookies per each window we now have a top-level
"cookies" attribute that is a list of cookies. These get restored whenever we
restore a session. Legacy window.cookies attributes will still be restored to
support older session formats for a while.
The DEFER_SESSION startup mode is active by default when a user choses not to
restore their whole session automatically but they still have one or more
pinned tabs. These pinned tabs are restored automatically and split off of the
rest of the session. The rest can be restored manually if the user chooses to
do so.
In the past, we here extracted and restored only the pinned tabs' cookies from
the last session. This filtering also works against how some sites (e.g.
Google) use session cookies. It also means we have to iterate all windows,
tabs, shistory entries, and cookies to find the data we want.
This patch changes our past behavior so that we now restore only pinned tabs
but all session cookies. So we don't have to filter, and pages will break less
likely. We hereby assume that a user having pinned tabs wants to continue their
browsing session partially, although without Firefox remembering the exact list
of tabs. Or they simply like starting off of a clean slate.
There are quite a few changes in here. At a high level, all we're trying to do is to replace the old update popup with a less intrusive and more modern doorhanger (set of doorhangers) for various update success and failure conditions.
There are quite a few changes in here. At a high level, all we're trying to do is to replace the old update popup with a less intrusive and more modern doorhanger (set of doorhangers) for various update success and failure conditions.
This reduces the amount of places where we need to specify the mozilla/frame-script environment. It does have
the side effect of allowing those globals in the whole file, but that is what specifying the environment would
do, and this is also for mochitest test files only.
MozReview-Commit-ID: 1LLFbn6fFJR
--HG--
extra : rebase_source : 82a6934d90bbbbd25f91b7b06bf4f9354e38865a
When font.name.*.* is set to false, "value" attribute of <preference> is removed. Then, <preference>.setElementValue() with an element which doesn't have onsyncfrompreference tries to set null. Then, <menulist> selects nothing.
In such case, <menulist> should select the item whose value is "". If there is onsyncfrompreference attribute and it returns empty string, <preference>.setElementValue() works as expected.
MozReview-Commit-ID: 54KIe3JxwyA
--HG--
extra : rebase_source : 8b94ff9a790cb5f771901cbfea72240d6d8df554
Update also the similar logic in browser/installer/package-manifest.in. The
reason I added the symbolizer is because it'd be useful when someone conduct
jsshell testing/fuzzing.
MozReview-Commit-ID: J9IqFWsnskS
--HG--
extra : rebase_source : db461065f778fc025576b1fc7612642181d94dcd
There's quite a few changes in here. At a high level, all we're trying to do
is to replace the old update popup with a less intrusive and more modern
doorhanger (set of doorhangers) for various update failure conditions.
MozReview-Commit-ID: 24sESMTosNX
--HG--
extra : rebase_source : ee0c1e00fe3f99e16388f0de17274ff97a3b9fcf
It isn't needed until we create a context menu.
MozReview-Commit-ID: 4kCfq9PzVPV
--HG--
extra : rebase_source : 51907d6aa28d5bd2a9fb8a0acb28cac719888292
This avoids importing ContentWebRTC.jsm unless webrtc is actually
being used, which reduces memory usage.
MozReview-Commit-ID: GlMo1WIZEFD
--HG--
extra : rebase_source : 25476c825bef1948f22d0e6dae67dc01ab41f886
This avoids importing ContentWebRTC.jsm just to register observers
that may never observe anything. Avoiding importing .jsms reduces
memory usage.
ContentObserver.js gets loaded once per content process, so I think
the ._initialized stuff is not needed in the process script.
MozReview-Commit-ID: 5r9L3bfFS0U
--HG--
extra : rebase_source : 0fe6e14c2963efccf21bd1606885098902fed598
The tests in browser_tabCloseProbes.js were closing tabs without waiting for them
to be fully open, and when they're not fully open, closing occurs without animation.
This was intermittently breaking the test for the probe that checks that we add
a count to the right histogram when closing with animation.
MozReview-Commit-ID: 5Qz7mZvtbkB
--HG--
extra : rebase_source : 3533f2c43091829723463f8943cf43e722bbd70c
The .app directory for OSX builds is created piecemeal by several
commands in browser/app/Makefile.in, however it isn't normally cleaned
by a build. If a file is removed from the tree, it's possible that an
incremental build will still have a copy in the .app dir and get
packaged up in the final dmg. It's simple to just rm -rf this directory
beforehand.
MozReview-Commit-ID: 2Zr97o9dTn8
--HG--
extra : rebase_source : 2c9995991c58ee9724464514ec8285c31ab8d062
This avoids a sync IPC message from child to parent.
Changes entirely from:
https://github.com/mozilla/pdf.js/pull/8218
MozReview-Commit-ID: 3Egayok3DBZ
--HG--
extra : rebase_source : e02829e2508bb75caf44c0a3c86b06fac3bf167f
One is always run, the other is only run when PdfJs.enabled is true in
the parent process. This refactoring enables the next patch.
The extensions changes are from:
https://github.com/mozilla/pdf.js/pull/8218
MozReview-Commit-ID: HwQ3yk8Jck4
--HG--
extra : rebase_source : 94f1516989685176a95e235f2d3ef8658adaf8b7
MozReview-Commit-ID: CIrC4ise4Zs
Hotkeys works like normal DOM links, except "Open in background tab" (which corresponds to ctrl/command + click)
open tabs in foreground due to limitation from outside chrome process.
--HG--
extra : rebase_source : 6a3b43c518e23c61fe3c48cc4317b813a39acc7a
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
Previously we were showing a doorhanger when the user moused to the
top of the screen while in fullscreen mode. However, the doorhanger
would disappear before the user had a chance to interact with it.
We decided it's best anyway to simply display a badge when the user
is in fullscreen, and to reshow the doorhanger when the user exits
fullscreen.
MozReview-Commit-ID: ENRtXC4wqvZ
--HG--
extra : rebase_source : d0ddc7395115287620ed4c9532297e825996be1d
sccache doesn't actually support clang-cl currently, so we're just making
our clang-cl builds slower by enabling it. Also, I'm trying to update to
a newer version of sccache and something broke running sccache+clang-cl
entirely so my try builds are busted, so disabling it entirely until
we actually support this configuration seems sensible.
MozReview-Commit-ID: LMkVuBRclCp
--HG--
extra : rebase_source : 76357d16190a6d2b2c5f177874de00ed3e636a76
Previously we were showing a doorhanger when the user moused to the
top of the screen while in fullscreen mode. However, the doorhanger
would disappear before the user had a chance to interact with it.
We decided it's best anyway to simply display a badge when the user
is in fullscreen, and to reshow the doorhanger when the user exits
fullscreen.
MozReview-Commit-ID: ENRtXC4wqvZ
--HG--
extra : rebase_source : 4d7f0880b2b4e8bd9424302bca16ef706e2fca25
This is a temporary measure until we have search complete and shipped (1353954).
MozReview-Commit-ID: KFeOefJ1RGM
--HG--
extra : rebase_source : 326a61f43e3e6f6d771b5bab713454945c9ee060
A couple other hidden="false" attributes were removed since they are unnecessary and shouldn't have been there. The changes to the downloadsGroup are because it is now nested inside of #applicationsContent.
MozReview-Commit-ID: IHZuKZUNYcR
--HG--
extra : rebase_source : f251849fd5a10bff8ad78554b96dc67c69a0ac78
The mercurial revision of sixgill listed in the manifest doesn't exist,
so I took what looks like corresponds to the last change to the tooltool
manifests, in order to avoid any other difference than GMP linkage.
This was built manually on a one-click-loaner.
--HG--
extra : rebase_source : 5ea830e48a6424a6ded9beab0628d0e562251c47
When panel behavior became asynchronous, |StarUI._doShowEditBookmarkPanel| needed to be changed to wait for the panel to finish opening before initializing it. Although the content of the panel can be changed successfully before the panel opens, the element focus at the end of initialization fails. This prevents the capturing of certain events, such as an Esc keypress (which should close the panel).
However, this introduced the problem where there is a short delay between when the bookmark panel opens and when the correct content is displayed in it. To fix this, the initialization function |gEditItemOverlay.initPanel| will now be called before the panel opens, but the element focus code will wait for the panel's popupshown event.
MozReview-Commit-ID: 6SrcCz963qW
--HG--
extra : rebase_source : c45f16913597b336dcae2717c0f902dbbe8025f2
* Track window states: active, fullscreen and tabsintitlebar for each window
* Use toolbar.id and window state to store and retrieve values from cache
* Note: As each window has its own ToolbarIconColor object, the cache is not currently shared across windows
* inferFromText callers pass in a reason and associated value, which is used to update the state we track, and potentially clear out the cache
* Create new windows test directory for browser-window-specific tests like this
* Test for the ToolbarIconColor changes to avoid sync style flushes when windows activate/deactivate
MozReview-Commit-ID: JDJ3RtL4Lge
--HG--
extra : rebase_source : 7b49921bc653d57117f1c08212acc6c2db537984
extra : source : dd2d15dc577d9ec1ec16eb69d823c793dd1e9db0
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
--HG--
extra : rebase_source : 883a91b249b6953b7872bfb9a8851e8be7257c7b
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
--HG--
extra : rebase_source : 2f166cf1746f389a035f7cf557edcadeacb10fa0
Also use the same cctools as cross-mac builds of Firefox.
Do dummy changes to the corresponding build scripts so that the builds
are force triggered (toolchain builds are not triggered automatically
when the tooltool manifest they use changes yet).
--HG--
extra : rebase_source : 699143de819c29c98ca31308ac502f9331123403
* Track window states: active, fullscreen and tabsintitlebar for each window
* Use toolbar.id and window state to store and retrieve values from cache
* Note: As each window has its own ToolbarIconColor object, the cache is not currently shared across windows
* inferFromText callers pass in a reason and associated value, which is used to update the state we track, and potentially clear out the cache
* Create new windows test directory for browser-window-specific tests like this
* Test for the ToolbarIconColor changes to avoid sync style flushes when windows activate/deactivate
* Skip test for windows 8, follow-up filed as bug 1356684
MozReview-Commit-ID: JDJ3RtL4Lge
--HG--
extra : rebase_source : e97bb5c09b2e6d7b264363ccba1b34bf666f31e9
The initial about:blank that we load in a new <xul:browser> is not a load we usually
care about. We have code in tabbrowser.xml that ignores the state changes for that
initial load, but I guess it's not perfect - there's a case where we were getting
a STATE_STOP for that initial about:blank load (since the DocShell will call
Stop() on itself before loading that initial about:blank), and then a STATE_START
once the about:blank actually started to load. The initial STATE_STOP was ignored,
but cleared the "ignore" flag for the STATE_START to come through and show the
loading throbber. Then, when flipping remoteness, the "busy" state was not cleared.
This patch makes it so that we ignore that initial STATE_STOP (differentiated from
other STATE_STOPS because we notice that no loads were currently in progress).
MozReview-Commit-ID: IPTxuVGsCYN
--HG--
extra : rebase_source : c4a574f33c39813bdecdd660e3f5be1bcc96532f
When initializing the service in SessionCookies.jsm,
SessionCookies._reloadCookies() currently iterates all cookies held by the
coookie service and calls _updateCookie() to add them. _updateCookie() however
is supposed to deal with cookie modifications, including session cookies being
converted to longer-lived ones, and thus handles deletion too.
This patch ensures a fast startup path by ignoring cookie deletion, we only
ever need to add new session cookies when initializing on startup. It also
changes the "cookie added" notification handler to ignore deletion.
Additionally, CookieStore.delete() is a little more intelligent now and avoids
the creation of maps only to find out the cookie didn't exist after all.
We need to run toLowerCase() on the category name because the searchresults category is actually searchResults.
MozReview-Commit-ID: 1AgSULER7N4
--HG--
extra : rebase_source : 64dd5aa30cf03666c829c3a8bd1aafa2d1f61860
When restoring a window, it's cheaper if we move the initially selected tab to the
index of the tab that's supposed to be selected in the restored state, rather than
switching to that tab.
If it turns out that moving that tab is not possible (if, for example, the user
context IDs of the two tabs to swap don't match, since the userContextIds are
set at tab construction time), then we fall back to tab switching.
MozReview-Commit-ID: L3qP40K5DaJ
--HG--
extra : rebase_source : 0954dac2f17af74418817ed45c5ab5dee7796511
Code written by Manotej Meka <manotejmeka@gmail.com> and Ian Ferguson <fergu272@msu.edu>
This is the initial landing of the search feature, and is preffed off behind
browser.preferences.search.
MozReview-Commit-ID: 7iaeRsIIV3Y
--HG--
extra : rebase_source : 5e875ed0777397ecc6d98731179a1dfbd1f073df
The Marionette component ships in Firefox, but is not enabled by default.
We want to facilitate activating Marionette at runtime by flipping
the marionette.enabled preference, and showing the Marionette related
preferences in about:config helps discoverability.
It is also useful to rely on the preferences' default values so that
they do not have to be hardcoded in the component.
When Marionette is enabled by setting marionette.enabled to true, a set of
recommended automation preferences found in testing/marionette/server.js
are set if the user has not overriden/user-defined one of them and
marionette.prefs.recommended is true (default). When Marionette is
stopped, the altered preferences are reset.
MozReview-Commit-ID: 3HLnEI0TEBB
--HG--
extra : rebase_source : 8be91ed46c443dd120cbc4b42c729cf3ae250b5f
This is split into a separate patch in an attempt to get a better
diff.
MozReview-Commit-ID: L9AI3VD2pbV
--HG--
extra : rebase_source : 6dc47abd27d8f66886af4cbb458b6d00e8d5c7ee
This retains the advantage of running only once per process, while
avoiding the per-process overhead of a jsm.
MozReview-Commit-ID: 1N53MvRwUpg
--HG--
rename : browser/modules/ContentObservers.jsm => browser/modules/ContentObservers.js
extra : rebase_source : 6a502cff26fcb55526f97385274bbae871f5cc6c
Matt Howell
Mark Banner
Bill McCloskey
Aaron Klotz
Kris Maglione
Mike Hommey
Shane Caraveo
k88hudson
Drew Willcoxon
Blake Kaplan
Wes Kocher
Matheus Longaray
Jared Wein
Dão Gottwald
Gijs Kruitbosch
Fischer.json
Iris Hsiao
Prathiksha
Andy McKay
Mike Conley
Sebastian Hengst
kernp25
ffxbld
Carsten "Tomcat" Book
Tim Taubert
Johann Hofmann
Phil Ringnalda
Ehsan Akhgari
Doug Thayer
Robert Strong
Ryan VanderMeulen
Joel Maher
Masayuki Nakano
Ting-Yu Chou
Doug Thayer
Andrew McCreight
Mike Shal
Rex Lee
Tomislav Jovanovic
Mark Striemer
Mathieu Leplatre
Matthew Noorenberghe
Francesco Lodolo (:flod)
Ted Mielczarek
Sean Lee
Kirk Steuber
Sam Foster
Zibi Braniecki
manotejmeka
David Keeler
Andreas Tolfsen