The menu is exposed as "More..." on devices that do not have a hardware
menu button.
========
8adeb1be57
Author: Nick Alexander <nalexander@mozilla.com>
Bug 984503 - Part 4: Show a toast after removing Firefox Account.
========
aeffca77dc
Author: Nick Alexander <nalexander@mozilla.com>
Bug 984503 - Part 3: Hide "More..." option if device has a hardware menu button.
The reason for this dance is to keep the "Remove Account" button out of
view if at all possible. I don't want to make it too easy to delete
your account.
========
4efe597308
Author: Nick Alexander <nalexander@mozilla.com>
Date: Thu Aug 28 15:04:38 2014 -0700
Bug 984503 - Part 2: Add "More..." to Firefox Account status list.
========
ad6a55dc33
Author: vivek <vivekb.balakrishnan@gmail.com>
Date: Thu Aug 21 00:25:30 2014 +0300
Bug 984503 - Part 1: Add menu option to remove Firefox Account.
This patch does a few other small things as well:
* It exposes the client device type. This will be used later, as part of
the visual refresh.
* Aligns the field names in remote_tabs_child with the names used by
TwoLinePageRow. This will be used later, when we finally use said
standard view class.
--HG--
extra : rebase_source : 291f69a5f9b68801dd9154c5d291c6795d218ff6
In order to launch in response to the MAIN activity (via |adb shell am
start -a android.intent.action.MAIN org.mozilla.fennec|, for example),
the activity must have category default. That is added automatically to
<activity> elements that have category LAUNCHER, but apparently not to
<activity-alias> elements. This patch adds it manually.
In general, <intent-filters> are prioritized by their order in the
manifest file. To avoid future confusion, this patch bumps the
android:priority of the existing filter.
--HG--
extra : rebase_source : 021da06af2f3e41fc0f38eee7fc33360797f64b0
========
https://hg.mozilla.org/integration/gaia-central/rev/24ad0668cab1
Author: Anthony Ricaud <anthony@ricaud.me>
Desc: Revert "Merge pull request #23331 from zbraniecki/1022767-use-json-l10n-manifests"
This reverts commit 2d16dbb66bc1acdf759e3ad43e5ac9c4c9f9aa2c, reversing
changes made to 001d1761e4685c2a08d3e96bb362f031d47f4033.
This prevent a bug where the graph would be using a SystemClockDriver even if it
was rendering Web Audio API content.
It went like this:
- An AudioContext was created.
- Some AudioNodeStream (Web Audio API MediaStreams) were created, but their
MediaStreamTrack was not added yet
- During the stream ordering, we would see that we were running an
AudioCallbackDriver (because the MSG was created using an AudioContext, and we
pass in hints regarding the type of MediaStreams that will be added in the
future, to open the audio stream as early as we can, because it can take some
time, the MSG was created directly using an AudioCallbackDriver)
- Also during the stream ordering, we see that none of our MediaStream have an
MediaStreamTrack with an audio track. This triggers a switch to a
SystemClockDriver, because the graph thinks there is no audio.
- During CreateAndDestroyAudioNode, we would not switch to an
AudioCallbackDriver on the first iteration (right after the UpdateStreamOrder
call), because we would be switching, and not during the iteration after,
because we thought we already switched (the first patch makes this more robust).
This basically forces an AudioCallbackDriver if there is an AudioNodeStream,
which prevents unnecessary GraphDriver switches (and save threads creation
destruction, audio stream create and destruction, and all other resources
associated with a GraphDriver).
--HG--
extra : rebase_source : 3c79c64a5dffee4c059d286125f0446c04a07a01
