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
The new API for onReceivedError() has just been introduced in API 23 / Android 6.0.
However our minSdkVersion is 9 currently.
--HG--
extra : commitid : 7fnyh1z1PeS
extra : rebase_source : e3d2682b357a66027c9a33546c929b6bf7106255
extra : amend_source : c4545b7b0cb8fbf3866a53d1753849f0cdf5c10a
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 : IReBJuG3b15
extra : rebase_source : 6e14f7ad7419e334bafef4bc9f0ac4dcf4355b2a
extra : amend_source : 39e97f5d2cd0e13a691a78e4c65044d379076fa6
Mark Finkle
Carsten "Tomcat" Book
Liang-Heng Chen
Daniel Holbert
Sebastian Kaspari
Jonathan Almeida [:jonalmeida]
Daosheng Mu
Jonathan Almeida
Nathan Froyd
Phil Ringnalda
Masatoshi Kimura
Michael Comella
Wes Kocher
Ehsan Akhgari
Kalpesh Krishna
Alexandre Poirot
Allison Naaktgeboren
Jim Chen
Reuben Morais
Fabrice Desré
Mike Hommey
Richard Newman
Margaret Leibovic
Martyn Haigh
Mark Capella
Prateek Arora
Nick Alexander
Dipti Nirmale
dominique vincent
slayerjain
Friedger Müffke
Sebastian Hengst
Chenxia Liu
Sergej Kravcenko
vivek
Ahmed Khalil
Justin Dolske
Martin Thomson
Jordan Lund
Tooru Fujisawa
Kartikaya Gupta
James Willcox