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
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
3rd-party app could ask to add default share item to menu, and share
the data url to other activities if user click the share-menu-item.
MozReview-Commit-ID: HkDyENJtFn9
--HG--
extra : rebase_source : 2312d7d0fcab7a7c45933bded7f173aface9912c
If 3rd-party app provides any custom menu items, add them to PopupMenu
and handle corresponding pending intent.
MozReview-Commit-ID: 5STg49hsCWF
--HG--
extra : rebase_source : 34240988a8b89bacb8baef206cf9bf9f93dbf8ef
Besides custom-menu-items from 3-rd party apps, we designed a custom
menu which always has
* buttons for Forward, Reload
* One menu item for 'Open by Firefox'
* a footer 'Powered by Firefox'
This patch adds a button as an anchor to standard menu. Once user click
it, to show a custom menu (GeckoPopupMenu) base on the anchor.
In current design, there is only one style for menu, regardless of Dark
or Light theme.
MozReview-Commit-ID: 5RMiGDlxLTU
--HG--
extra : rebase_source : 0d867d1b2aa4fd72dbf4eda14ab3ed5ce841f9cc
CustomTabsActivity is usually be used by 3rd-party apps. Its look and
feel is usually different from GeckoApp. To give separated themes to
ensure any change to CustomTabs won't effect GeckoApp.
MozReview-Commit-ID: 7aBnnPXv3nQ
--HG--
extra : rebase_source : 019778cdadbe1ec6239e85e0fae1e873f453edcd
Menu items in CustomTabsActivity are static. Not necessary to create
items several times. However `onPrepareOptionsMenu()` will be called
before menu is shown.
Cannot use `onCreateOptionsMenu()` due to GeckoApp overwrited
`onCreatePanelMenu()` and pass different instance to sub-class. Since
CustomTabsActivity does not use custom menu, just overwrite
`onCreatePanelMenu()` should be safe.
MozReview-Commit-ID: 2oTN85GurqS
--HG--
extra : rebase_source : 3006b661eefab1cf191db6f9a660a7a618f4cb12
Look for omni.ja to copy from in dist/fennec and in dist/fennec/assets,
but throw an error if we find multiple copies of omni.ja that are
potentially conflicting.
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
On startup and at the beginning of a sync we check how long it has been since we've subscribed
to a channel for fxa service. If it's been over 21 days, request re-subscription.
MozReview-Commit-ID: GzvPecZ9hTy
--HG--
extra : rebase_source : d0292acddbdd231502808469d4e5502a4ac93779
Although regression window testing pin this to bug 1260276, I believe
this is a regression from bug 1126967. Bug 1260276 just make it more
visible because we stop automatically redirect users to the original
page.
This patch fix the bug by checking if the current page is in readerable
state (i.e. not error state), and send the message accordingly.
MozReview-Commit-ID: B5UJcPvVlAc
--HG--
extra : rebase_source : 630347e1f4256550857d84bc6e8a30036b114362
TabsPanelComponent and TabStripComponent share a lot of functionality, so factor
out TabsPresenterComponent.
MozReview-Commit-ID: Gnbo8gvowj6
--HG--
extra : rebase_source : 5f6738723893ac055354aafd7e872686598c0a8b
The tabs tray is drawn on top of the tab strip, not instead of it, so the tab
strip needs to be updated after tabs are moved in the tabs tray before the tab
strip becomes user-visible again.
This introduces a slight change in behavior: *if* a move (of a tab matching the
privacy state of the tab strip) occurs while the tabs panel is open, the tab
strip will be scrolled to the currently selected tab when the tabs panel is
closed - previously the tab strip maintained its old scroll position if a tab
wasn't closed or added while the tabs panel was open.
MozReview-Commit-ID: Ipy5huthNYB
--HG--
extra : rebase_source : e7a3432cdad104b3cec45eeb798f239ae08dd9b9
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
Session store will be notified in the next patch.
MozReview-Commit-ID: APTJykdnMF2
--HG--
extra : rebase_source : f3cdd3e5529f470834c32d6ae2289a6d272cba67
Every way I've tried to move a browser in the deck results in the browser being
reset (it loses its docShell and contentDocument). So now we treat
deck.children as a set of browsers instead of a list, and make BrowserApp._tabs
the sole keeper of the user visible tabs list order. That means
deck.selectedIndex should no longer be used to get the user visible index of the
currently selected tab (deck.selectedPanel is still valid), and that all
additions to deck can be appends.
Note if this gets reverted at some later date: there's currently a bug, which
this change renders moot, where we reinsert a close-undo tab correctly in the
_tabs list, but incorrectly append it to the deck instead of inserting it.
MozReview-Commit-ID: Id7FR1p1nfN
--HG--
extra : rebase_source : 1506f513e653c67d066601fb9038bee098be9479
A cache to remember the position of the tab that was just moved will be added in
the next commit.
MozReview-Commit-ID: 5V4FSpcJ69Z
--HG--
extra : rebase_source : b81d9f4de6d72244ec314d8edf27397fbe601668
Future commits will update the tabs lists in Tabs and gecko; for now we're just
updating the TabsLayoutAdapter list.
When considering some of the changes in TabsTouchHelperCallback, note that
TabStripView uses the new drag and drop, but not swipe to close.
MozReview-Commit-ID: EEseqmVIZmY
--HG--
extra : rebase_source : 779b8ac3f0f9b7b57f9932205890b564aea86d9d
extra : source : 54bfd72900af26472346f75f9fe50334ed273481
The session store keeps a serialised copy of a tab's session history around so that the gathering of the data (which can be somewhat expensive) can be decoupled from writing it to disk.
When the user clears Firefox's history, we therefore need to discard this data as well (except for the currently open entry), so it doesn't stick around until the next time some navigation/history change occurs in that tab. Otherwise, if Firefox or just the tab is closed before the purged state has been re-collected by the session store, the supposedly purged session history will resurface when the tab is restored again.
Bug 1337940 means that we'll now catch the history notifications caused by the session history being purged, however
- we still need to handle zombified tabs separately, since as far as the rest of Gecko is concerned, those simply consist of a plain "about:blank" browser with the true state being stashed away in the session store data, so the purging of the live session history data won't have any real effect
- the history purging on the tab happens after the session store receives the "browser:purge-session-history" notification, meaning that these changes received through the regular history notifications won't get written to disk immediately
Therefore we now explicitly purge the session history data of all tabs in our notification handler, so this state can then immediately be saved to disk.
MozReview-Commit-ID: KkR0Tif9BBk
--HG--
extra : rebase_source : 5744c88e2871cd873e2484e9688deb53bf8d44f2
It's easy to get a tab's browser, but going the other way round requires always calling getTabForBrowser(), which then additionally has to search each open tab in turn to find the tab with the matching browser.
Also, the browser won't survive tab zombification, so for Part 3 we'll have to start keeping a reference to the tab object anyway.
MozReview-Commit-ID: B2aC7vB0cuj
--HG--
extra : rebase_source : 233b6deec58c0c47640e8a0b597d77324ce66963
Delay-loaded tabs all have browsers pointing to about:blank, so there's not much sense in querying browser.currentURI for them. Instead we read their session data to determine the correct URL, which allows selectOrAddTab to successfully detect duplicate tabs even when they are zombified.
MozReview-Commit-ID: JZ179Y85Ehe
--HG--
extra : rebase_source : bc34d34d501a994ce989c27858cc529b78b5ae3d
Fennec's session store code was forked from Desktop a few years ago. Since then, the Desktop session store code has been refactored and modularised, which allows us to pull in again the bits the are compatible with our session store architecture and don't require any mobile-specific handling.
The handling of session history is such a case - with the exception of the "wyciwyg" filtering, any differences between SessionHistory.jsm and our equivalent in sessionstore.js seems to stem from Desktop bugfixes that were never ported over to our copy of the code.
Switching Fennec's session store over to use SessionHistory.jsm will prevent those sort of errors from occurring again in the future and hopefully simplify the maintenance of the session history code going forward.
MozReview-Commit-ID: Hm0TWTwtPsI
--HG--
extra : rebase_source : 5935c7baeefbd2c75754fe609b684aaf40ee85e9
When we detect text being deleted from the URL bar via setComposingText while we're displaying an autocomplete suggestion, we clear the autocomplete text and prevent the keyboard's delete from having any effect on the URL bar by returning false.
Some keyboards might not handle this correctly and assume that they've in fact successfully set the new text, so the next time the user presses a key can lead to weird behaviour. As a workaround, we therefore additionally restart the input for affected keyboards.
MozReview-Commit-ID: DucveafL3AB
--HG--
extra : rebase_source : 3ba1701adf7e4e8a03d263a75c04717aadaab663
Clearing history purges a tab's session history as well. Normally, we only update the navigation button state in the UI for a location change, so now we need to start listening for the appropriate message as well.
BrowserApp has already registered a background thread listener for "Sanitize:ClearHistory" - since this can be called during shutdown as well and their listener is more important (clearing the history DB), we defer to them and redispatch to the UI thread ourselves, so BrowserApp doesn't have to do this during shutdown.
MozReview-Commit-ID: C83mk6Z56Oq
--HG--
extra : rebase_source : 6dc40b1ff816b373783afa6bd34546a961e75571
BrowserApp's sanitize() function assumed that the Sanitizer would return promises for each sanitization handler, so it could wait for them to resolve before proceeding with shutdown (which was also the assumption behind the patch for bug 1266594). In fact even the Sanitizer expected to do this is well, since it wrapped each of its handling functions within a promise/task/sendRequestForResult. However it turns out that Sanitizer's clearItem function then failed to actually return this promise - apparently ever since this was implemented.
MozReview-Commit-ID: 6hN3UTXUIuV
--HG--
extra : rebase_source : 4971bc02962c817037a565595d3c1cedb0532d76
Bug 1339685 - 1. Support compiling GeckoView aidl from multiple packages; r=nalexander
Specify a list of AIDL files for GeckoView so we can include AIDLs from
multiple packages, and not just those from the org.mozilla.gecko.process
package.
Bug 1339685 - 2. Add AIDLs for GeckoEditable; r=esawin
Add IGeckoEditableParent.aidl and IGeckoEditableChild.aidl for two-way
communication between the parent, which lives in the main process, and
the child, which lives in the main process or a child content process.
Bug 1339685 - 3. Refactor some GeckoEditable code; r=esawin
Auto-generate native constants for the constants in GeckoEditableClient,
instead of keeping a separate set of constants in native code.
Bug 1339685 - 4. Add GeckoEditableChild; r=esawin
Add the GeckoEditableChild class, which is currently only used in the
main process as the interface between the native nsWindow and
GeckoEditable. Eventually, it will be expanded to child content
processes as the interface between the native PuppetWidget and
main process GeckoEditable.
Bug 1339685 - 5. Use GeckoEditableChild from GeckoEditable; r=esawin
Make calls to GeckoEditableChild from GeckoEditable, and remove code
that exists in GeckoEditableChild from GeckoEditable.
Bug 1339685 - 6. Add GetNativeObject member to proxied native calls; r=snorp
Add a convenience function for getting the C++ object that is the target
of the native call.
Bug 1339685 - 7. Use GeckoEditableChild from native code; r=esawin
Make nsWindow and GeckoEditableSupport use GeckoEditableChild for
communication. nsWindow still keeps a reference to GeckoEditable for
switching views.
Bug 1339685 - 8. Updated generated bindings; r=me
This patch has multiple changes folded into:
* Remove old highlights query
* Add new query for retrieving recent history to consider for highlights
* First version of highlights ranking implementation
* Add new loader implementation that will return a list of Highlight objects instead of a Cursor
* Modify UI code to work with Highlight objects instead of a Cursor.
MozReview-Commit-ID: Pdx2YxrZKA
--HG--
extra : rebase_source : 495bd97e40270fb15c05d5b5f511d5dcf89fbd1b
Bug 1137567 - 1. Allow dispatching key events during composition; r=esawin
We potentially dispatch key events during composition to provide
compatibility for pages that only listen to key events.
Bug 1137567 - 2. Allow keyboard events in DispatchInputEvent when not on APZ thread; r=rbarker
We use nsIWidget::DispatchInputEvent to dispatch our keyboard events on
the Gecko thread, which on Android is not the APZ controller thread. We
should allow these events to pass instead of crashing.
Bug 1137567 - 3. Add GeckoEditableSupport class to support TextEventDispatcher; r=masayuki
Add a separate GeckoEditableSupport class, which implements
TextEventDispatcherListener and uses TextEventDispatcher for IME
operations. The new class is entirely separate from nsWindow to allow it
to be independently used in content processes as well.
Most of the code is copied from nsWindow::GeckoViewSupport, and adapted
to use TextEventDispatcher.
Bug 1137567 - 4. Make nsWindow::WindowPtr available for outside classes; r=snorp
Make nsWindow::WindowPtr available not just for classes inside nsWindow
but for outside classes as well. Also, add support for RefPtr native
objects to nsWindow::NativePtr.
Bug 1137567 - 5. Use GeckoEditableSupport in nsWindow; r=esawin
Use the new GeckoEditableSupport class in nsWindow to replace the
previous code in nsWindow::GeckoViewSupport. GeckoEditable native
methods now go to GeckoEditableSupport instead of GeckoViewSupport.
Several native methods in GeckoEditable are changed from
dispatchTo="proxy" to dispatchTo="gecko", because we no longer need the
special nsWindow::WindowEvent wrapper for our native calls.
Bug 1137567 - 6. Use pushPrefEnv in test_assign_event_data.html; r=masayuki
setAndObserveCompositionPref in test_assign_event_data.html does not
invoke the callback if the pref is already set. This patch changes it to
use SpecialPowers.pushPrefEnv so the callback is always invoked.
We used to scroll in addTab to make sure a new tab created by a close-tab-undo
at the start or the end of the list was made visible instead of staying where it
was created off the edge. We're now taking care of that in selectTab (where it
should have stayed in the first place), where the select in that case occurs
between the time when the new tab is added to the adapter and when the layout
gets updated. In the case where the new tab is at the start, that means the
check 'position < layoutManager.findFirstCompletelyVisibleItemPosition()' in
selectTab reads '0 < 0', which fails (which is why we need the new check for
'position == 0'), but the check 'position >
layoutManager.findLastCompletelyVisibleItemPosition()' for a tab added at the
end reads 'new_lengh -1 > old_length - 1' which already passes, so we don't need
a special case for undo-tab-close adds at the end in selectTab. Tabs added at
the end by a normal "create new tab" still scroll for the same reason.
Robotium was confused by the duplicate 'add_tab' ids from the tab strip and the
tabs panel, so I renamed one of them. Also note that the 'getTabId' added to
TabStripItemView for testing already exists on TabLayoutItemView, but the two
classes don't share a common base.
MozReview-Commit-ID: BzG2r8BSs90
--HG--
rename : mobile/android/tests/browser/robocop/src/org/mozilla/gecko/tests/testTabStripPrivacyMode.java => mobile/android/tests/browser/robocop/src/org/mozilla/gecko/tests/testTabStrip.java
extra : rebase_source : b2859647d9e26cdca24e1b03065d3c62e20f7b1b
extra : source : 119ee2655404e277c13d0e436fba1cad1272797e
For a fresh profile it is expected that there are no session files to restore from, however afterwards we should normally always have a valid - if possibly empty - session file available. We try excluding the first run case by checking the first run pref used by Telemetry so far and see whether we get any reasonable results out of this...
MozReview-Commit-ID: 2ZxmLqwhk32
--HG--
extra : rebase_source : 6e76cad14017aced2e4b5f00b8c385dc544529bf
This pref could be useful for things outside of the TelemetryCorePingDelegate as well, so we have it live in GeckoApp now.
MozReview-Commit-ID: 2JZ3vNqSzcl
--HG--
extra : rebase_source : 0cf6d4f799a705d4e47be89de409925079bf661b
More JPZ leftovers, I presume. In any case what's left doesn't do anything really useful and a DXR search didn't reveal any remaining users, so this can be thrown out.
MozReview-Commit-ID: 9dN6Jifpbvw
--HG--
extra : rebase_source : 04614d729a55e00c5331ecc321ca2ef5b5e73747
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
BatchingDownloader uses provided RepositoryStateProvider instance in order to track
offset and high water mark as it performs batching.
The state holder objects are initialized by individual ServerSyncStages, and prefixes are used to ensure keys
won't clash.
Two RepositoryStateProvider implementations are used: persistent and non-persistent. Non-persistent
state provider does not allow for resuming after a sync restart, while persistent one does.
Persistent state provider is used by the history stage. It is fetched oldest-first, and records are applied
to live storage as they're downloaded. These conditions let use resume downloads. It's also possible to
resume downloads for stages which use a persistent buffer, but currently we do not have any.
Offset value and its context is reset if we hit a 412 error; it is maintained if we hit a sync deadline, allowing us to
minimize number of records we'll redownload. BatchingDownloaderController owns resuming and context checking logic.
High water mark (h.w.m.) is maintained across syncs and used instead of stage's "last-synced" timestamp if said stage is
set to fetch oldest-first and explicitely allows use of a h.w.m. Server15RepositorySession provides correct timestamp
to RecordsChannel, decoupling BatchingDownloader from this logic.
MozReview-Commit-ID: IH28YrDU4vW
--HG--
extra : rebase_source : 63bd7daaa1fd2a63e10289d6d4cd198aaf81498b
Grigory Kruglov
Dale Harvey
Edouard Oger
Julian_Chu
Jan Henning
Phil Ringnalda
Alastor Wu
Tom Klein
Nick Alexander
Carsten "Tomcat" Book
Valentin Gosu
nechen
maliu
Delphine Lebédel
Wes Kocher
Michael Kaply
brainbreaker
Sebastian Kaspari
Jim Chen
Eugen Sawin
Nevin Chen
Kan-Ru Chen
Andrew Swan
Sebastian Hengst
Makoto Kato
Matthew Wein
Iris Hsiao
Samael Wang
Dylan Roeh
Gabriele Svelto
Jing-wei Wu
Tomislav Jovanovic
Florian Quèze
Geoff Brown
John Lin
Zibi Braniecki
Alphan Chen
Dão Gottwald
Dragana Damjanovic dd.mozilla@gmail.com
Mike Conley
Timothy Guan-tin Chien
Andrea Marchesini
Luca Greco
Randall Barker
suman
Tushar Saini (:shatur)
Ben Kelly
Alfredo.Yang
Kris Maglione
Krishna
Masatoshi Kimura