This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
It's possible for parcels derived from the session to outlast the
session lifecycle. This patch makes us return null when trying to
retrieve window objects using stale parcels.
MozReview-Commit-ID: 3Vp6T3uCEBt
--HG--
extra : rebase_source : fceda356bf812d80d81f4e35cbc3f74ad6151d77
It's possible for parcels derived from the session to outlast the
session lifecycle. This patch makes us return null when trying to
retrieve window objects using stale parcels.
MozReview-Commit-ID: 3Vp6T3uCEBt
--HG--
extra : rebase_source : 5e6b5d71786b326a0f47781cdb8dd5ea90ae71d6
1. Improve BrowserApp._handleTabClosed() to remove Tab correctly if a new tab is
added during "TabClose" dispatching.
2. Resolve "load" event in next event tick to simulate visiting a different page
properly, so the session history will be added correctly.
moz.configure automatically enables profiling if the milestone is
Nightly (see js/moz.configure:226). So, --enable-profiling in the
nightly mozconfigs is redundant and can be removed.
The whitelist has also been updated to reflect the removal of this
line.
MozReview-Commit-ID: 7nUJVcFOp6c
--HG--
extra : rebase_source : 86db8c2bf646c83701ade8c4a10d667d1c2da6f1
We're still somewhat undecided on how to exactly handle external intents
arriving while the tabs tray is open, however in the case of Assist App intents
- opening a new tab in editing mode while the tabs tray remains open causes some
weird behaviour (the keyboard appears in front of the tabs tray and no matter
which tab is selected on the tabs tray, you first enter editing mode and then
always end up in the tab opened by the Assist App intent)
- the goal of our Assist App intent handling is to allow the user to enter a
search query or an address into the URL bar
hence we should hide the tabs tray (if open) when handling such an intent.
MozReview-Commit-ID: GpwrscdNjZP
--HG--
extra : rebase_source : 5275a8323a0ca5bcebdc6fe2148a8de4b87a7651
'modified' value might be missing; in SQLite, max(123, null) is null, and so we must
coalesce fields which might be missing values.
MozReview-Commit-ID: Bn1P0kdaHHT
--HG--
extra : rebase_source : 9f54208c3dd0de8cf602f0e34376e1ac0a511017
This fixes a regression introduced in Bug 1291821. History records would be bulk-inserted from sync, and our ContentProvider
would erroneously forget to set these two timestamp fields.
MozReview-Commit-ID: 2k0afijN62H
--HG--
extra : rebase_source : 143fbcbad3b7a822650c1e132f5ae809c4399ab8
Data review request comment:
1. What questions will you answer with this data?
We want to know when the user exit on-boarding. So we can start to A/B testing on other contextual hints. We don't want to overlap them.
2. Why does Mozilla need to answer these questions? Are there benefits for users?
We need this information to know if users had done on-boarding
3. What alternative methods did you consider to answer these questions? Why were they not sufficient?
I can't think of any.
4. Can current instrumentation answer these questions?
No
5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the found on the Mozilla wiki.
I can't find one for Android
6. How long will this data be collected? Choose one of the following:
We want to permanently monitor this data. (Joe Cheng)
5. What populations will you measure?
All Fennec users
6. Which release channels?
All channels
7.Which countries?
All countries
8. Which locales?
All locales
9. Any other filters? Please describe in detail below.
No
10.Please provide a general description of how you will analyze this data.
We'd like to use Leanplum to cross-reference those events
11.Where do you intend to share the results of your analysis?
We'll use it internally
MozReview-Commit-ID: 2s7Hnc97dhp
--HG--
extra : rebase_source : 81736b5222490347fbc275fc8c8c06a4a2ee19c5
The layout debugger UI is only accessible on desktop platforms, so there's no
need to include it for Android builds.
MozReview-Commit-ID: 8PTDwExU5xz
--HG--
extra : rebase_source : 0cf22b85afd0b036a4899761eca3248ba3ffafbe
- We already do this when packaging conventionally via ./mach package
- The omnijar is itself already a compressed archive, so no need to compress it
again
- Gecko (especially the GeckoJarReader) expects the file to be STORED within the
APK, doing otherwise may cause read access to the omnijar to fail
MozReview-Commit-ID: GcpeAehLe5h
--HG--
extra : rebase_source : b0c2562dc39f00541a9f3da308779c7ffe9fe584
Early during startup there might not be a selected tab yet, so we can't use its
data to decide which home panel to show again.
Fortunately showHomePager can be called with a null panelId, in which case it
will eventually simply fall back to using the default home panel from our
settings.
MozReview-Commit-ID: GbmozJeYZVb
--HG--
extra : rebase_source : 0ed294b6820faa1934105c2719460dd7bef1a852
The background is enabled when using a theme to increase readability of the URL,
but disabled in private mode, because we don't show the theme while in private
mode.
However for the latter feature to work, the respective layout needs to be told
about the private mode state of the toolbar in the first place. We did this
for the ToolbarDisplayLayout, but had forgotten the ToolbarEditLayout.
MozReview-Commit-ID: 3GAesHvwDEX
--HG--
extra : rebase_source : 753be3bcbdbe7fef05fddfcb77e7b69926e6fbef
The reason it was set from mozconfigs is that profiling require it. But
since it was added, bug 751355 made it implied by --enable-profiling,
and bug 1144842 further made sure that profiling and STRIP_FLAGS were
tied together.
--HG--
extra : rebase_source : c2a6b03bf007e661db48e40cca98e81aaa04c878
Similar to maybeSwitchToTab in bug 1426613, a search might be launched while we
don't have a selected tab yet. Therefore we determine private mode state via the
browser toolbar instead.
MozReview-Commit-ID: 4idUR8v7MCx
--HG--
extra : rebase_source : 7104ffbb752b6c0d499b85c47910168391291797
The currently selected tab might not actually exist immediately after startup,
in which case the browser toolbar is a safer bet for determining whether we're
in private mode or not.
I think the current worst case is when we're
- not restoring a previous session, and
- need to open some tab queue tabs, and
- also need to open some other tab in response to our launch intent
in which case we won't have a selected tab in Java until after Gecko is up and
running. This in turn can take a while, especially when a fresh copy of
libxul.so needs to be extracted after an update/installation/cleared cache/...,
which potentially gives the user ample time to click on a search result/Top
Sites entry/... that then triggers this crash.
MozReview-Commit-ID: FlJZw2aL8OM
--HG--
extra : rebase_source : 41f6bb1e83d4f47c1ba04f8ce919753a14dfd9c6
Even though the Sanitizer itself will be lazy-loaded, most imports are only
required for specific data categories. Therefore for users who aren't clearing
all data at once, lazy-loading can still be beneficial.
MozReview-Commit-ID: CLM1BN0XeJj
--HG--
extra : rebase_source : 346124db74eeb1a5dc4cb8c2c6aefcb290b1caf2
Instead of manually unsetting a few variables and adding
--disable-compile-environment, we can rely on the mozconfig that does
all that.
--HG--
extra : rebase_source : 47e0b63d08b98f258344648f1aa002b3da50646b