This commit introduces a special type of a pin, "Activity Stream pin".
It's identified by a fixed position of -1. Activity Stream pins are displayed inline
with top sites, at the very front. They are "non-positioned", as opposed to regular pins
which have a position on Top Sites grid. This approach was selected (as opposed to creating a
new kind of a "non-positioned pins bookmark folder") because it is simpler, does not
involve any migrations or sync changes, and is thus preferred in light of a moving
target that is the current vision for Activity Stream.
Two types of pins, regular ones and Activity Stream pins, are independent of each other.
Due to the fact that pins and bookmarks are almost the same thing, we can only figure our,
based on the underlying queries, the following ahead of time:
- pinned state of a pinned top site item (trivial case)
- pinned state of a non-pinned top site item (trivial case)
- bookmark state of a "bookmarked" hightlight item (trivial case)
- bookmark state of a non-pinned top site item
For all other combinations, states have to be looked up when user opens a context menu for an item.
MozReview-Commit-ID: 3KbOp9S4Pz7
--HG--
extra : rebase_source : a86893a235ee7c6c7d2215b9c8a3b56f986480a9
Since we want to include pinned sites in A-S Top Sites, this removes the "plain top sites"
query which excludes pinned sites.
Maximum number of suggested sites displayed is set so that they will fill out at most two "pages".
MozReview-Commit-ID: 8uynmwiaPkt
--HG--
extra : rebase_source : 763633fca5f9f606a8f6cfd1f4a4332273c34dee
Convert "ClosedTabs:Data" and "Sanitize:Finished" events used in
RecentTabsAdapter and GeckoPreferences from NativeJSObject events to
GeckoBundle events.
Convert JavascriptBridge, JavascriptTest, and other relevant code to use
the new Bundle events. We used the same "Robocop:JS" event for
communicating both ways before, but now that we have a unified bus, we
need two different events, "Robocop:JS" and "Robocop:Java" for two-way
communication.
Convert events that are only used in robocop tests to Bundle events,
which are then used through Actions.expectGlobalEvent /
expectWindowEvent.
"Content:" prefix is added to "DOMContentLoaded" to follow the event
naming convention.
SelectionHandlerTest.java is removed because it's no longer used
anywhere.
This results in the highlights title smoothly animating upwards with the remaining RecyclerView items.
Previously RV would crossfade between a panel containing both the welcome message AND the highlights
title, which means the Highlights title would vanish and reappear. This patch results in a more
correct and pleasing animation. We also upgrade to using a ViewStub for the welcome panel as part of
this commit.
MozReview-Commit-ID: GYxrSiqKeS5
--HG--
extra : rebase_source : d766347b74971874a28062b48cdf2a2880031608
Converting this image to webp results in artifacts on the rectangle, therefore
we can only try to minimise its size by removing the alpha channel. (All other
firstrun images will be converted to webp as they do not display these artifacts
after conversion.)
MozReview-Commit-ID: EdAgdfHna8C
--HG--
extra : rebase_source : 21a483c304607d6fd3876ddd52e14376c771578f
Bug 1321418 - 1. Use GekcoBundle events in GeckoApp; r=snorp r=sebastian
Switch GeckoApp to using GeckoBundle events everywhere. UI or Gecko
events are used if the event requires the UI or Gecko thread,
respectively, and background events are used for all other events.
There are changes to some other Java classes, such as SnackbarBuilder
and GeckoAccessibility, due to the switch to GeckoBundle.
For "Snackbar:Show", we need the global EventDispatcher because the
event can be sent to both GeckoApp and GeckoPreferences. Howveer, we
only want one listener registered at the same time, so we register and
unregister in GeckoApp's and GeckoPreferences's onPause and onResume
methods.
Bug 1321418 - 2. Use appropriate JS EventDispatcher to send GeckoApp events; r=snorp r=sebastian
Change JS code that sends events to GeckoApp to use either the global
EventDispatcher or the per-window EventDispatcher.
"Session:StatePurged" is not used so it's removed. "Gecko:Ready" in
geckoview.js is not necessary because it's only used for GeckoApp, so
it's removed from geckoview.js.
Bug 1321418 - 3. Use GeckoBundle events in BrowserApp; r=snorp r=sebastian
Switch BrowserApp to using GeckoBundle events, in a similar vein as
GeckoApp. UI or Gecko events are used if the event handlers required UI
or Gecko thread, respectively, and background events are used for all
other events.
Some other Java classes also have to be modified as a result of
switching to GeckoBundle.
Bug 1321418 - 4. Use global EventDispatcher to send BrowserApp events; r=snorp r=sebastian
Change JS code that sends events to BrowserApp to use the global
EventDispatcher instead of "Messaging".
Bug 1321418 - 5. Update usages of events in tests; r=gbrown
Update cases where we use or wait for events in tests.
Add expectGlobalEvent, expectWindowEvent, sendGlobalEvent, and
sendWindowEvent to the Robocop Actions interface, along with changes to
EventExpecter, to support GeckoBundle events on Gecko, UI, and
background threads.
Changing the setting currently won't take effect until you rotate the tabs
panel (to cause it to be recreated); that will be fixed in the next commit.
MozReview-Commit-ID: HZfQRy8zubV
--HG--
extra : rebase_source : 78c3606eb55146afe3d59b0cdfa623999f09796b
- move all buffer related code from the Callbacks class to (Input|Output)Pocessor
- don't implicitly release output buffer to codec. Do it when client calls releaseOutput()
- fix buffer management problem in reset()
- minor code formatting issue
MozReview-Commit-ID: FmMjFBQax0s
--HG--
extra : rebase_source : 88fcaa58fe1cae1a8603bdbce2ad0cd6c6f7a21e
%l seems to be for hour in 12hr clock (i.e. 1-12), but we're applying it to a filesize.
%d seems more appropriate in order to display the actual raw filesize.
MozReview-Commit-ID: AKTpYndm81o
--HG--
extra : rebase_source : 4107bd4ebbe6169ecd3823b2613099bb73ae81a1
Fix a crash in GeckoBundle.fromJSONObject due to wrong values array
type. Also, fix a bug where the first element of a converted array is
repeated. r=me for trivial patch.
In general, any code that was using nsIX509Cert.nickname should be able to use
the attribute displayName (if using nickname for display purposes) or the
attribute dbKey (if using nickname as a unique identifier for a certificate).
MozReview-Commit-ID: G9CfMJDfLqe
--HG--
extra : rebase_source : 1c464dab8f028568cedd5a42cf87428b8bb63fc0
A subtest's cleanup function only runs at the very end, after *all* subtests have finished. This means that we cannot use it to close the test tabs if we want to reuse the tab variables during following subtests. If we did, we'd be leaking those previous tabs, meaning they remain open at the end of the test and cause possible problems for following tests as well as lots of "Unable to restore focus" messages in the log.
MozReview-Commit-ID: H87JQ5gcIAg
--HG--
extra : rebase_source : 5e870acba4c8ee05557f1ac0175bda12606b4e28
So far still cannot find the reason of causing exception. To add more
debug information to make sure it is not permssion problem.
MozReview-Commit-ID: 7hhU7Et64Qs
--HG--
extra : rebase_source : 84ac7c066468bf613afe0513b2ce00081e16f62c
Fennec has touch support, so enabling
"layout.accessiblecaret.enabled_on_touch" in all.js is sufficient.
MozReview-Commit-ID: 4Aa3g5eqt2F
--HG--
extra : rebase_source : c5fe085fe3d643dcf9f9a3732986954032566837
These events are not accessed through GeckoApp, and should therefore use
the global EventDispatcher rather than the per-GeckoApp/GeckoView
EventDispatcher. Otherwise, we could run into situations where we end up
registering / unregistering the same event using different
EventDispatcher instances, causing exceptions like this one.
Update the tooltool manifests for the android builds to include
support for the i686-linux-android target.
MozReview-Commit-ID: EyALhnfG4Kz
--HG--
extra : rebase_source : a85b8c1509458e1f5a8f8eae163e38edd1c363ce
Previously for the spacing at the top and bottom of the tabs grid panel we had
the total desired vertical spacing set on the RecyclerView padding, but then
there was also an additional half spacing coming from the ItemDecoration padding
in the top and bottom rows. Here we decrease the RecyclerView vertical padding
to account for the ItemDecoration vertical padding.
The alternative route of keeping full RecyclerView padding and then having the
ItemDecoration adjust itself depending on its position turned out to not "just
work": for example, if span count is three and you have four tabs, then the
first three tabs have half padding along their bottoms (since there are two
rows), but then when you close tab 4, there's now only one row and so the three
tabs should have no padding along their bottoms (since the RecyclerView already
has its own full padding), *but only tab 3 gets its ItemDecoration updated
automatically*, so it gets 0 bottom padding, but its row still has other tabs
with half bottom padding, so a) there's still too much bottom padding in that
row coming from tabs 1 and 2, and b) tab 3 sits too far down in its space
because it doesn't have the bottom padding that tabs 1 and 2 do.
That issue could be fixed by updating all ItemDecorations after each close, but
the patch here is both simpler and leads to less runtime work.
MozReview-Commit-ID: 2WeZ6QdfIF4
--HG--
extra : rebase_source : 85aec8adfdaacac7062827e273cf697c09167d63
The idea is that cancelling edit mode when opening a new tab implies that we want to select it as well, otherwise we wouldn't have to cancel edit mode in the first place.
MozReview-Commit-ID: Gova1ymzlHn
--HG--
extra : rebase_source : a1d957de82a5e1ec9bf9162e1f01641e34e16ab4
Change prompt response from using JSONObject/String to using
GeckoBundle. The GeckoBundle is automatically translated to a JS object,
like before, when dispatched to JS code.
Context menu items used UUIDs as their prompt list item IDs. However,
prompt list items only support integers as IDs. This error didn't show
up before because JSONObject was silently ignoring the error. This patch
changes to using an incremental integer as the ID and fixes the error.
Convert prompts to use BundleEventListener and GeckoBundle.
DefaultDoorHanger.setOptions accepts a JSONObject argument, but if we
converted it to GeckoBundle, it would involve a lot of extra changes in
the other doorhanger code. So this patch adds GeckoBundle.fromJSONObject
and converts JSONObject to GeckoBundle within
DefaultDoorHanger.setOptions. In the future, another patch would convert
all doorhanger code to use GeckoBundle instead of JSONObject.
Fix several bugs when handling arrays in GeckoBundle.
1. Correctly return null when getting an array that is not in the
bundle, instead of crashing.
2. Convert object arrays to GeckoBundle arrays in EventDispatcher
instead of leaving it as a single GeckoBundle with integer keys, due
to lack of object array support in NativeJSObject.toBundle.
3. Return error when trying to convert a JS array of arrays to
GeckoBundle, instead of crashing.
4. Add convenience methods for setting arrays; for example, setting
boolean arrays from Boolean[] and Collection<Boolean>.
- poll all buffers when started or flushed.
- retry only for timed out.
- remove unnecessary polling
MozReview-Commit-ID: DU9vvjJkwDH
--HG--
extra : rebase_source : 54d734585e198413b2f1afbdad9b073b4e14a153
Currently, we stop updating closed tabs if max_tabs_undo is set to 0, however we don't clear that data and carry it around indefinitely unless the user clears the browser history.
This means that when closing a tab, we still show the "Undo close tab" snackbar, however with its contents referring to the last tab the user closed before setting browser.sessionstore.max_tabs_undo to 0.
With this patch, we clear all closed tabs (and don't reload them from disc on startup) if max_tabs_undo is 0, which also stops the snackbar from showing after closing a tab.
MozReview-Commit-ID: PEtminpW4B
--HG--
extra : rebase_source : 7c8039db1d1d7c5bc127cdc11fbc0a1387694ef9
This can happen if the users sets browser.sessionstore.max_tabs_undo to 0 - with no closed tabs available, without this fix the resulting exception breaks browser.js's closed tab handling, meaning the tab gets closed in the UI but not in Gecko.
MozReview-Commit-ID: 7yMyIB6UzAB
--HG--
extra : rebase_source : 37ca55519b30cbd5d263127d3ecd6b893ccfafc9
Let's use a pristine unpackaged directory of the en-US package, and just
rsync that to l10n-stage. That way, all repacks start off with a copy
of en-US without modifications of the previous repack.
Removing clobber-zip, that hasn't been used in ages, on the way.
Moving the creation of the branding dir to the INNER_UNMAKE_PACKAGE,
which is the command that needs it, to simplify rulesets.
MozReview-Commit-ID: 8WJtaAqjmk1
--HG--
extra : rebase_source : 2c60a09bc09c72d5d8cf3058a66f806059c93751
Update tooltool manifests to repacks of upstream builds of
rustc 1.14.0-beta.2 (e627a2e6e 2016-11-16)
cargo 0.15.0-nightly (a9c23dd 2016-11-15)
for the relevent hosts and target platforms.
We prefer to use stable rust but this bump gets us debuginfo
for the rust standard library on all platforms, which we hope
will improve crash reporting (bug 1268328). That is higher
priority. The rust 1.14 version should be in stable release
before Firefox 53 goes to Aurora, so we'll still stabilize
and ship with stable rust.
This build also contains the fix for the arm code generation
bug blocking update from 1.12 on android, so we can use 1.13
language features in Firefox 53. For more information, see
https://github.com/rust-lang/rust/pull/37815
This doesn't update the native MacOS build because of an
openssl link issue with cargo. This is resolved upstream
for rust 1.15; getting that ported to a later 1.14 beta is
tracked in https://github.com/rust-lang/rust/issues/37969
MozReview-Commit-ID: JbJTd4D7VOu
--HG--
extra : rebase_source : 0690f3d4443f3fc7f224f051f910de92c54b8f60
Run the tooltool manifests through a python script to read the
json as an OrderedDict and when write it back out with normal
tooltool formatting options. This regularizes the whitespace,
fixing trailing spaces written by older versions of the python
json serializer, dos-vs-unix line endings, and regularizing
opening '[{' and closing '}]' to be on separate lines.
The android manifests have a 'versions' key which has indenting,
unlike the rest of the files. I've left that as-is.
MozReview-Commit-ID: EVW1YlgRJJL
--HG--
extra : rebase_source : 40c1992090807dc40495ebacb37ee358c1d6a6f1
We switch to thinking of the tabs grid layout as being determined by specifying
the spacing between the items, and then allowing the items themselves to expand
to fill whatever room that leaves available, but we also allow the spacing to be
adjusted to match the span counts of the previous GridLayout implementation
(which is a good thing).
MozReview-Commit-ID: L3fgjacMu2d
--HG--
extra : rebase_source : 72e77a44c0f0c8c9de3c9d6c5ef95aad405d27a3
extra : source : 17966f55c27550e30f2ec1aab5bc6bc849240436
Wait to register MediaPlayerManager events until we have a GeckoApp
EventDispatcher, because we only have an EventDispatcher after we create
the GeckoView in onCreate.
Since we're Proguarding the automation build now, we shouldn't need to
multiDex anymore -- even in beta.
MozReview-Commit-ID: 6Yc73Vi9Fhd
--HG--
extra : rebase_source : cdfb01a47dc05dfafc4ba67cdb30f86dbd5aa4ec
moz.build achieves better results than Gradle, and I can't fully
explain why that is. At first I thought it was due to
-optimizationpasses, which is 6 for MOZILLA_OFFICIAL; however, it's
not -- I see no change (let alone an improvement), when I set the
number of passes to 1, 6, 10, or 100. I think there are two things at
play. First, moz.build strips debugging information from "libraries",
which are broadly the Google support libraries. I don't think it's
possible to strip debug information in this fine-grained manner using
Gradle. Second, I think the Gradle build might be including more code
than the moz.build configuration (see the follow-up patch removing
multidex support), but I can't determine what's actually different.
After APK compression, I see less than a 50kb regression in APK size
between Gradle and moz.build outputs, which I deem reasonable.
MozReview-Commit-ID: 4q4Zye2wnOF
--HG--
extra : rebase_source : dfc0f983f56ceb5907f9aafcb37d2ac63d50988b
<input>'s of type checkbox and radio are rendered as native widgets by default
on Desktop, but on Fennec, we fallback to using the built-in, non-native
checkboxes.
The earlier patches in this series made it possible for agent, user and page
stylesheets to make changes to the non-native checkbox and radio input fields.
Unfortunately, some of the default agent styles for those checkbox and radio
elements on Fennec were accidentally setting rules that they shouldn't. That
wasn't a problem before because the inputs couldn't be styled before. Now that
they can, we're failing a bunch of reftests because the inputs look wrong in
certain situations.
For example:
1) We were setting background: var(--form_background) for every radio and
checkbox input. --form_background is just a colour though, and that meant
that the rest of the background styles were being overwritten. This has
been fixed by setting background-color: var(--form_background) instead.
The same also applied to some usage of --form_background_disabled.
2) We were setting border-radius: var(--form_border_radius) on all input
elements, but this was putting rounded corners on the checkbox and
radio inputs as well. This rule has been modified to skip checkbox
and radio inputs.
MozReview-Commit-ID: CnpTRXcCxoY
--HG--
extra : rebase_source : ee688b96270e9b2b3498f18d43f9430048b9b444
Our previous GridLayout settings gave extra horizontal space to the padding
between items, but GridLayoutManager by default simply left aligns fixed width
items in their column, so the item's width has been changed to fill_parent
and the item title has been switched to fixed width (since otherwise it looks
broken when it expands to an item width larger than the thumbnail width). The
drawback is that clicking on the extra width part of an item activates the tab,
even though it would seem from what's being displayed that the item should end
at the vertical edge of the thumbnail - that will be fixed in a future commit.
Both the list and grid tabs panel views are now RecyclerViews, so move
TabsLayoutRecyclerAdapter.java to TabsLayoutAdapter.java.
MozReview-Commit-ID: CBrxw1HfRcP
--HG--
extra : rebase_source : 009e98a71b1644fbe39e36dab10bfbf371329fa8
extra : source : 1c6a92e7614c2b0981db9ccfbc1d673656c88daf
