Not really happy about the change but it addresses the problem.
* Loading the list from disk is much faster than parsing the string (2500ms vs. 30-50ms on a Nexus 6P)
* Because of (potential) disk I/O we are required to extract the label asynchronously on a background thread
* We load the list only once and then keep it in memory - like we did before the change.
MozReview-Commit-ID: 9MPGbmIGRnS
--HG--
extra : rebase_source : 8b31f852c6bb90fd57baeb07ba0066421d5a6e46
We want functions without an @imports to not have any side effects, and
to not use external resources. So remove the few functions we expose from
os.path without @imports('os') that do.
--HG--
extra : rebase_source : a9485ec269d4de5785d66d7772eda4fae5a84b4a
For the short sound, we don't want to show the media control interface for them, eg. game effect.
Therefore, we check the media's duration to decide whether need to notify Java side "Tab:MediaPlaybackChange" or not.
MozReview-Commit-ID: 8PlQl2w2BSI
--HG--
extra : rebase_source : c4e5d38eae1dba22af268ea575dd6c9672e7cf9f
This seems to be a change and/or regression in the 23.4.0 support libraries, which results
in the drawable being treated as having no (or infintely small) bounds, and therefore
no drawable being shown on screen. This workaround is only needed on Android <= 4.4.4, i.e.
pre-Lollipop.
MozReview-Commit-ID: LOg3Dd6gtZx
--HG--
extra : rebase_source : dc653f7dc85135b799d0da3e784913cdd9a3f973
This is in preparation for adding context-menu support to TopSitesCard, which requires
the two url-open listeners.
MozReview-Commit-ID: 7ubTCqCqcW9
--HG--
extra : rebase_source : 25d5e3c90e52ce4bca66650bf35887b8411f0b78
extra : source : b2757c2c28993795b6db83924869514a2592a448
This will allow us to reuse it for other similar menu buttons.
MozReview-Commit-ID: L8pleo8bQp9
--HG--
extra : rebase_source : cf925c13437001d392eb7397835e26029a2426d3
extra : source : cf46aca08e8c9a53df820dff629c6c2f9958aa84
This will allow us to ship the feature to a subset of the users or pull the feature without
needing to release a new version of the app.
MozReview-Commit-ID: 3rGLT29wuyC
--HG--
extra : rebase_source : 993b7c34aace5d7a5f7d1c63eb65ce1ed39aab7f
There's no reason to use InboxStyle here. We do not add any items to the list.
Currently the content text is truncated aggressively showing only one line of
text. With BigTextStyle we can show a lot more.
MozReview-Commit-ID: 8CQZVHzc7b8
--HG--
extra : rebase_source : c717e0c532d7ee101fac89e12db7961e44e811f7
After lots changing in media control's code, we don't need 'ACTION_START' anymore.
MozReview-Commit-ID: 3KktTrY4HoR
--HG--
extra : rebase_source : e54e59bdaef38b0f4742b94285fae477dbd02e02
There is no big difference between 'ACTION_RESUME' and 'ACTION_RESUME_BY_AUDIO_FOCUS', we can simplify it.
MozReview-Commit-ID: 4nqfgoopuJ6
--HG--
extra : rebase_source : adf46ef7f3ccd81ed68c02ba32187a8da8b8c7a0
Make sure the value of |mActionState| is correct after we modified the media control's interface.
MozReview-Commit-ID: 6Nhu1gqCFrD
--HG--
extra : rebase_source : 0f7104698feac19112aa6229108fae6c45261769
We don't need gecko to do something when receiving 'MEDIA_PLAYING_CHANGE' and 'CLOSED'. The only thing we need to do in Java side is to modify the media control's UI interface.
MozReview-Commit-ID: 6NrNraVOixg
--HG--
extra : rebase_source : 1342e5f44d9ed62d008cf9298832953b19a98d15
When user resumes media from the page, we should notify MediaControlService so
that it can change the playing icon to the correct status.
MozReview-Commit-ID: 15e2GrxvB6a
--HG--
extra : rebase_source : 3bb6714c6c8e10d83a629dc7dd55d6e8a3070b0f
Turns out the Facebook comment box doesn't work well if we send
compositions alongside set/remove span events. This patch adds back the
update composition flag, but only sends composition when necessary,
which is only right before we send key events.
Because onImeUpdateComposition is no longer associated with a separate
action, it no longer sends back a reply using AutoIMESynchronize.
When a Gecko text change spans larger than our original request, we have
to do the replacement in parts in order to preserve any spans from the
original request. There was a bug where the selection is moved to the
wrong offset after the three replacements. This patch switches the order
of the two replacements and manually fixes up the selection.
For any text changes that originated on the Gecko side, this patch also
splits the replacement into two parts (delete + insert), so that old
composing spans are properly cleared first. This new behavior changes
the expected result for the test added by bug 1051556, so the test is
changed as well.. I think this new behavior is more correct, but if it
results in regressions, we can reevaluate.
Right now we send a "process-gecko-events" message to
GeckoInputConnection in order to wait on Gecko during testing. However,
now we have GeckoThread.waitOnGecko() to do that, so we can just use
that directly.
Under asynchronous IME, when we check text/selection for correctness, we
have to wait for the IC thread to sync the shadow text first. In order
to do that inside the assert methods, we have to move them to inside
InputConnectionTest, so that they can call processGeckoEvents() and
processInputConnectionEvents().
Also, ignore a single newline character, if present, at the end of the
actual text, because it's a side effect of some editing operations in
Gecko (e.g. clearing all text in an HTML editor).
When switching the IC thread from one thread to another, we can no
longer block on the old IC thread waiting for the Gecko thread. However,
we still block on the new IC thread, waiting for the old IC thread to
finish processing any old events.
Sync the shadow text to the current text when the selection or text
changes on the Gecko side, provided we are not in batch mode and if we
don't have pending actions. Otherwise, remember the skipped sync and
re-sync when we exit batch mode and/or finish all pending actions.
We used to flush the Java side text upon receiving the acknowledge-focus
event, at which point the Java side is waiting on the Gecko side.
Because of the async IME refactoring, we can no longer wait on the Java
side, so we have to flush the text early, before sending the first focus
notification. Also, the acknowledge-focus event is no longer needed as a
result.
Our call to InputMethodManager to restart input also has to changed due
to the change in calling sequence between notifyIME and
notifyIMEContext.
Due to async IME refactoring, we no longer need the blocking mechanism
in ActionQueue. As a result of the simplified code, we can remove
ActionQueue entirely and move its code to under GeckoEditable.
ActionQueue.offer() is now icOfferAction().
This patch also makes mText an instance of AsyncText, and change all
accesses to mText to reflect the new async interface, i.e. accesses on
the Gecko thread go through getCurrentText() and the current*** methods,
and accesses on the IC thread go through getShadowText() and the
shadow*** methods.
AsyncText keeps two copies of the text - the current copy on the Gecko
thread that is the authoritative version of the text, and the shadow
copy on the IC thread that reflects what we think the current text is.
When editing the text on the IC thread, the shadow copy is modified
directly, and then the modification is sent to the Gecko thread, which
modifies the current copy concurrently. Depending on what Gecko does to
the text, the current copy may diverge from the shadow copy, but
periodically, the shadow copy is synced to the current copy through
AsyncText.syncShadowText() to make the two copies identical again.
As part of async IME refactoring, we will no longer send composition
updates separately. Instead, composition updates will be integrated into
the set-span and remove-span events, similar to what we already do for
replace-text events.
GeckoEditable implemented GeckoEditableListener because GeckoAppShell
called its methods through GeckoEditableListener, but now we use JNI to
call GeckoEditable methods directly, so GeckoEditable no longer has to
implement GeckoEditableListener.
This change also lets us simplify GeckoEditableListener by making
onTextChange and onSelectionChange no longer have any parameters.
Currently, clearSpans calls are carried out immediately, but that makes
it out of order in relation to other calls, which have to go through
Gecko. This patch fixes this issue.
This will be needed for opening background/private tabs from the highlights menu.
MozReview-Commit-ID: 8wvFuTgl2SP
--HG--
extra : histedit_source : de4024ee986c5a48d9da4206160cf960b1d7bc3c
This flag seems to no longer be needed, and prevents the use of switch statements for resource ID's. It was first introduced for mach based geckoview builds, however geckoview now seems to be built using gradle which is able to invoke aapt to produce better R.java's, resulting in constant Resource ID's in Fennec.
MozReview-Commit-ID: EjWCX4nvlht
--HG--
extra : rebase_source : 3eb30debbc76c39bd8e367bf8709eaaf1592f42a
We want to access ActivityStreamContextMenu directly in our new test. That menu
extends BottomSheetDialog which is contained in the design support library, hence
we need to make that library available in robocop builds in order to access
the AS context menu.
MozReview-Commit-ID: EPyv7wvkJAE
--HG--
extra : rebase_source : cafe1e7dd6fbdcfb471cf5f66a1c0522e796c3aa
In the pageAction and browserAction schemas, several methods are
declared with `"async": true` but without a specified callback in the
`"parameters"` object, so callbacks are not allowed. However, when a
callback is proxied, the `ParentAPIManager` will mirror the call by
passing in an extra callback to the proxied API - and break.
This patch fixes the issue by removing uses of async:true. Also for
consistency between the browserAction and pageAction methods, the
methods that were not declared as async have also been marked as async.
MozReview-Commit-ID: JQqzmTUAotB
--HG--
extra : rebase_source : 62d1cbc4843dd6c792318337158e4311f8df94a4
This ensures no white borders around the favicons when on Android 4, no changes
on Android 5. Read FilledCardView for the full background on the border/corner
issue that happens on Android <= 4.
MozReview-Commit-ID: IsBcp7xxwjn
--HG--
extra : rebase_source : c37fbfe63eba9d8af4bc0c7b4d4535a380b6d3bd
Okay, this patch is much bigger than I anticipated. However at this point it is impossible
to separate all the interweaved changes.
* Update sizes and colors
* Use a dynamic number of top sites tiles to adjust to the screen size
* Do not keep references (to possible outdated) Cursors from every top sites page
* Remove unused bottom panel
* Add menu button to highlights items
MozReview-Commit-ID: 2CeEGCOXBKl
--HG--
extra : rebase_source : a780ec20fa6f87520c3418403ae4fe259ff39d69
Update path can be null. In this case we fallback to using the last saved path. However
if this doesn't exist either then we just continue with a null path and eventually crash
the service.
MozReview-Commit-ID: Kuihp496TEo
--HG--
extra : rebase_source : 96e2182571f4b2235b3fea25f449b2dbb3e17bb8
The Android version of TouchDelegate never resets the value of its
mDelegateTargeted, which means that once an event is delegated, future events
can get delegated as well, regardless of whether the event occurs within the
TouchDelegate's bounds. Because of the geometry this is more of an issue with
the (future RecyclerView version of) TabsGridLayout, but it can occur on
TabsLinearLayout as well where we use a TouchDelegate to increase the hit size
of the close button on a tab - once a close button is hit by delegation and the
tab is closed, the next time that tab is recycled it will continue to delegate
ACTION_UP events to the close button (in which case they're silently dropped)
even if the ACTION_DOWN was not in the close button's delegation area.
This commit introduces TouchDelegateWithReset, which is simply an override copy
of TouchDelegate with one extra block (commented in the new class) to reset
mDelegateTargeted on each new gesture received.
MozReview-Commit-ID: 5xrPBAdAK6D
--HG--
extra : rebase_source : d1b9c7a443b0590c63433ea6855c8a1ae0662455
extra : source : 0c267676cb0824d916f398155b0d5b7dec6f346c
Use the index in TabsLayout to specify where a tab was inserted instead of just
replacing the entire tabs list on a tab add.
MozReview-Commit-ID: Feft0RlN97r
--HG--
extra : rebase_source : 1ff47946d9e94d08dfcee34364c65ae7f8c02e7a
Also make a temporary testing adjustment to handle the fact that TabsListLayout
and TabsGridLayout don't currently share a common usable base.
MozReview-Commit-ID: HPExAnehKRq
--HG--
extra : rebase_source : 4d9d0ce9fff216090ae676163e22645cd45c92a5
extra : source : 411a8ac7368e3b69e8191812fb53f0d1b8aa3247
TabsListRecyclerAdapter.java will replace TabsLayoutAdapter.java when the time
comes.
Note from the future: the previous tabs layouts did a scroll each time an item
was added or selected, but GridLayoutManager sometimes does scrolls that aren't
necessary (like even when the position being scrolled to is already completely
in view), so we've adopted the approach of only scrolling when RecyclerView
makes it necessary.
MozReview-Commit-ID: JisX974zt88
--HG--
extra : rebase_source : 4105762cdd743d5120385e246350fc4059b6bcfc
extra : source : e4e74d6ae6da7dddda9a95e50c26656b07e67287
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
This removes the rest of the usage of nsISupportsArray in MediaManager.
MozReview-Commit-ID: EqXTRNyKiva
--HG--
extra : rebase_source : afc25d91dfcabf6f8f5c9aca6828d41acac9e97e
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
--HG--
extra : rebase_source : 069b6ec173bb98ab08d93279b5e983494184f8c0
Setting an empty view's visibility only for the view corresponding to the current PanelLevel was intended to make sure the empty view doesn't get hidden because of an unrelated status update - e.g. to prevent the history empty view hiding itself because the recent tabs count changes.
This approach however doesn't work for switching between panel levels (the user moving into and out of the sync/recent tabs folders) - in that case we always need to turn off the empty view of the previous panel level, which is not possible with the above approach.
So instead, we revert to always updating the visibility of the empty views, but at the same time initialise the desired state of current PanelLevel's empty view with its current visibility instead of simply defaulting to false.
MozReview-Commit-ID: 6Xsnuo29srk
--HG--
extra : rebase_source : d540c128df51ae0315f9ee05c3fb87cfcf44877a
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
This allows us the use of VectorDrawable's (which can be created by converting SVG files) in a
limited set of circumstances.
MozReview-Commit-ID: 4n4dXnZYn9W
--HG--
extra : amend_source : 8fbf2579260590a26ecd0112d6fce1055e929bd7
Also this makes the gScreenWidth/gScreenHeight variables unused, so those can
come out too and the Window:Resize handler can be simplified a bit.
MozReview-Commit-ID: 96iF16jSKBB
--HG--
extra : rebase_source : 01db1de5cc548db107267d84dda5b774cd652883
Bug 1305498 - 1. Remove NotificationClient task queue; r=sebastian
Not sure why we needed a task queue for NotificationClient actions. The
actions all go through IPC and are non-blocking, so it's perfectly fine
to perform them off of whatever thread we're on.
Bug 1305498 - 2. Integrate NotificationHandler et al into NotificationCllient; r=sebastian
There's no reason to have NotificationHandler, AppNotificationClient,
and ServiceNotificationClient all separate from the base
NotificationClient class. This patch adds the functionality of
those three classes to NotificationClient.
The notifications hash map is changed from a ConcurrentHashMap to a
regular HashMap with synchronization because I think the use case here
doesn't warrant the added performance and overhead of ConcurrentHashMap.
NotificationService is changed to match the new NotificationClient. Now
the only job for NotificationService is to set a notification as
foreground, rather than to manage all notifications like before.
NotificationHandler, AppNotificationClient, and
ServiceNotificationClient will be removed in a later patch.
Bug 1305498 - 3. Set NotificationListener in GeckoApplication; r=sebastian
Set NotificationListener once in GeckoApplication.onCreate, instead of
spreading it out in GeckoApp, BrowserApp, and GeckoService. This is
possible because there's no longer a distinction between
AppNotificationClient and ServiceNotificationClient in the new,
consolidated NotificationClient.
Bug 1305498 - 4. Remove obsolete notification classes; r=sebastian
Remove AppNotificationClient, ServiceNotificationClient, and
NotificationHandler, now that they've all been replaced by the new,
consolidated NotificationClient.
Bug 1305498 - 5. Use NotificationReceiver for web notification callbacks; r=sebastian
Previously, web notification callbacks went to GeckoApp directly, but
that presented some problems such as not being able to implement the
on-close callback, because we don't want to launch GeckoApp when the
notification is closed by swiping. This patch makes us use
NotificationReceiver for callbacks, and let NotificationReceiver launch
GeckoApp if necessary.
Bug 1305498 - 6. Don't keep notification cookie in native code; r=sebastian
Keep the notification cookie a single location (in the notification
intent itself), and simplify the native notification handling code.
Bug 1305498 - 7. Use NotificationReceiver for persistent notifications; r=sebastian
Currently, persistent notification callbacks go through a different code
path, but it'd be more consistent and correct to let persistent
notification callbacks go through NotificationReceiver as well.
This takes care of some housekeeping work that was missing for
persistent notifications, such as deleting the mNotifications entry when
the notification is closed.
The fixup migration assumes that there must be a default panel, and sets the history panel as default if not.
This assumption is wrong in the case where no panels are visible: in this case there is no default.
Before this commit, that migration will make the history panel visible for all users who had no
visible panels, with this commit that migration will retain the all-panels-hidden state.
Note: it's impossible for us to recover the all-panels-hidden state for clients that have already
run the migration, however we can at least prevent this issue from happening for users who
have not yet migrated (i.e. in release).
MozReview-Commit-ID: 9JlmltPW2Ly
--HG--
extra : rebase_source : 4e608910775c971ec09c0f9096b8ae36e9f7b877
Sometimes the tab doesn't get its favicon yet when we send the notification.
Therefore, we would listen the FAVICON event and then re-send the notification again if we used the default cover icon in previous notification.
MozReview-Commit-ID: JSphLBEhGy2
--HG--
extra : rebase_source : 55f12e30583480a1d0d7f2743974a05180198ad5
We need to bump the Gradle Deps task, which fetches dependencies, to
include new test dependencies; and use freshly uploaded tooltool
archives (manually uploaded) containing the new test dependencies.
MozReview-Commit-ID: 8bNOVQPHlk6
--HG--
extra : rebase_source : 0c80117fb58e43f9c857027941f0a14f03b97f13
Web Crypto returns an unhelpful "operation failed for an
operation-specific reason" error if the actual decryption fails, but
we can report more useful errors for missing and invalid header
values.
MozReview-Commit-ID: JRdGHBUodmb
--HG--
extra : rebase_source : 8f1b047b6f01c89a852aefbb1349a608f1178ab8
On Windows, the contextmenu event is fired when the finger is lifted after a
long-press. However, there are various bits of code, such as the AccessibleCaret
or potential fixes for bug 1147335, which would benefit from knowing when the
long-press gesture was detected. By moving eMouseLongTap event up we can satisfy
that need. An alternative approach considered was to fire the eMouseLongTap
before the contextmenu on all platforms unconditionally, but that makes it harder
to implement platform-specific text selection behaviour the way we want. In
particular we would have to add an extra message or notification for non-Windows
platforms that initiated text selection if the contextmenu event was not
consumed.
MozReview-Commit-ID: 2lmwxmmGrVD
This patch introduces WebsiteMetadata.jsm which imports fathom and page-metadata-parser.
The code has been slightly modified to not depend on more node libraries.
On DOMContentLoaded the module will extract the metadata asynchronously and send it with
a 'Website:Metadata' event.
MozReview-Commit-ID: LxhYOTvvdsF
--HG--
extra : rebase_source : e31286bd7268ad62d55f1a5318cde79442e9acba
Huge oversight in my original patch. Pressing any hardware button will result
in the history list being shown after the long-press delay (regardless of long-pressing).
MozReview-Commit-ID: KO8u0NzTxaO
--HG--
extra : rebase_source : 6f6932c4f35b9e580a84a2d68a7688abe4da79de
After the splitting of text overlay and the caret images, the caret image should
be placed from the top of #image div.
Delete those "top" style for Fennec since they're not needed anymore in current
setup.
MozReview-Commit-ID: Dn6jgqaFfek
--HG--
extra : rebase_source : 92b697db26cb7311fbd22a63e9f0ed71e6a434f4
It looks like the update (23.4) version of palette returns the actual dominant colour
for a red mock (FF0000). Previously it returned a more muted red (F80000).
MozReview-Commit-ID: 5VpRavyooHY
--HG--
extra : rebase_source : ab55e787a305481f890d00739de2843b87063bed
Make contentDocumentChanged and isContentDocumentDisplayed calls require
the caller to pass in a window object, so that we can get the widget and
GeckoLayerClient from the window object. This way these calls no longer
depend on having a global layer client in AndroidBridge.
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
--HG--
extra : rebase_source : a8beed043989f6e69e89d17c0db1864c6d7258ac
I've also updated espresso versions. For some reason using espress results in test-app
defaulting to annotations 23.0.1 or 23.1.1 (depending on espresso version), but we can
override this with the actual annotations library version to make gradle happy again.
MozReview-Commit-ID: 6rFtvVgceJV
--HG--
extra : rebase_source : 3c9fb20cad396eebbfbd890cc37a4931221488d9
