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
Without the use of an upstream the first repo cloned on a machine will
be cached. If a subsequent job references a different repo, it may have
to pull thousands of changesets because those changesets aren't part of
the initially-cloned repo. This is why the --upstream feature to
robustclone exists and is why it uses the mozilla-unified repo.
The mozilla-unified repo is a superset of central, aurora, beta, release,
etc. So by cloning it, you get changesets for all of the repos at the
time of the clone. When a subsequent job comes along and requests
a changeset from a different repo, you likely only need to fetch data
for a handful of changesets, not thousands.
This change adds the upstream url config for all fx_desktop_build jobs,
ensuring it is used. A redundant config entry for the try repo has been
removed as well.
MozReview-Commit-ID: 3EL7aSXS4AG
--HG--
extra : rebase_source : 19fc7373da56ad879b4b813a379dd8d9798909e4
I think I initially defined these and I think I know why I used
mozilla-central (it had to do with try not advertising bundles and
mozilla-unified being generaldelta when other repos were not). Those
reasons are no longer valid and we should be using mozilla-unified
everywhere.
MozReview-Commit-ID: CFaZspU6A5M
--HG--
extra : rebase_source : 79b74038307a3faa9b150a7ea1d449cad472e748
The webrtc gyp files have a 'build_for_tool' flag that controls among other
things what defines are provided at build time. This meant that during a
firefox valgrind build webrtc would still specify NVALGRIND, thus disabling
some valgrind macros. Similarly there are flags for asan and tsan that we
should probably have been specifying as well. This patch sets the
'build_for_tool' flag to the appropriate value when building under valgrind,
asan, and tsan.
Additionally, move some history tests to the history folder, split insertMany tests into their own test file.
Also, remove some no more needed android annotations, Firefox for Android doesn't use nor build Places anymore.
MozReview-Commit-ID: 6p4mazeUjsw
--HG--
rename : toolkit/components/places/tests/unit/test_async_history_api.js => toolkit/components/places/tests/history/test_async_history_api.js
rename : toolkit/components/places/tests/history/test_updatePlaces_sameUri_titleChanged.js => toolkit/components/places/tests/history/test_sameUri_titleChanged.js
extra : rebase_source : 1061f3ceb6dc20b9a94a39a7d400670ac45657d0
This helps Stylo builds to actually use the new cssparser.
Source-Repo: https://github.com/servo/servo
Source-Revision: 535d0e421a3188473fc0c3cefca569c1276c4804
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : d72cbe5b073fd7a22eb291a86007734c7b54e42b
On Android, nsIHandlerInfo instances representing protocols are also instances of nsIMIMEInfo. This causes the RDF back-end of the handler service to store them in the same cateory as MIME types. This fix corrects the situation for the JSON back-end, while leaving the RDF back-end unchanged for backwards compatibility.
Detailed testing is added using different RDF reference files for Desktop and Android.
MozReview-Commit-ID: B0ls60jfENe
--HG--
extra : source : 0bfa2e0ad6232cbaf66dd7e42326101e23b62352
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.