A new configure option --with-devtools (which sets MOZ_DEVTOOLS) is added to
control whether all DevTools, just the server, or no DevTools are included.
This defaults to just the server.
Applications should also include /devtools within their moz.build tree, so that
DIST_SUBDIR is in effect for all DevTools files if it is used by the app.
Previously we used a ViewStub to only show the back button for some configurations. Now we
show the button always, so we can get rid of the ViewStub.
--HG--
extra : commitid : EcIVAzNG08l
extra : rebase_source : 4bf70217fee2c8913a8343da1bf579b183c81693
DONTBUILD NPOTB
This has always been possible with Gradle -- Gradle doesn't care where
in the file tree resources are found. (Gradle is perfectly happy to
take resources from outside of the root project directory.) IntelliJ,
however, displays resources outside of known "content roots" in
special and frankly unhelpful ways. Here, we avoid that on a
technicality: IntelliJ doesn't acknowledge (or even register a content
root!) for the non-standard AndroidManifest.xml locations set in
build.gradle. This means we don't see odd content roots in unexpected
places in IntelliJ.
With this change, the formerly failing command
mach clobber && mach configure && mach gradle-install
completes successfully. That gets us one step closer to being able to
open Fennec in IntelliJ without running additional commands.
--HG--
extra : commitid : 6KuAzJIpq3Y
extra : rebase_source : 0b85181412d86fa49ee52cf7d612dd3c4028dfb6
extra : histedit_source : 6b8d8171810501a0af053df080b336af70c456b6
DONTBUILD NPOTB
This needed the same dependency changes that the previous part did.
There's a nice simplification here because some of the code is now
being compiled in the containing project (base) and not the (now
removed) sibling project.
--HG--
extra : commitid : IHKXiR8SpLr
extra : rebase_source : 0b2e03f0a76ed17782f0bbaba61adbfa547a6ba2
extra : histedit_source : 0c3420152b2c37dfcbb6e11e6ca58e6c03ad7aca
While testing, I found some issues with the existing dependencies. To
address them, I've made all project preBuild tasks depend on the
(single) root generateCodeAndResources; this should ensure that the
Make integration happens as early as possible. In addition, I fixed
the dependencies syncing the generated resources into the build
directory, which weren't quite right. This works well locally now.
--HG--
extra : commitid : 4Kblf9h0yst
extra : rebase_source : e9e6fa415939f2622a7cfc09f5945e31269338e4
extra : histedit_source : 4cdf1470a0d99b1f805a4fda69d57f425f613421
Technically, branding should be part of the App and not GeckoView, but
we don't have separated resources yet, so in it goes.
--HG--
extra : commitid : 5r00T6BTBRE
extra : rebase_source : ca1411809bb5352617814bc136689d77358fd29c
extra : histedit_source : a435587e3bf16ad3f5457936a0e4efeffa69f9a4
We were both lazy and incomplete before. Lazy because .aapt.deps is a
sentinel, and doesn't necessarily see relevant changes, due to
timestamps and deletions. Incomplete because we never forced
generated Java code to be fresh.
--HG--
extra : commitid : JXLe9uWqjhN
extra : rebase_source : 8eaa2d012915ad59d5cd03d7e4a6552ae4db13c1
extra : histedit_source : 231ca7ad88e7965424a8c8a3e80dac68a32980a7
This patch will use the single column list on phones in portrait mode
again. In landscape mode the multi column grid will be used.
In addition to that this patch removes the Nightly flag (Bug 1204917).
--HG--
extra : commitid : Cw6uqgLYChb
extra : rebase_source : d9e45369adb0bba89f0376c6756eddafc6d71ae1
DONTBUILD NPOTB
The :omnijar project is for IntelliJ only; adding it neatly labels
folders we consider part of the omnijar in mobile/android. The JAR
produced is not used.
We add an evaluation-time dependency from :app to :omnijar so that we
can declare the set of omnijar folders exactly once. We'd prefer to
have the dependency in the other direction (to save evaluation time)
but there's an interface mismatch between the two Gradle model types.
See comments in the :omnijar project.
This is delicate.
--HG--
extra : commitid : 4TLicjMC7Bn
extra : rebase_source : 5dd4ab1e1fcdb296b46bc892b9e10414baadee61
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This new screen better fits the style of the share overlay.
--HG--
extra : commitid : Cmru9467h5K
extra : rebase_source : b3658b71eafa13ded04dc9bb7da4a3355054450f
These Strings' callsites were removed in the previous commit.
--HG--
extra : commitid : 80m2nfG6q7p
extra : rebase_source : a012df2154652404380c3221191953fd2353ef63
The upcoming commits will replace the toast with an alternative confirmation.
Note that this new confirmation will occur *before* the share event, meaning we
can't show the user whether the share actually passed or failed. However,
failure is essentially non-existent so we don't care.
--HG--
extra : commitid : CpdtyrIVEcy
extra : rebase_source : da6721fa6e5af3cd0241167ad629b90cdb7b4f26
Note that these assets will be consolidated in bug 1212629.
--HG--
extra : commitid : 4Bns1UBRvrs
extra : rebase_source : 8bf8f5fefc5c586386c2b720037c9f5cb23366f6
This should make these attributes compatible with Theme.AppCompat.
--HG--
extra : commitid : IsmpzvpV3ox
extra : rebase_source : 92eed417ac1067cd962c57624d8b2530cdba8fd6
We override this in most places so it shouldn't affect the application too much.
--HG--
extra : commitid : 21btkn6GZap
extra : rebase_source : 600f66cc5836ad040a4ec497569f6cb6d6b2df19
This will resolve conflicts when introducing the android design support library
in bug 1189306.
--HG--
extra : commitid : 6mkNPj0xng4
extra : rebase_source : 3feee4e9f361cb3e18e7c7c02f6ec206de6cb015
If Gecko is not ready, we should queue the disposeNative call in
GeckoView.onDetachedFromWindow instead of calling it right away. We use
the PROFILE_READY state here to correspond to
GeckoView.onAttachedToWindow, where we make the open call on
PROFILE_READY.
This changes the color of the settings action bar to grey, as expected.
Note that I was unaware of this no-prefix convention when I wrote the previous
patch and added an "android:actionBarStyle" which may be confusing things
further. We may also benefit from removing the prefix there and fixing the
results.
--HG--
extra : commitid : 6aYSAKTkbkB
extra : rebase_source : cc66caa6da48dce95b58f4fd225ac01f1ffa9ee7
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
On (at least) Android 6.0 it can happen that GeckoView has focus but is not the active view for the input
method. As a consequence InputMethodManager will ignore the call to showSoftInput().
--HG--
extra : commitid : 6Gkhejuli6g
extra : rebase_source : bd5486bc60af060f058b0335a524a1b9aafe1b8f
I tested multi-locale builds and the notification is in the new language as
expected.
--HG--
extra : commitid : H4ESwDwwebb
extra : rebase_source : 172fc75d5430d250b6b1cf2082da8da833ac230f
After this changeset series, the expected flow for web links is:
* If not pb, open the Intent URI
* If pb and no matching applications, open about:neterror
* If pb and one matching application, show this dialog
* If pb and > 1 matching application, show the Android system chooser
When the user explicitly chooses to share (and thus should infer they're
exiting Private Browsing), we don't show the dialog.
Custom URIs sort of work: I tested `mailto` and it worked as expected but `tel`
does not work as expected (i.e. it doesn't show the dialog). Perhaps there's an
explicit "Open dialer" code path. To figure this out, I tested this patch
against my Intent URI test page [1].
Decisions around explicitly showing the Android chooser:
When there are multiple application matches to an Intent URI, we
want to show the Android Intent Chooser. However, we have no way
of distinguishing regular tabs from private tabs to the chooser.
Thus, if a user chooses "Always" in regular browsing mode, the
chooser will not be shown and the URL will be opened. Therefore we
explicitly show the chooser (which notably does not have an "Always"
option).
[1]: https://people.mozilla.org/~mcomella/test/uri.html
--HG--
extra : commitid : DobYxI7BEnZ
extra : rebase_source : 12c30732a07e20f29ad67ce153cdbd13fc143e73
Note that the DialogFragment is currently unused and will be used in the
followup changesets.
--HG--
extra : commitid : UYPRTIGSfk
extra : rebase_source : dc1e45275f41280df6fceb11c1afad0834777064
One fear is that different devices set different menu colors and text colors.
Since we're using the default text color and set an explicit menu color, the
text color may not look good on these devices. I was unable to find a way to
override the menu text color.
It seems the best way to find out if this is a problem is to land
it and test though!
--HG--
extra : commitid : ylxnVEA269
extra : source : c01f712e3d98c74a03f1dcf9c5133c0c8982d32d
This excludes Material design in v21+, which will be overridden with AppCompat
in the following changeset.
--HG--
extra : commitid : 6NvfKORKfyr
extra : source : bfc7e7f997eb2a4f5bbfea4e817aa4e738900d5b
After this changeset series, the expected flow for web links is:
* If not pb, open the Intent URI
* If pb and no matching applications, open about:neterror
* If pb and one matching application, show this dialog
* If pb and > 1 matching application, show the Android system chooser
When the user explicitly chooses to share (and thus should infer they're
exiting Private Browsing), we don't show the dialog.
Custom URIs sort of work: I tested `mailto` and it worked as expected but `tel`
does not work as expected (i.e. it doesn't show the dialog). Perhaps there's an
explicit "Open dialer" code path. To figure this out, I tested this patch
against my Intent URI test page [1].
Decisions around explicitly showing the Android chooser:
When there are multiple application matches to an Intent URI, we
want to show the Android Intent Chooser. However, we have no way
of distinguishing regular tabs from private tabs to the chooser.
Thus, if a user chooses "Always" in regular browsing mode, the
chooser will not be shown and the URL will be opened. Therefore we
explicitly show the chooser (which notably does not have an "Always"
option).
[1]: https://people.mozilla.org/~mcomella/test/uri.html
--HG--
extra : commitid : 1cCVQe5jmNx
extra : rebase_source : 146766c2ac5cf8814288377453253debc2ff3f8a
Note that the DialogFragment is currently unused and will be used in the
followup changesets.
--HG--
extra : commitid : 2SboY6SbK0Y
extra : rebase_source : 601bd61bcaec304477fc8ed6e99b555f9d3fe404
One fear is that different devices set different menu colors and text colors.
Since we're using the default text color and set an explicit menu color, the
text color may not look good on these devices. I was unable to find a way to
override the menu text color.
It seems the best way to find out if this is a problem is to land
it and test though!
--HG--
extra : commitid : AOkx9ROJDf7
extra : rebase_source : 49318e2d179a4da16933cb8248b4b9b00a606226
This excludes Material design in v21+, which will be overridden with AppCompat
in the following changeset.
--HG--
extra : commitid : JL19c4EJfVf
extra : rebase_source : b9030c31b99bd2e1613fc7898e7ef4f9c275003c
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
The regression is fixed by the backout of bug 1175354 and this
should ensure it doesn't happen again.
--HG--
extra : commitid : 7mVa6zNb0uq
extra : rebase_source : b83744e2fc37fbf41a1d91104861b3bc41c00a05
This will make the following SDKs, tools and libraries available:
* Android SDK 6.0 / API 23
* Android tools r24.4
* Android build tools 23.0.1
* Android Support Repository (Support Library 23.0.1)
* Google Support Repository (Google Play Services 8.1.0)
To support gradually switching the Android 5.1 SDK (API 22) and Android build tools 22.0.1
are still included in the linked archive.
--HG--
extra : commitid : ESkIoGj3q2f
extra : rebase_source : f30a24432876e839980a07fe4109b324f090c096
It's quite challenging to both wait for "load", and wait for something
to happen in the DOM, since the DOM isn't prepared until after "load"
has fired. This test therefore has a small race window: it is
possible that we could wait for the mutation only after the logins
have been loaded and the 'logins-list' DOM element is inserted. The
logging should be good enough to identify this case; and in practice,
this is very unlikely.
Since I was here, I converted this to use SpawnTask.js.
--HG--
extra : commitid : 1cCEXRuq146
extra : rebase_source : f458ec34f684bbdefa5794fcfb0b18b1ac6b0926
Right now, in response to "load" (on the window), we're:
1) updating the DOM to show the spinner;
2) loading the logins with a main-thread janking synchronous load;
3) updating the DOM to hide the spinner.
This is all on the main-thread, so we only see a layout and paint
after 3). Thus no interstitial is ever visible, and the logins list
pops in after a long delay.
This patch ensures that 2) occurs at least one layout after 1). This
allows a paint to occur with the interstitial visible. Since the
animated CSS spinner is carefully designed to hit the off-main-thread
animation pipeline, it animates smoothly even though the main-thread
janking synchronous load blocks JavaScript progress.
There is a small race window between the promises resolving and the
_logins member being accessed by the filter. It's not clear that this
was ever well guarded, so I haven't tried to mitigate.
--HG--
extra : commitid : 9nKfLhK3JOa
extra : rebase_source : 8eb67ac9322372aa6e049d7154542c31e9de0d43
This collects client-side fxa-content-server data. The data covers
only the about:accounts experience until:
* the fxa-content-server provides the LOADED message; or
* connection failure is observed.
Nota bene: a healthy fxa-content-server always delivers the LOADED
message! In future, we might want to timeout the load (and observe
said timeouts) separately.
We collect no data after the fxa-content-server LOADED message. The
intention is for the server-side metrics flow to capture the valuable
"bounce rate" metrics, since the fxa-content-server team are in
position to quickly improve the web-based UI flow.
The client-side data collected is intended to answer the following
questions:
1) How many remote content loads started;
2) How many loads completed;
3) What proportion of loads made it to the LOADED message, as opposed
to failed;
4) How long it took each successful load to observe the LOADED
message;
5) How long it took each failing load to observe failure.
All of these are keyed by the fxa-content-server endpoint path (like
'settings' or 'profile/avatar'), since I observe differences between
the time-to-LOADED for each endpoint path.
There is a privacy trade-off here. Mozilla is collecting data to
understand the user experience when about:accounts is connecting to
the specific fxa-content-server hosted by Mozilla at
accounts.firefox.com. However, we don't want to observe what
alternate servers users might be using, so we can't collect the whole
URL. Here, we filter the data based on whether the user is /not/
using accounts.firefox.com, and then record just the endpoint path.
Other collected data could expose that the user is using Firefox
Accounts, and together, that leaks the number of users not using
accounts.firefox.com. We accept this leak: Mozilla already collects
data about whether Sync (both legacy and FxA) is using a custom server
in various situations: see the WEAVE_CUSTOM_* Telemetry histograms.
--HG--
extra : commitid : 6ablpwYytrm
extra : rebase_source : bb04e263adf4fd34d36b51610ca170f3dd9c8328
This is hygiene that completes the set of paths through this part of
the code. If we wrapper.{init,retry}, we are guaranteed to have a new
promise; and now that promise will always be fulfilled. It is
technically possible, but not anticipated, for an in-flight promise to
be replaced. Such a situation should not occur, but if it does, the
obsolete promise will still exist but never be fulfilled (since
loading or errors only touch the most recent promise). Eventually it
will be safely garbage collected.
--HG--
extra : commitid : 9gE08vjgVdF
extra : rebase_source : b920d6c1ae45e28128fcc3702cba219d66f7b1ab
J. Ryan Stinnett
Chenxia Liu
Jim Chen
Sergej Kravcenko
vivek
Sebastian Kaspari
Nick Alexander
Carsten "Tomcat" Book
Mark Finkle
Margaret Leibovic
Michael Comella
Kershaw Chang
Liang-Heng Chen
Christian Schmitz
Wes Kocher
Daniel Holbert
Jonathan Almeida [:jonalmeida]
Daosheng Mu
Jonathan Almeida
Nathan Froyd
Phil Ringnalda
Masatoshi Kimura
Ehsan Akhgari
Kalpesh Krishna
Alexandre Poirot
Allison Naaktgeboren
Reuben Morais
Fabrice Desré
Mike Hommey
Richard Newman
Martyn Haigh
Mark Capella
Prateek Arora
Dipti Nirmale
dominique vincent
slayerjain
Friedger Müffke
Sebastian Hengst
Ahmed Khalil
Justin Dolske