Layer on the hacks! This:
1) Reinstates the <activity-alias android:name=".App"> that we have in
the moz.build produced Android manifest. I found no way to do this
using placeholders or the manifest merger.
2) Culls manifest entries provided by
com.google.android.gms.measurement. We know they're not necessary,
since they're not present in the existing Fennec Android manifest.
These are strictly workarounds to avoid doing the real work of fixing
the issues. To fix 1), we'd need to migrate all existing users with
homescreen shortcuts to .App. This could be difficult, especially if
partners have deployed packages out of our update control. To fix 2),
we'll need to upgrade our Google Play Services to at least version
9.0.0 and then use the finer-grained AAR dependencies to not build
with the measurement split at all.
MozReview-Commit-ID: 21CaZ2KMeIa
--HG--
extra : rebase_source : c9aff7c414c13843c4e54267c95941fa35bc1001
This has two advantages:
* If the network changes while we are downloading content then we do not continue on an metered network.
* When adding telemetry in one of the next patches then we can report which kind of content we did not
download.
MozReview-Commit-ID: 80QzSRyCArr
--HG--
extra : rebase_source : ff902c57e36cc5eadaef075410635aa07671c353
There's no need to run all other checks if there's nothing scheduled to be downloaded (anymore). In later
patches we want to report error states to our telemetry system and there's no need to report "no network"
errors if we are not going to download anything anyways.
MozReview-Commit-ID: K4bxbM3ptvZ
--HG--
extra : rebase_source : 22c8d9ff3f10e76d25362332232f9eb0e65e0e14
There might be up to 2 Always-show-as-action button in ActionBar.
One for menu-options, one for 3rd-party app action-button, if any.
According to our design spec, the two buttons appearance should be
similiar, therefore now we create them by same method.
MozReview-Commit-ID: GPVteQR3hxr
--HG--
extra : rebase_source : f03b2dcda5864221abe301d1b1ce8f8c1c38752d
Move this change to ActionBarPresenter. Use cross icon as close button
to match design spec.
MozReview-Commit-ID: JgUcKp7p7Bc
--HG--
extra : rebase_source : 8350b2d8684cd967cb7463949017c26db4ef1782
.aidl files can contain interfaces or parcelables. Interfaces should be
compiled through the aidl tool but parcelables should not. Explicitly
list the AIDL interfaces for Fennec, so we only compile the interfaces
but not the parcelables.
Based on what I'm seeing, if you call scrollToPosition and that causes you to
"scroll into view" (remember, scrollToPosition doesn't actually scroll, it just
redraws the new position) one or more positions, then RecyclerView runs the add
animation on all those views "scrolled onto screen", which, for the list view's
slide-in-from-the-right add animation, looks silly (I think). [Caveat:
RecyclerView sometimes keeps one offscreen view ready to go, which doesn't seem
to get the add animation.]
In non open-tab-from-another-app-with-the-tabs-tray-already-open operations this
was never an issue because either those animations are hidden by the panel being
animated into view when the panel opens and we scroll to the selected position
[at least that's my guess], or we only scroll by at most one, as in the case of
a tab close or undo close. But in the
open-a-tab-and-scroll-to-it-while-the-tabs-tray-is-already-open case that we can
get with opening a tab from another app, the add animation runs for however many
tabs "need to be added" between the current position and the new tab; sometimes
the animation still gets hidden if the new tabs get added quickly enough when
fennec reloads [again, my guess], but on my device I always see the animations
if I open a tab in tab queue and then reopen Fennec by hand, whereas on an
emulator I see the animations in additional external-app-open cases as well.
MozReview-Commit-ID: J3x0bBLPNyz
--HG--
extra : rebase_source : 9ee77d395e452e50f958c6c096167704cbe37795
extra : source : f03ab10a14245f2cd8c71130cb677cb8bf1a31db
If another app opens a link in Fennec, and Fennec restores itself in a state
where the tabs tray is already open, we need to scroll to the newly added tab
since it gets added offscreen (not to mention the scroll position restored when
we open is unconstrained (it's whatever the user left it at before they switched
apps)).
This introduces one small change in behavior:
1) Use a gridded tabs tray;
2) Fill more tabs than will fit in the tray;
3) Put more than one tab on the last row;
4) Scroll so that the last row is partially, but not fully, hidden;
5) Close the last tab and then undo the close.
In that case we now scroll the last row fully into view, whereas previously we
maintained the old (partially hidden) scroll position. (If you undo close any
tab other than the last on the final row then you still get the old behavior.)
Note that this fixes the case where the other app adds a *new* tab in Fennec
with the tabs tray open; it's (currently) also possible to open a link in an
already existing tab with the tabs tray open - that's bug 1353226.
MozReview-Commit-ID: BazXFwT0B8v
--HG--
extra : rebase_source : c5fe91793b90f22dfeea0d05fd8730906d0ccdbe
extra : source : 3c5cea45aec424bee4043cd7d362e80aff9a491d
If the activity is restoring, onTabChanged might not be called.
To update title from existing Tab data in onResume.
MozReview-Commit-ID: 3LqQ6HDh7Dc
--HG--
extra : rebase_source : 1dd49658642be420d54d6a8e2d8c33e7658b0f2e
Now we can get toolbar color from intent directly, and the intent will
be stored in `onSavedInstanceState`. Let's get rid of the local
variable.
MozReview-Commit-ID: OsqwgFJctH
--HG--
extra : rebase_source : a5cd688de88de564739481f77fe514bdeffd6c0e
`getIntent()` not always returns the intent whith start this Activity
due to GeckoApp.onCreate reset it. We make a copy here in case of this
activity is destroyed and re-created.
MozReview-Commit-ID: 7TF3b1WdbM2
--HG--
extra : rebase_source : 60bab715166fd01b1fc89ca149e7f5a0f94e6bd1
Promise based MediaDataDecoder expects one response per request, but ICodecCallbacks was not designed that way. onInputExhausted() is called only when there are none or just a few input buffers waiting to be queued, and onOutput() is called as soon as output buffers are available. It means these 2 kinds of events are usually interleaved and hard to align with pending promises. Reporting each input buffer status makes it easier for RemoteDataDecoder to resolve promise properly.
MozReview-Commit-ID: K09txmHTtmX
--HG--
extra : rebase_source : 9ad331c54a24eab6ce5e0195f354afce52247572
Confusion between storeDone() and storeDone(long end) resulted in certain sessions (bookmarks
and form history) not overriding the current method. As a result, their final "flush the queue"
methods weren't being called by the buffering middleware.
This patch removes the storeDone(long end) method, making such confusion a non-issue.
Given that a lot of sessions tend to build up buffers which they need to then flush after a storeDone()
call, passing in a timestamp into that method doesn't make sense. Instead, let's supply a default
implementation in RepositorySession which calls onStoreCompleted(endTimestamp) with current time,
and allow sessions to override this method and own the onStoreCompleted(endTimestamp) call.
MozReview-Commit-ID: 84o7aAL8RPC
--HG--
extra : rebase_source : 41767ad502bd5ad8a0a487235bfdca8cf0d0c927
To observe the difference, use `javap -l`. For example, for
automationRelease and automationDebug built with `./mach gradle clean
app:assembleAutomationRelease app:assembleAutomationDebug`, I see
locally:
$ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/release/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class
Compiled from "ActivityStreamContextMenu.java"
class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> {
final android.view.MenuItem val$bookmarkItem;
final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0;
org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem);
LineNumberTable:
line 103: 0
<snip>
}
$ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/debug/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class
Compiled from "ActivityStreamContextMenu.java"
class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> {
final android.view.MenuItem val$bookmarkItem;
final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0;
org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem);
LineNumberTable:
line 103: 0
LocalVariableTable:
Start Length Slot Name Signature
0 16 0 this Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu$1;
0 16 1 this$0 Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu;
0 16 2 x0 Landroid/os/Handler;
<snip>
}
MozReview-Commit-ID: 3HmiGkHhowQ
--HG--
extra : rebase_source : c84d8d4b8ac813e49db0c61a30c7098ff2eae3f4
Since we're uploading records atomically, order in which they're processed by the uploader
only matters if we want to do sanity checks on certain types of records. Server might still
preserve some of the order, but for our purposes here it shouldn't matter.
We'd like to ensure that we process the "mobile root" bookmark record along with other folder
records first, so that we increase our chances of avoiding making a failing network request if
that those records' payload is too large.
Sorting by bookmark type achieves this.
MozReview-Commit-ID: KrAs3zepaOk
--HG--
extra : rebase_source : 24f1d3d6aa2ee3b6777dc38abdd1e01aba5213c2
If we try to upload a record whose payload BSO field is larger than the limit specified
by the server, fail that record during BatchingUploader's processing.
Consequently, Synchronizer will fail current sync stage and advance to the next.
Previous behaviour was to essentially rely on the server to fail our POST request,
at which point we'll fail current sync stage. So in a way, this is an optimization to
avoid making network requests which we know will fail.
MozReview-Commit-ID: 5aJRRNoUuXe
--HG--
extra : rebase_source : 18920cfe7b7599be1984c53ebc0c9897c98fb7d9
Also rename Wikipedia Belarusian for consistency
MozReview-Commit-ID: DDtmwrG3sU5
--HG--
extra : rebase_source : 4dcec3ac19f421098f1ed9e9e33a1b13014c745e
The shared preferences keys used for storing/retrieving the activity list data are constants, so it is a bit disconcerting to see them named like normal member variables.
MozReview-Commit-ID: GivVloU0pFv
--HG--
extra : rebase_source : e26bcabd1cdf549e8a0ee54f0e6333c76484ca24
We need to access sessionToken in the Engaged state in order to perform device
registration. We expose getSessionToken() on the base State class, to allow
customers to get the sessionToken easily instead of having to downcast the
TokensAndKeysState/Engaged states.
MozReview-Commit-ID: 8s2C350noUG
--HG--
extra : rebase_source : e0bc8bf7ebfdcb7a31bb4a6ddb5b928acf7baba9
If user long click text area of ActionBar(URL or Title), then copy
current URL to clipboard.
MozReview-Commit-ID: EdVoMiX0Gt3
--HG--
extra : rebase_source : eecd78325162bb5c0a41436b90d0e10f5669030c
This assumes that the observed test failure was caused by the async file delete triggered by the history sanitisation in test_sessionStoreClearTabHistory being somehow delayed long enough to only take place after we had already started test_sessionStoreClearFiles.
MozReview-Commit-ID: FenpPyb4sGZ
--HG--
extra : rebase_source : 3f14e1053b043a03aac1680ee56483243b5a4045
CLOSED TREE
Backed out changeset 4ac559eea9ec (bug 1348803)
Backed out changeset 2ab6e0b8aec6 (bug 1348803)
Backed out changeset f966aef934b1 (bug 1348803)
Other events in browser.js are all lower case letter, also change these two to make them consistent.
MozReview-Commit-ID: LkzYUo6OrEA
--HG--
extra : rebase_source : 8b134332e32cae29a1f963e604f2507433c694b8
We could register media control related event after the tab has active media.
But we still need to register "audioFocusChange" in the beginning, because it
affect every tab even the tab has no active media.
MozReview-Commit-ID: 4pBKIR8F5tV
--HG--
extra : rebase_source : fc26c98ed7b33552b4eba5b20168394b1b1a4390
This patch affects all grided tabs panel layouts: tablets, phones in landscape
mode, and phones in portrait mode with the "Compact tabs" setting on.
MozReview-Commit-ID: 5cqVJA57ARu
--HG--
extra : rebase_source : c71d4e028bcef921f6a2725d14aaf27940d87f5e
Layer on the hacks! This:
1) Reinstates the <activity-alias android:name=".App"> that we have in
the moz.build produced Android manifest. I found no way to do this
using placeholders or the manifest merger.
2) Culls manifest entries provided by
com.google.android.gms.measurement. We know they're not necessary,
since they're not present in the existing Fennec Android manifest.
These are strictly workarounds to avoid doing the real work of fixing
the issues. To fix 1), we'd need to migrate all existing users with
homescreen shortcuts to .App. This could be difficult, especially if
partners have deployed packages out of our update control. To fix 2),
we'll need to upgrade our Google Play Services to at least version
9.0.0 and then use the finer-grained AAR dependencies to not build
with the measurement split at all.
MozReview-Commit-ID: 21CaZ2KMeIa
--HG--
extra : rebase_source : c45694814145946425031064cf59d3b863d3bde4
__Device_Configuration__|__o_Applied_Style_______________
ldrtl-v17 v17 v15 |
o o o | UrlBar.Entry
\ | | |
-----o | | UrlBar.V17.Entry(start/end)
\ | |
\ o | UrlBar.V15.Entry(left/right)
\ | |
--o | UrlBar.Base.Entry(original style)
Though Android support RTL since API level 17(JB_MR1), it's really buggy at that moment.
This patch fix a severe UI layout attribute bug, which only happen on android 4.2 in RTL language context:
If view attributes "start/end" and "left/right" are both written in a view layout xml, they will both be applied and cause UI abnormal. In API 18 and above, "left" will be ignored if "start" also exist.
For example, as below show, alignLeft and alignStart are both exist in ImageView. On android 4.2 with RTL context, it's width will both align Left and Start(Right), cause the symptom that ImageView have the same width and cover on the view "back."
```
<ImageView android:id="@+id/url_bar_entry"
android:layout_alignLeft="@+id/back"
android:layout_alignStart="@+id/back"
```
MozReview-Commit-ID: JptLuWX2w15
--HG--
extra : rebase_source : ef89a31f77f56f6f4e936e20644c243abfa7239f
Change filter_py to only report on toolkit files referenced in
mobile/locales/jar.mn.
We ignore netwerk, security/manager, devtools/shared, services/sync
on the module level.
MozReview-Commit-ID: 4YRwZHUD1gE
--HG--
extra : rebase_source : 2613456c9c3442ba2d27468fdc106c1778273f6f
This commit adds a check for not prompting the user in case
the permissions have already been granted for accessing
file:// uris
MozReview-Commit-ID: A62AUqqTJSb
--HG--
extra : rebase_source : c5109c2fede109e1942cce240e26b12a220e8574
Generate a separate omni.ja for GeckoView during the packaging step,
under dist/geckoview. Define a MOZ_GECKOVIEW_JAR flag to optionally
include/exclude files in the package manifest.
Once user click "Open in browser" from menu, we are going to open a tab
in full browser, and close this activity. Therefore we won't have two
tabs which confuse user.
MozReview-Commit-ID: Co9gAdWweFX
--HG--
extra : rebase_source : 2f8f783783491ef480ca5266268d9d3b21bcab23
I can't remove the throbber.png itself because about:performance is
using it.
MozReview-Commit-ID: 6xqAqROptG4
--HG--
extra : rebase_source : 817981ed534800d646ce4decf3e69fff96e3e9fc
Expand the existing test by navigating to a different page and then going back after the tab has been restored again.
Proper restoration of the zoom level for anything other than the current history entry depends on resolution of bug 1312605.
MozReview-Commit-ID: Aspg2RRcY53
--HG--
extra : rebase_source : 4c70ebc82c682878506005007798db4fda0a613e
Just as the comparable test on desktop we should use a really big document with enough space for scrolling in both Y *and* X directions. We should also randomise the scroll positions used for testing instead of hardcoding them.
MozReview-Commit-ID: 9FvaOnaKJ6
--HG--
extra : rebase_source : af57219a92a7ad84a58c186fde9bd4c60ef16a76
We are going to need this in the future and starting collection even before releasing
Activity Stream will create a better experience once we turn it on.
And this flag is hard to miss. So let's just get rid of it.
MozReview-Commit-ID: 5oDzXhpQdSA
--HG--
extra : rebase_source : c96800257070af9287d5236625150dbb62985c4b
This is a bit complicated. But most of that code should go away again as soon as
we can stop shipping the opt-out preference.
With this patch we have three flags that can be controlled via Switchboard:
* activity-stream: This is our global kill switch and allows us to pull the feature
if needed. A user has to be in this experiment to ever see activity stream. The
goal is to enable this experiment for 100% of the Nightly audience.
* activity-stream-opt-out: This is experiment will enable the Activity Stream by
default. The goal is to enable this experiment for 50% of the Nightly audience.
* activity-stream-settings: This experiment controls the visibility of a setting
to enable/disable activity stream (settings -> advanced -> experimental features).
This allows us to control whether users can opt-in or opt-out of the activity
experiment. The goal is to enable this for 100% of the Nightly audience.
MozReview-Commit-ID: BwEoTK6QMQx
--HG--
extra : rebase_source : dbe9815127c1aa620bbc2f1623aa4726438d3285
It's not used anywhere in gecko or addons. Remove it will make
removing PScreenManager easier.
MozReview-Commit-ID: K3BHnktO7wU
--HG--
extra : rebase_source : 6f481759d1fb82d222ea6a92ebfd50dbb6cb63d5
Media control would also be displayed for non-audible media, we shouldn't
arbitrary request audio focus . Only request audio focus from gecko which know
whether the media is audible.
MozReview-Commit-ID: Ke9DCYd0Qh2
--HG--
extra : rebase_source : 6ca2f83de877495f7249ee5e7f5cf2165f6f7f6b
This means scaling the the size of the images used for buttons and making sure that at large magnifications, the toolbar's text input properly moves into its own line instead of simply overlapping the preference immediately below. We also want to make sure that the text on any buttons remains vertically centred.
MozReview-Commit-ID: 7rUf1tucAzL
--HG--
extra : rebase_source : d227729955d15bc74d7502e116d0e71b97d76828
A basic check that the listener is indeed operational.
MozReview-Commit-ID: 6KijcsRaScI
--HG--
extra : rebase_source : c999d7bd78101f16efffedbfddbce89c83b39f9c
We can use this function for our upcoming test as well, so we should move it into the common header.
MozReview-Commit-ID: H5ANDAlnpmm
--HG--
extra : rebase_source : 9d873d45ec7f701bc993e3b5f676c0638d58656d
The state of the switch added in Part 4 is stored in our Android-side shared preferences. For this to have any actual effect on rendering, we now add a class that is initialised when Gecko starts up and listens to changes of that particular pref.
When it is turned on, we enable font inflation and add another listener for the system font scale, which then forwards the current font scale as well as any changes to Gecko, so mobile mode pages can be scaled correspondingly as well.
When the setting is turned back off again, the system font scale listener is stopped again and the Gecko font size settings reverted back to their default values.
MozReview-Commit-ID: GyffpZTQQX8
--HG--
extra : rebase_source : 23fcadbf04505f78ff1531c5d3c212d4f98eab9e
After landing bug 1300884 and B2G is dead, Web Alarm API is removed. So we should remove Android backend for Alarm API. This implementation was for B2GDroid.
MozReview-Commit-ID: ItmjOQrVSgs
--HG--
extra : rebase_source : 1844b81c515c043245c9bed034698a1904f03286
Merge "DOMServiceWorkerFocusClient" & "DOMWebNotificationClicked"
to "DOMWindowFocus" event. Utilize the event to switch tab when
loading links to an existing target tab.
MozReview-Commit-ID: Hd1NkVkrJA1
--HG--
extra : rebase_source : 745c0d66c3afd8e487c616891c0f10bd820da1fe
If 3-rd party app specify to use tint for Action Button, use primary
text color as the tint color for Action Button.
MozReview-Commit-ID: 3sX0MH8P0dM
--HG--
extra : rebase_source : a50256dd16675f2a329eb182c6aed9e564386315
This patch changes the crashreporter client code as well as the crash service
code to compute a SHA256 hash of a crash' minidump file and add it to the
crash ping. The crash service code computes the hash on the fly before handing
over the crash to the crash manager; the crash manager will then add it to the
crash ping. The crashreporter client on the other hand sends the hash via the
ping it generates but it also adds it to the event file so that the crash
manager can pick it up and send it along with its own crash ping. On Fennec
the crashreporter activity takes care of computing the hash.
SHA256 hash computation uses nsICryptoHash in the crash service, the
java.security.MessageDigest class in Fennec, the bundled NSS library in the
crashreporter when running on Windows and Mac and the system-provided NSS
library under Linux. The latter is required because the crashreporter client
uses the system curl library which is linked to NSS and which would thus clash
with the bundled one if used together.
This patch introduces two new methods for the nsICrashService interface:
|getMinidumpForID()| and |getExtraFileForID()|, these reliably retrieve the
.dmp and .extra files associated with a crash and ensure the files exist
before returning. These new methods are used in the CrashService for
processing and will become the only way to reliably retrieve those files
from a crash ID.
MozReview-Commit-ID: 8BKvqj6URcO
--HG--
extra : source : a4d8291c56fcde00238ab3166bbe6af6dd602340
To gauge the impact of bug 1343995 on perceived shutdown times, we want to measure how long sanitising actually takes in practice on Android.
MozReview-Commit-ID: 3gSfT8IoO70
--HG--
extra : rebase_source : 19ffdfbf1005ae4beebaa0c9d8befea31e1aa01f
This'll allow customising context menu/session store/... behaviour in Gecko depending on the tab type, since in the future we might not only have special behaviour for custom tabs, but for web app tabs etc. as well.
MozReview-Commit-ID: LS6oGfO4KpR
--HG--
extra : rebase_source : 677a013a05cc683cae82c84864509d8f4799b474
Custom tabs etc. shouldn't show up in the main browser activity.
MozReview-Commit-ID: 1yrLZP6HJ3e
--HG--
extra : rebase_source : 6f3a1b8149d4747ef665f1a90a589940d12526a9
We always want at least one browsing type tab open to match current behaviour and assumptions built into the app, but the same doesn't hold true for other tab types. A CustomTabActivity instance e.g. only holds a single tab, so the lifetime of the tab is tied to the lifetime of the CustomTabActivity. If we're exiting the activity, we just want to close the corresponding tab without opening a new replacement for it.
Since we have to select some other tab instead in that case (so the selected tab in the tab list and the selected tab in Gecko remain in sync and so we always have a selected tab), getNextTab() therefore has to fall back to browsing-type tabs as a default if no other tabs of the same type are available.
MozReview-Commit-ID: IpvINlu5Qq9
--HG--
extra : rebase_source : 6b934209c06dd8ed2b199f92a768a37c028bb689
As long as the tabs are opened in the same Gecko browser window, splitting the Java UI tabs list into multiple parts breaks too many assumptions, so the easier solution is to allow setting a type attribute on each tab object, which will allow filtering of them later on.
MozReview-Commit-ID: 1PbxMkWTK47
--HG--
extra : rebase_source : ea7b82271b681e04590046a1d5cf9c2230729781
To add a progressbar to CustomTabsActivity then user knows page loading
progress.
MozReview-Commit-ID: L1Qc7Oj81bZ
--HG--
extra : rebase_source : c55813f271d3bbdaacf485809290c935d2b6ef7b
No need to create id resources for common widgets in each activities, e.g.
toolbar. Reuse id resources to make less ambiguous when invoking `findViewById`
In BrowserApp and CustomTabsActivity, both of them have ActionBar and
Progress-Bar. Let them use the same id resource.
MozReview-Commit-ID: 2jq18dwlBlm
--HG--
extra : rebase_source : 7d8d2bcb3da6969b1471e267527f27ea1bbeaab7
We upload meta/global in three scenarios:
- fresh start
- when it was modified after a successful sync
- when it was modified after an aborted sync
Use X-I-U-S header to assert what we believe about meta/global's presence (during freshStart)
and last-modified timestamp (in all other cases).
We might encounter a concurrent modification condition, manifesting as a 412 error. If we see such an error:
- on fresh start, we restart globalSession
- on regular upload, we request a re-sync of all stages
MozReview-Commit-ID: 3qyb6rUSOeY
--HG--
extra : rebase_source : 166be44aceb634b4e9fa3a8e20f7047cfec2af54
Similiar to GeckoApp, once user click icon in ActionBar, it displays
a popup menu for site identity.
MozReview-Commit-ID: LpvhFjx2BSk
--HG--
extra : rebase_source : 6771f9d2b50da26306222072aa85d42b26a3ebce
If there are multiple SiteIdentityPopup instances.(ie. in GeckoApp and
in CustomTabsActivity), each instances will start receiving events once
attached to window. However it might have not call init() yet.
MozReview-Commit-ID: 1dIAUOTeTLg
--HG--
extra : rebase_source : e38d5b734fc057e44b3fe8bba82c6aedbcf65dd4
The CustomView has three components
* Icon - for site info to indicate whether the visited site is security
* Title
* Url
Icon is for site info to indicate whether the visited site is security.
Its icon type is decided by SecurityModeUtil. All of the components' color
are the same as TextView color.
When onTabChanged happens, it updates CustView of ActionBar to reflect
current site security status. Sometimes the callback will be invoked rapidly
several times in very short time. To avoid icon twinkle, to add a delay when
updating CustomView.
MozReview-Commit-ID: KCu3XLObmmV
--HG--
extra : rebase_source : 4f2ad2517124b59168b6d6b5149800b4be4bd5a9
Designer provides a color code as default background color for
ActionBar.
Also get rid of `NO_COLOR`: -1 equals 0xFFFFFFFF, so it always ignores
white color.
MozReview-Commit-ID: 6YJDxsSOhkZ
--HG--
extra : rebase_source : f0c7e5f3d004eff2df557b4b6f448a534718384f
Translucent color cause some rendering problem in Toolbar. For example,
if we set translucent color to toolbar and changes title, we will see
new title convers the old-translucent title.
Since ActionBar is usually on the top and nothing behind it, it does not
make sense use translucent color as its background.
MozReview-Commit-ID: LdZyuYZ7IgX
--HG--
extra : rebase_source : 5839a1ef14c28dc75f55772c3209b334b4b8391a
ActionBar of CustomTabsActivity is getting complicated. There will be
more components in ActionBar, such as Site-identity-icon.
Move some action-bar related view code to another class.
MozReview-Commit-ID: I5sOSCQKnlv
--HG--
extra : rebase_source : 6822593af92c657c496339ba8df7769ea463c681
Merge "DOMServiceWorkerFocusClient" & "DOMWebNotificationClicked"
to "DOMWindowFocus" event. Utilize the event to switch tab when
loading links to an existing target tab.
MozReview-Commit-ID: Hd1NkVkrJA1
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue. GeckoThread.waitOnGecko is changed to wait on
both the widget queue and the XPCOM queue. nsAppShell::SyncRunEvent is
changed to avoid a possible deadlock condition involving locking
sAppShellLock twice.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative. As a rule, disposeNative is dispatched to the queue with
the least priority among the queues that other native members of the
same class dispatch to (i.e. "gecko_priority" if all other native
members dispatch to "gecko_priority", or "gecko" if any native members
dispatch to "gecko").
Bug 1344892 - 3. Update auto-generated bindings; r=me
Use the global EventDispatcher for signaling update results. The event
listener in about.js must be unregistered after every event to prevent
memory leaks, so expectUpdateResult() is added and called whenever we
are expecting update results.
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative.
Bug 1344892 - 3. Update auto-generated bindings; r=me
Wes Kocher
Eugen Sawin
Francesco Lodolo (:flod)
Nick Alexander
Sebastian Kaspari
Sebastian Hengst
Dylan Roeh
Geoff Brown
Joel Maher
L10n Bumper Bot
Carsten "Tomcat" Book
Delphine Lebédel
Nevin Chen
Nitish
Julian_Chu
Jim Chen
nechen
Dale Harvey
Phil Ringnalda
Michael Kaply
James Willcox
Tom Klein
Tomislav Jovanovic
John Lin
Iris Hsiao
maliu
Grigory Kruglov
Kris Maglione
Munro Mengjue Chiang
Jan Henning
Ehsan Akhgari
Jim Porter
Ralph Giles
Ryan VanderMeulen
Edouard Oger
Alastor Wu
Valentin Gosu
brainbreaker
Florian Queze
Timothy Guan-tin Chien
Kan-Ru Chen
Andrew Swan
Makoto Kato
Matthew Wein
Samael Wang
Gabriele Svelto
Jing-wei Wu
Zibi Braniecki
Alphan Chen
Dão Gottwald