Extract logic around whether a browser needs to change processes, get a new
frameloader because of preloading, etc. from `_loadURI` in `browser.js` to
`E10SUtils.jsm` where it can be shared with other code paths.
The side effect paths (trying to handle in chrome, removing preloaded state) are
left behind in `browser.js` so that the `E10SUtils` version can be a pure
function.
MozReview-Commit-ID: 6LYB3e3U5o8
--HG--
extra : rebase_source : d6ecac045f90e62a374f8a100e3cc8e1f45f7527
On Desktop and GeckoView we only ever need to store histograms for a
subsession and clear the histograms when a snapshot is done (e.g. a main ping is built).
On Fennec we don't have subsessions and only store for a session and never clear the storage.
MozReview-Commit-ID: BeVi86kZPs2
--HG--
extra : rebase_source : 50bb218c9fb9a04c8d60d6300e4e9e67544232c0
Gecko has some built-in UIs:
* to edit size of objects like <img>, <table> and absolute positioned elements.
* to edit position of absolute positioned elements.
* to add/remove table columns and rows.
Currently, those UIs are available in both designMode editor and contenteditable
editor only on Gecko. I.e., the other browsers' users cannot modify as such
without web apps implement such function. So, for compatibility with the
other browsers, we should hide those UIs by default. On the other hand, if
this is too risky for backward compatibility, we should not do that.
So, before doing that, we should collect actual usage data of object resizers,
inline table editing UI, positioning UI of absolute positioned elements with
telemetry probes.
This patch adds 3 sets of probes for each UI. One is percentage of showing
each UI in all instantiated HTMLEditor. The other is number of user interaction
of each UI in HTMLEditors which has shown the UI.
This patch makes all new probes as "opt-out" because they are really important
data since used for deciding whether those UIs are necessary or unnecessary.
MozReview-Commit-ID: B9Y6GTiCPw6
--HG--
extra : rebase_source : 00e49f31712e24cb269ad3aa65c7d13b7cccb3a5
The symbol server recently gained the ability to upload symbols from try
to a different prefix in the symbols bucket. If we change the token stored
in the Taskcluster secret `project/releng/gecko/build/level-1/gecko-symbol-upload`
to one that has only "upload try symbols" permissions then we can upload
symbols from try server builds directly to symbols.mo.
MozReview-Commit-ID: HjQclKKXbA3
--HG--
extra : rebase_source : 8afed0bf52565bad513c30a7d5de274b356d6d84
buildhub is a service that stores a list of nightly and release builds and
can be queried to find specific builds. Currently it ingests data by scraping
info from ftp.mozilla.org. This patch makes it so we generate a buildhub.json
during packaging with the data that buildhub wants.
There are a few pieces of data that we can't accurately provide from the
build system such as the URL to the build, so we provide some stub data
there with the expectation that a release engineering process will fill
them in later.
MozReview-Commit-ID: 266BnZZBFoL
--HG--
extra : rebase_source : 23d05a9a0dc95ff3705551a5d85d90d6ed8f950f
extra : histedit_source : 166a8dbf4fb63de7e926fb292de07c550db96d78
Currently we have a mess of targets in packager.mk which doesn't really help
much. This patch removes the make-buildinfo-file and make-mozinfo-file targets
and just puts their commands inline in the make-package target.
MozReview-Commit-ID: 7j83dC4QoZY
--HG--
extra : rebase_source : b9aa73f5839903a68e2cbfe88a964519f395060a
extra : histedit_source : 7208f20b3437f47d3f8fcdd734fe40b602be28f5
This script is already doing most of the work, so make it write the text
file instead of using shell commands.
MozReview-Commit-ID: HfFTlNaPSst
--HG--
extra : rebase_source : 30bb2670f24b495809bfaca4a7c63f478291d5ab
extra : histedit_source : 343c70f4d2c0ebc6b7e01f5d0a19cd3853b15739
The `make-buildinfo-file` target is called as part of `make package` to
generate a json file and a text file with some info about the build. Because
a few of those things like the Build ID and source repo / changeset are not
guaranteed to be set at configure time it has to pass them down from the make
environment.
In CI all of these things are passed in the environment, populated at task
graph generation time, so doing this work only in automation builds lets
us simplify things a bit.
MozReview-Commit-ID: 5Ygd3XmSA8x
--HG--
extra : rebase_source : 233f88e436bbf6c3a57d8495f0d92f0aedf98ec5
extra : histedit_source : 735e40632e4b697b6bc32dd15f194e9f02a66f7f
This commit introduces a temp `itemsToRemove` table for local and
remote deletions. We populate this table from the `deleteLocally`
(tombstones on the server that we decided to apply) and
`deleteRemotely` (local tombstones in `moz_bookmarks_deleted` that we
decided to upload to the server).
A deleted GUID can exist in `deleteLocally`, `deleteRemotely`, or both.
GUIDs only in `deleteLocally` already have tombstones on the server, so
they don't need new tombstones. GUIDs in `deleteRemotely`, or in both,
need tombstones for the next sync.
MozReview-Commit-ID: HFk7DDyjIHS
--HG--
extra : rebase_source : 7459640a1705b217ae401fd8981870fcf407b96f
This commit changes `fetchLocalTree` to include all items in Places,
syncable and non-syncable. The four user content roots, and all nodes
that descend from them, are syncable. Everything else is not.
When we check for structure changes of a local or remote node on the
other side, we also check if the node is syncable on both sides. If the
node is not syncable, on either side, we flag it for deletion. If the
non-syncable item is a child of a syncable parent (for example, an
orphaned left pane query), we set the parent's merge state to "new",
just like for local deletions, which flags the parent for reupload on
the next sync.
Uploading tombstones for non-syncable items is handled in the next
commit.
MozReview-Commit-ID: B9HzycuneND
--HG--
extra : rebase_source : e1de165ed17c24d4433a1d08cc9a61399c63f4ba
* Remove `infosByNode` from `BookmarkTree`. The tree only needs to look
up parents by children. The level, and, in the next commit, syncable
flag, can be stored directly on the node.
* Remove `MergedBookmarkNode#{toBookmarkNode, decidedValue}()`. These
are from before we used triggers to apply the merged tree; we don't
actually use the new merge state's synthesized node for anything.
* Flatten `process{Local, Remote}OrphansForNode` into `relocate{Local,
Remote}OrphansToNode`. The next commit uses these methods to flag
non-syncable nodes for deletion.
MozReview-Commit-ID: 6yqJMC1c7rP
--HG--
extra : rebase_source : 7ce2d006d38b554b5341624fadea4e819a247da0
For some reason, removing the scrollbar binding triggers
content process performance regression on Linux.
We'll add an empty binding for now until we find the real cause.
MozReview-Commit-ID: 5sonOULH1x8
--HG--
extra : rebase_source : 10d9a1577f2f36937baf65b10baf29c6e2e3a114
The stacks are now correctly output by the test harness, they may not have been before.
MozReview-Commit-ID: FugywVd9xoC
--HG--
extra : rebase_source : d593415b72da65b1f08bb00ad1249db0b66ca225
Currently, it attempts to override 'ok()', but fails in doing so.
MozReview-Commit-ID: LUp6LRb1Alv
--HG--
extra : rebase_source : 4814ce5684db429af07d9ea9357aa0dedad1a390
Since we want to start collecting all form data through mapFrameTree on Fennec,
too, we need to change our filtering strategy for form data.
We can no longer bail out directly during the data collection loop and instead
have to filter the data after having collected all of it.
The easiest way to do that is to start using PrivacyFilter.filterFormData() on
Android as well.
MozReview-Commit-ID: GBos4Zn3l2U
--HG--
rename : browser/components/sessionstore/PrivacyFilter.jsm => toolkit/modules/sessionstore/PrivacyFilter.jsm
extra : rebase_source : 1c5dfce28716c82e3a237f6d559449cb904ae13a
GeckoView has already started using a slightly modified version of mapFrameTree,
and since ssu.forEachNonDynamicChildFrame() has vastly simplified the process of
correctly using FormData/ScrollPosition.collect() for *all* (non-dynamic) child
frames, we want to use mapFrameTree for Fennec's session store as well.
Therefore, to avoid further duplication of code, we add a common version to the
session store's Utils.jsm module.
We base the code on the GeckoView implementation of mapFrameTree, which has
gained the ability to use callback *arrays*, however we still use ssu.forEach-
NonDynamicChildFrame() like Desktop currently does, instead of simply iterating
over *all* frames.
MozReview-Commit-ID: 3ilEgNSeCEv
--HG--
extra : rebase_source : 793c34bf5160329efd7f92c402945903f0204da9
MozReview-Commit-ID: EQFyRswqy5L
Since a range rect can be considerably smaller than the rect of its
containing frame, this change avoids an unpleasant false-negative for
find-in-page. Without this change, if a frame is reported as visible,
but none of the range rects are visible, the later call to isRangeRendered
will report the text as not findable, even though it could be scrolled
into view. With this change, the text in such a case is reported as
findable, but just out of view, and the find-in-page logic will scroll
it into view as needed.
--HG--
extra : rebase_source : 387a597710a90dcbf3bb54ca39fb3704e7b9457c
Manually-implemented QueryInterface functions don't benefit from the
MozQueryInterface optimizaions, and a lot of them are in hot code, and
implement a large number of interfaces.
MozReview-Commit-ID: 8OzglraowZt
--HG--
extra : rebase_source : 5fff3d9973a0ea976096339a63ce9ff628b68441
J. Ryan Stinnett
Jan-Erik Rediger
Masayuki Nakano
Ted Mielczarek
Coroiu Cristina
Stephen A Pohl
Aaron Klotz
Chris H-C
Narcis Beleuzu
Andreea Pavel
Johann Hofmann
Csoregi Natalia
Brindusan Cristian
Cosmin Sabou
Margareta Eliza Balazs
Mike Cooper
Dão Gottwald
Jorg K
shindli
Paul Bone
David Keeler
Ciure Andrei
David Major
Mark Hammond
Kit Cambridge
Dorel Luca
Issei Horie
Gurzau Raul
Mark Striemer
Timothy Guan-tin Chien
Shane Caraveo
Mark Banner
Haik Aftandilian
arthur.iakab
Valentin Gosu
Zibi Braniecki
Ryan Hunt
Neil Deakin
Jan Henning
Gijs Kruitbosch
Brad Werth
Marco Bonardo
Sebastian Hengst
vinoth
Michal Novotny
Kris Maglione