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
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
