Added support for changing default browser by opening settings screen in API Levels >=24.
MozReview-Commit-ID: 5rxJm6hQQ4A
--HG--
extra : rebase_source : e8fc23bc658e216c04c27e10067c16abf2b0cd5c
There are a number of ways in which we could supply favicons for the default suggested
sites. Reusing the touch tiles has the advantage that it works for both our own suggested
sites, and also distribution-supplied suggested sites. If we were to add yet another
icon source, distribution supplied sites would end up having no nice icon in AS topsites.
The priority ordering of the SuggestedSitePreparer means icons will be overriden as soon
as a site-supplied favicon is available - these icons will only be used up until the point
where a site has been visited.
MozReview-Commit-ID: CHsinHHpfnw
--HG--
extra : rebase_source : a162f5b15e968f382b43505290b0633cbe6e2c7a
In order to allow for a background which merges into a favicon, we
need to allow for solid (non faded) colours. It is simplest to do this
by letting the colour generator (i.e. either the colour extractor,
or the favicon generator) fade the dominant colour as it wishes.
That also means the colour generator can in future choose to
not fade the colour if appropriate.
MozReview-Commit-ID: LsI8PlZsaGn
--HG--
extra : rebase_source : 757f10613a201475edb81afc094f32d5a714ade2
onTabLoad() means we've potentially navigated to a new page, in which case any auxiliary tab data we keep around for the currently loaded page only (form input data, scroll position) would be invalidated and shouldn't be preserved.
Since onTabLoad() can however also be triggered if e.g. just the tab title changed (an additional DOMTitleChanged event), we shouldn't throw away the old data without replacing it with the current state, though. We already do this for the form input data - we need to do it for the scroll position as well.
MozReview-Commit-ID: HG7g6L7htDG
--HG--
extra : rebase_source : 1f7aab26002ee71237dd0a48b872298b39ca7f13
Launching a new activity within our app triggers both onActivityPause() (the current activity) and onActivityResume() (the new activity) in GeckoApplication. The most prominent example at the moment are probably our preferences - entering/exiting/navigating within them always triggers a pause/resume combo. This means that currently each time this happens, the network manager is stopped only to be immediately restarted.
To prevent this, we now stop the network manager only when Gecko is actually being paused. In order to avoid unmatched start/stop calls, we need to treat the calls to start() similarly and provide an additional code path for the initial call to start() immediately after startup.
Since the BatteryManager is only started and currently never stopped, we can use this for its startup, too, so as to avoid duplicated calls to its start() method.
MozReview-Commit-ID: 6NdScT5cLYL
--HG--
extra : rebase_source : 758a5948e0852bfa29c78d2d364cd5ac88e9103d
Currently, GeckoPreferences always returns "false" for isGeckoActivityOpened(), which means that when we're e.g. opening a new settings screen, GeckoApplication's onActivityPause() code assumes that Firefox is being backgrounded for real, calling GeckoThread.onPause(). This is then immediately followed by a call to onActivityResume() which unpauses Gecko again.
To avoid this, GeckoPreferences needs to properly implement support for GeckoActivityStatus and check the target of outgoing intents along the lines of the implementation in GeckoActivity.
Since checkIfGeckoActivity() is now used outside GeckoActivity as well, we refactor it into our IntentUtils.
MozReview-Commit-ID: UfPNAic5os
--HG--
extra : rebase_source : d8e900140f55f9a363b86064eb1ad8f8ee4c5c48
Launching a new activity within our app triggers both onActivityPause() (the current activity) and onActivityResume() (the new activity) in GeckoApplication. The most prominent example at the moment are probably our preferences - entering/exiting/navigating within them always triggers a pause/resume combo. This means that currently each time this happens, the network manager is stopped only to be immediately restarted.
To prevent this, we now stop the network manager only when Gecko is actually being paused. In order to avoid unmatched start/stop calls, we need to treat the calls to start() similarly and provide an additional code path for the initial call to start() immediately after startup.
Since the BatteryManager is only started and currently never stopped, we can use this for its startup, too, so as to avoid duplicated calls to its start() method.
MozReview-Commit-ID: 6NdScT5cLYL
--HG--
extra : rebase_source : 629d9a252125cfe4db1c30d6fcbe6607ac81ab33
Since we're no longer pausing Gecko when entering this activity, it must implement this interface so we can still properly pause Gecko if we get backgrounded while on the Sync preferences screen.
Most actions here are actually done via the application context (i.e. GeckoApplication), so overriding startActivity et al. and using mGeckoActivityOpened doesn't achieve all that much for most cases, but since we currently at most exit the screen (activity is finishing, so won't trigger a GeckoThread.onPause() call) and stay within our application (open a new tab in Firefox), we're still fine for now.
MozReview-Commit-ID: 3760hXMjckX
--HG--
extra : rebase_source : 026654ca101082140f9fbbc922562f9890daab50
Currently, GeckoPreferences always returns "false" for isGeckoActivityOpened(), which means that when we're e.g. opening a new settings screen, GeckoApplication's onActivityPause() code assumes that Firefox is being backgrounded for real, calling GeckoThread.onPause(). This is then immediately followed by a call to onActivityResume() which unpauses Gecko again.
To avoid this, GeckoPreferences needs to properly implement support for GeckoActivityStatus and check the target of outgoing intents along the lines of the implementation in GeckoActivity.
Since checkIfGeckoActivity() is now used outside GeckoActivity as well, we refactor it into our IntentUtils.
MozReview-Commit-ID: UfPNAic5os
--HG--
extra : rebase_source : 6167836e9a20763724c62aade1d2f0a5e976a890
Update to the point release. These are repacks of the
upstream builds for 1.15.1 stable with appropriate
libstd builds for each target.
This incorporates the -fPIC fix for linux32 so we can
use upstream builds instead of our patched toolchain.
It also corrects the signature of vec::IntoIter::as_mut_slice
which was incorrect in 1.15.0.
MozReview-Commit-ID: JvEdGPwgS03
--HG--
extra : rebase_source : 9edd9970d8328274311493c2c3c4fffa97b258a9
There's apparently a bug which causes *both* paddingRight and paddingEnd to be
applied (in my case on an API 23 emulator); the workaround, in this case, is to
also specify paddingLeft and paddingStart (with values "0dp").
MozReview-Commit-ID: 98hm1GcSPxi
--HG--
extra : rebase_source : 90b63521b410836615134eb7310ac0c2fb15081b
If the intent from 3rd-party app doesn't have data url, directly call
PendingIntent.send() will perform nothing. To use current url as
polyfill to fix it.
MozReview-Commit-ID: IIP7hGd1cBH
--HG--
extra : rebase_source : 14010c9f0b566e1320598a2edc0a6538d9c6150e
Suggested sites don't have a bookmark ID, there's little value in setting one here since
that's confusing for anyone handling the cursor. (This is probably an oversight from
when the single-cursor topsites query was first implemented.)
MozReview-Commit-ID: 77Cw37za6cD
--HG--
extra : rebase_source : 4e654b64d76423133bcfe4c90dab13891dcc4f09
Suggested sites aren't joined against the bookmarks table before returning
them as part of getTopSites(), so their bookmark state is unknown.
MozReview-Commit-ID: C5BhUcoSsll
--HG--
extra : rebase_source : 4509eb9980970de703e7f32ca371c76ec78b2673
The refactor patch removed a try/catch block that would have caught this
error before. Instead of using try/catch, this patch checks for the
affected items and send an error when the items are missing.
JSONObject.optString defaults to empty string ("") if the key doesn't
exist, whereas GeckoBundle.getString defaults to null if the key doesn't
exist. So the correct conversion for `json.optString("foo")` should be
`bundle.getString("foo", "")`. This patch fixes the wrong conversions
from before. In case we did default to null, this patch gets rid of the
redundant null second argument to GeckoBundle.getString.
Follow-up to fix breakage in accessibility caused by the bundle
conversion. In particular, optString(foo) should have been converted to
getString(foo, "") because optString returns "" by default.
Also fix a small bug in Presentation.jsm where an array or null should
be used instead of a string.
Repack of the upstream builds of the rust 1.15.0 stable release.
MozReview-Commit-ID: KDjkSQSFrFA
--HG--
extra : rebase_source : 7ca562b3d1cc4d051d9cfc25ef14fbbe2dbd77bb
They use an older version of Sencha Touch (v2.1.0) which is known
to not be compatibile with Firefox. However, pretending to be Chrome
fixes the issue of not being able to scroll and various paint bugs.
MozReview-Commit-ID: K35ll42Xxlt
--HG--
extra : rebase_source : 26f2e68ff2bc6be7d00a3eba1bedd56a9a7d62be
It seems that there is a wide variety of affected devices, so we should just play it safe
and run the workaround on any device that might be affected. (We already run this code
for _all_ devices for the main app menu, so it doesn't have any adverse affects. On the other
hand it would be nice to remove it eventually, i.e. once we no longer support Android 4 or 5 -
although that's still a long way away.))
MozReview-Commit-ID: 2nOYScRXQLd
--HG--
extra : rebase_source : 4e157683ac0de78f2ffb7336a7d0a0c7b483c502
For homepanels we usually send a long ID string (see the list in HomeConfig). We
reuse the topsites panel to render ActivityStream, so topsites and AS have the
same panel ID. It seems simplest to just override the session name when showing
AS.
MozReview-Commit-ID: JqyyqY77Eo3
--HG--
extra : rebase_source : cd372a4de91c550f30754d40f80ef8c86f6eb1c8
We currently only start a session when swiping between homepanels. We should also send
it when showing the homepanel normally.
MozReview-Commit-ID: 8Kk2RDCbDDc
--HG--
extra : rebase_source : 113474aa6efe5a7e25a2b96a6db5bc049a12d7cf
The Samsung Internet content provider provides both bookmarks and folders,
distinguished by "bookmark_type" (equals 0 for folder, 1 for bookmark). We're
currently importing both types, with folders getting inserted into our db with a
url of null. Such "bookmarks" never seem to surface in UI, and sync ignores
them, but let's stop importing them anyway.
MozReview-Commit-ID: 7G3QuEYBgRb
--HG--
extra : rebase_source : 965e704c5b4d470f90c1e89a69e64d4203374a27
3rd-party-app could launch CustomTabsActivity, and could also configure
a custom action button. Now let CustomTabsActivity supports it by
creating a MenuItem.
MozReview-Commit-ID: 2KuMgBJy2gz
--HG--
extra : rebase_source : 93bcfb33001005d307dba68f898375ab7d86adb2
To support ActionButton in CustomTabsActivity, information should be
extract from intent.
MozReview-Commit-ID: 3C19U0EQfV6
--HG--
extra : rebase_source : a8d941a3fd740d5d8863e748b20de790b8bf589c
This variable is useless. So far we reference to a toolbar instance by
local variable. Removing it makes less ambiguous.
MozReview-Commit-ID: 8zrEKaB2H48
--HG--
extra : rebase_source : e35e3f87876ca497745585134018cff41536b9b0
This shouldn't ever be true - but we have crash reports from
devices running API 10 (Android 2.3), despite having a minimum
requirement of API 15 (Android 4). The cause is unknown, but could
be caused by Google Play bugs (e.g. if it were to ignore an increase
in the minimum SDK), or some other override.
MozReview-Commit-ID: 12uHsDxGPp
--HG--
extra : rebase_source : c6de3f0ed88bf506ca55297323e2670cd5641965
extra : source : 0da24048d1a8206a3a30d6b32c2d11a13cc119f6
I accidentally added this while working on a fix for Bug 1120441,
and forgot to remove it before landing. This call isn't harmful,
but it's unnecessary.
MozReview-Commit-ID: FrnhoYWFvKR
--HG--
extra : rebase_source : d5c4afef36e45bbf8ea4ef4932af55d94ac2a3a3
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
Let password manager handle opening the popup on username fields itself.
MozReview-Commit-ID: FbI6CgsadEd
--HG--
extra : rebase_source : b50f8ecaf5daff5660832894f083e2fda7336e3f
There appears to be a race occurring where InputExhausted callback isn't always called.
The issue could be reproduced prior all those changes, albeit rarely.
The tracking of re-enabling this feature will be done in bug 1336358
MozReview-Commit-ID: 5rPpcCcgNIq
--HG--
extra : rebase_source : bf3513e5ff8d8c72ed7aa505c8fda723a480c243
Our version of the palette support library crashes for certain icons on x86 systems.
MozReview-Commit-ID: E6eEyFXd4uK
--HG--
extra : rebase_source : fe2e3d55ff7744d480c8a6318aba09bb2c519a13
To test different situations
* Intent has custom animation
* Intent has no custom animation
MozReview-Commit-ID: 9KqBJu9x4nw
--HG--
extra : rebase_source : 30820e83d91df185cc70155bb528c4bbe9316869
3rd party app could specify its own custom-exit-animation when launching
CustomTabsActivity.
For that case, to call `overridePendingTransition` in method finish().
MozReview-Commit-ID: CivYpP2jvXp
--HG--
extra : rebase_source : 23f202a08af134f83814ac89b26a1c0d0f480478
This icon contains no arc curves, and has been tested to not display
corruption on Android 4 - we'll hopefully not run into any issues with it!
MozReview-Commit-ID: 8ISTp4i5u4O
--HG--
extra : rebase_source : 445bdaea628b9c23ac77cd6611d9438d70fbe69a
The support library on Android 4 seems have two unrelated VectorDrawable issues:
- overzealous proguarding results in drawable corruption (already fixed)
- arc curves can result in the entire drawable disappearing
This patch fixes the latter issue, by converting all remaining VectorDrawables
(some had already been fixed in a separate bug where arc curves caused corruption
on Android 6).
MozReview-Commit-ID: 2oWRXDnDZ3v
--HG--
extra : rebase_source : bd5413e304360d5ab18b95b2855f65e07a6d8a09
The return value of isKnownContent() now depends on whether we exclude this type of content or not.
This patch updates the test to reflect that.
MozReview-Commit-ID: F4KAVdv2l1X
--HG--
extra : rebase_source : 842e9f382bd7db3f3511624dd7b6a3464d114fd6
Newer versions of the support library do this automatically, but we need to
roll our own implentation for now.
16:9 keyline means that the top of the menu is placed such that a 16:9 window
of application content is still visible above the menu. This is illustrated in:
https://material.io/guidelines/layout/metrics-keylines.html#metrics-keylines-keylines-spacing
(The menu itself is _not_ 16:9.)
MozReview-Commit-ID: FSUdssb5eBN
--HG--
extra : rebase_source : 735cfb9ce7f78e4247780011c76850560f67d40e
This has no benefit right now, but this lets us avoid forgetting to upgrade to the non-deprecated
method once we no longer need to support api 15.
MozReview-Commit-ID: FmRoP5PnGDC
--HG--
extra : rebase_source : 2c5df232fd526f044bd10b3e6cf9920ddb2e4e7b
This seems to be an Android platform bug affecting Android 4.X, which
is visible primarily on tablets (on phones, page titles are often broken
over two lines, which isn't the case on tablets, hence it's easy
to spot if this bug is happening).
MozReview-Commit-ID: AfSw3AJHFqH
--HG--
extra : rebase_source : 125789099f5c7309f2bb049b49341183fa99c3a2
On some devices, ImageView appears to lose it's padding when calling
setBackground[Drawable](). We therefore need to save and restore the
padding on those devices.
Known affected devices are various Asus Transformer tablets,
and also the Motorola Droid 4, running various Android 4.X versions.
We therefore make this workaround conditional on Android 4 to minimise
the number of devices where this workaround is used. (Having the conditional
should also make it easy to notice when we can remove the workaround, i.e.
whenever Android 5 becomes the baseline.)
MozReview-Commit-ID: B88gWwEx48x
--HG--
extra : rebase_source : f22fb850c919a25dd14b46e6dec558e8e8998d7b
Add more callback tests to testEventDispatcher,
1) Test for checking that the callback for a Gecko thread event,
dispatched from Gecko, is synchronous. We depend on this behavior in
several places where we require a "function call" style event.
2) Test for checking that callbacks accept a variety of data types as
the response object, including the standard types supported by
GeckoBundle, as well as primitive types that are convertible to standard
types.
Remove GeckoEventListener and NativeEventListener now that we uniformly
use BundleEventListener. Also remove related classes NativeJSContainer,
NativeJSObject, and GeckoRequest, as well as related tests and C++
code.
The "Messaging" object in Messaging.jsm is replaced with a dummy object
that redirect calls to the global and/or window event dispatcher.
Previously we started the DLC service from GeckoApplication. The reason for that was that we wanted to
download content like fonts as early as possible so that they are available the next time we display
a website.
However we do not know whether we are running in automation until the BrowserApp activity is launched.
This patch will start the service from BrowserApp.onCreate() now if we are not running in automation.
MozReview-Commit-ID: C3Ob6S3yve4
--HG--
extra : rebase_source : 3dbe64f6cbc0a90149e9c46849d4b68e5674b532
This patch adds the ability to run SingletonEventManager handlers in
different modes: sync, async, raw (no exception handling, arg cloning,
or asynchrony), or asyncWithoutClone. When you call the handler,
you're required to specify which variant you want.
Existing uses of SingletonEventManager are all converted to async calls.
Note that some of them were previously synchronous, but it didn't appear
to be necessary.
Also added a callOnClose for SingletonEventManager when the last listener
is removed.
MozReview-Commit-ID: ATHO97dWf3X
--HG--
extra : rebase_source : bf02d79e3fbab84892be8a7e52ea7a1caf2e003d
CLOSED TREE
Backed out changeset 2d42350d209a (bug 1203330)
Backed out changeset 3a12c51c3eca (bug 1203330)
Backed out changeset 31fac390e15d (bug 1203330)
Convert events used in PageActions to bundle events. UI thread events
are used because the listeners require the UI thread. The observer
notifications from Java to Gecko are converted to events as well.
Convert events used in AccountsHelper to bundle events. Most events are
kept as Gecko thread events, but a couple events that start activities
are converted to UI thread events.
Convert events used in IntentHelper to bundle events. UI thread events
are used for most events because the listeners perform operations on
Intent objects, which is best done on the UI thread. For
"Intent:GetHandlers", use a Gecko thread event because it's possible we
want a synchronous callback response.
Convert events used in HomePanelsManager to bundle events. Background
thread events are used because HomePanelsManager processes panel changes
in the background thread. Changing to background thread events also lets
us make the change queue a simple ArrayList instead of a
ConcurrentLinkedQueue, because there is no longer multiple threads
involved.
Convert the "HomePanels:Data" event to a GeckoBundle/BundleEventListener
event. UI thread event is used because the listener invokes the callback
on the UI thread.
Convert events used in FindInPageBar to GeckoBundle/BundleEventListener
events. UI thread events are used because the listener performs UI
operations. FindInPageBar also sends some events like "FindInPage:Find"
from Java to Gecko; those events will be converted in another bug.
Convert observers in ActionBarHandler.js to events that go through
WindowEventDispatcher. "TextSelection:Get" now replies through the
callback interface rather than a "TextSelection:Data" event. The patch
also adds new lazy-loading events in browser.js to replace the
lazy-loading observers that ActionBarHandler relied on.
Convert the events used in MediaCastingBar and ChromeCastPlayer to
GeckoBundle/BundleEventListener events. UI thread events are used
because the listener performs operations on the UI thread.
When going down one folder level, we store the current scroll position of the list view and then scroll to the top of the list, so that we always show a child folder starting from the beginning. When navigating back up to its parent, we then restore the previously stored scroll position.
MozReview-Commit-ID: 9C2RMXrlUm1
--HG--
extra : rebase_source : 7ec5a3f1d602db9454efa52603e0f50704c1418d
Fix up javadoc so it matches the actual function parameter and remove unneeded imports.
MozReview-Commit-ID: I91NuqLlpL1
--HG--
extra : rebase_source : 13366049ee9fe1487b3cf24f4e6f610f66bee5ee
Showing the tab history panel involves a gecko call to retrieve tab history. This
can be slow, meaning we have no idea what state the app will be in when the tab
history data is returned. Thus we need to protect the code that shows the tab
history fragment against a number of scenarios to avoid crashes in those cases
where the app might be shutting down:
1. If onSaveInstanceState() has been called (which might happen before or after onPause(),
and might be linked to app shutdown - but the docs don't appear to give any guarantees),
fragment transactions cannot be performed. We protect against this by accepting loss
of state in fragment transactions.
2. If the Activity has been completely destroyed, trying to perform a fragment transaction
will likewise fail. We protect against this by not even trying to perform the transaction
if we definitively know that the Activity is being shut down (ie isFinishing()).
In both of these cases, we simply must accept that we're potentially losing UI state: i.e.
a user could request the tab history panel via long-back-press, followed by exiting the app;
we now end up never ever showing the panel. This scenario doesn't seem like a major loss - and
fixing this issue properly would require significant investment (i.e. we would need to either
cache tab history on frontend side, or cache the tab-history panel request - and it's not clear
users will still care about seeing the panel the next time they open firefox).
MozReview-Commit-ID: JsAK1By8yqn
--HG--
extra : rebase_source : 9a3b64d2829a969e4de2775c2714874aa8708031
Since bug 1228593, the mobile session store
- once again flushes its data when we are quitting, to make sure the latest state (including any potential cleaning of history/tabs) is flushed to disk
- ignores windows/tabs closing as a byproduct of shutdown
The latter point is dependent on a new shutdown notification introduced in that bug. Because we forgot to add that notification to the restart code used for add-on updates, in that case the session store currently doesn't enter shutdown mode and therefore records the window being closed during shutdown before flushing its data to disk, which means that all open tabs are lost.
MozReview-Commit-ID: LgtdQoYwacM
--HG--
extra : rebase_source : 1bf6c544d9e25961a0e64236678ca5938e8a69fe
A tab object should know how to zombify itself instead of having to rely on the MemoryObserver. This also simplifies the situation for anybody else who wants to call this function since it is no longer necessary to figure out how to load the MemoryObserver for this.
MozReview-Commit-ID: 5IX114QUjBT
--HG--
extra : rebase_source : 964186678848b804e5f0550e1b6a328d7fcfbc50
Actors outside of the session store shouldn't have to poke around within the session store's data structure and end up reimplementing parts of the session store code (and cause data loss if the implementation is incomplete) in order to restore delay loaded zombie tabs. Therefore, we simply expose a method for this via BrowserApp's tab object.
To simplify handling and make the method a little more fool-proof for external callers, the check whether the tab is actually zombified is moved into the restoreZombieTab() function.
Later on, we can also hook up this method to the appropriate web extension API (see bug 1322485).
MozReview-Commit-ID: 85lnbCpMcP3
--HG--
extra : rebase_source : a6f1cfa11debcb18471b49804776521c60655fce
With --with-intl-api, xpcshell test for MozIntl is always failure on Android. So we should add mozIntl.xpt to package.
MozReview-Commit-ID: BWBKSG3gSqr
--HG--
extra : histedit_source : d4091b91221bc2ef282d0855dbf4856adb403c9b
Bug 1319660 - 1. Don't take shortcut if old replacement ranges don't match; r=esawin
The block at [1] is a shortcut we take when we reconcile Java text
changes with Gecko text changes. However, we only checked that the new
ranges are the same, i.e. that the new Gecko text is the same as the new
Java text. We should also be checking that the old ranges are the same,
i.e. that the replaced Gecko text is the same as the replaced Java text.
[1] https://dxr.mozilla.org/mozilla-central/rev/bbbd2f7539f224a482cc6d2dd10e6a5f31c8baf3/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoEditable.java#1233
Bug 1319660 - 2. Use previous node instead of sibling when adjusting last node; r=masayuki r=smaug
nsContentIterator in pre mode adjusts its last node if the node is a
childless node like <br>. However, right now it's using GetPrevSibling,
which can lead to error in some edge cases such as:
<p></p><div><br></div>
In this case, if the last node is <br> with offset 0, GetPrevSibling
will return <p> because <p> is <br>'s parent's previous sibling, and the
last node will be set to <p>. However, the correct last node in this
case is <div>, because <br> with offset 0 refers to the position to the
left of <br>, which is <div> with offset 0. In this case, PrevNode
returns the correct <div> value, so we should set the last node to the
result of PrevNode.
For the first node, for a childless node in pre mode, GetNextSibling and
NextNode are the same, so there is no bug in this case. Nevertheless,
this patch changes the call to NextNode to be consistent with calling
PrevNode for the last node.
Bug 1319660 - 3. Add test for correctly adjusting last node in content iterator; r=masayuki
Add a test for the previous patch that makes sure querying selected text
in an edge case works correctly.
Bug 1319660 - 4. Add test for start node regression; r=me
Add a new test case for the NextNode() regression. r=me for trivial
test-only patch.
Bug 1319660 - 5. Restore GetNextSibling call for first node of pre-content-iterator; r=smaug
The last patch changed the `GetNextSibling()` call to `NextNode()`
because I assumed they're equivalent in this case. That turned out to
not be the case because we can reach this line even if the node has
children -- the index just has to be after the last child. So this patch
restores the `GetNextSibling` call to restore the correct behavior.
I also added some comment to clarify that we can reach this line due to
one of two conditions: 1) the node has no children; 2) the node has
children but the index is after the last child.
This patch also replaces the `HasChildren()` check when setting
`cChild`. If the index is after the last child (i.e. index ==
childCount), `GetChildAt()` fails and we erroneously log an assertion
warning, even though the input was valid. The new check handles all
cases whether start node has children or not.
Bump the Android builders to the latest beta release to reduce
the variance when we update Firefox 53 to 1.15.0 stable early
in the Aurora phase.
Android builds were moved to 1.15 early to address a code generation
issue with devices without neon.
Work around an issue with tarball naming in the cargo packages.
MozReview-Commit-ID: KQfkWmXV9hQ
--HG--
extra : rebase_source : 9448e0b948740fc3905ef70c8df316dc7342d52e
When turning off SPS profiler by configure option, or we build non-SPS arch build such as android/aarch64, Tab.prototype.onStateChange already throws the exception because Profiler isn't defined.
So we should check AppConstants.MOZ_ENABLE_PROFILER_SPS to use Profiler object.
MozReview-Commit-ID: A9ISurxiRmc
--HG--
extra : rebase_source : 25103e97cd4827edef33335e3aec9384a6695526
When a snackbar with a button callback is dismissed, this translates to a rejected promise from sendRequestForResult(). We need to catch this in order to avoid a spurious 'JavaScript Error: "uncaught exception: undefined"' message appearing in the console and possibly causing confusion.
MozReview-Commit-ID: 7hsAOAMTeDP
--HG--
extra : rebase_source : 6c5eb28d2e0dcf39a35b310d1e1c45cfc47f272b
We've been parsing the session store file and doing the initial tab creation on the Java side for a long time now, so the code to open completely new tabs on the session store side instead of using tab stubs is no longer necessary.
Besides, because of bug 1301160 the on-disk session file is now containing tab IDs as well, so this distinction between tabs read directly from the raw session file and those contained in a session string passed over from the Java UI is no longer available.
MozReview-Commit-ID: Hmq0TwClqMQ
--HG--
extra : rebase_source : 1f9ab6da18a7fd0f40a1cb0784082abb2384404f
brainbreaker
Edouard Oger
Andrzej Hunt
Phil Ringnalda
Christoph Kerschbaumer
Kris Maglione
Jan Henning
Wes Kocher
Ralph Giles
Tom Klein
Julian_Chu
Nevin Chen
Carsten "Tomcat" Book
Aman Dwivedi
Grigory Kruglov
Jim Chen
Eugen Sawin
Mike Taylor
Jean-Yves Avenard
Adam Velebil
Shan
Tushar Saini (:shatur)
Chris Manchester
Sebastian Hengst
Dylan Roeh
Matthew Noorenberghe
maliu
Chris Peterson
Sebastian Kaspari
Tim Huang
Swaroop Rao
Daniel Holbert
srivatsav
jdarcangelo
Andrea Marchesini
Krishna
Benjamin Smedberg
Florian Quèze
jwu
Andrew Swan
Justin Wood
Tooru Fujisawa
Tomer Cohen
Makoto Kato
James Cheng
Michael Kaply
cnevinc
Nicholas Nethercote