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
The protocol handler is intentionally simple. It works for the entering into the
urlbar case but not a lot else. Included some basic tests.
MozReview-Commit-ID: 4FQ1irdt3Nj
--HG--
extra : rebase_source : 30d9fc7ba2c500f268d282e47d291724d9899ba4
Unfortunately tinting the bookmark star is highly complicated due to the tinting
that NavigationView performs (i.e. we'd likely have to disable NavigationView
tinting, and do manual tinting on every icon - alternatively we could hack
the tint-list to use blue for "checked" items, and set the bookmark item
as checked). Since it's unclear if we even want the star to be blue,
we'll leave it grey (but filled) for now.
MozReview-Commit-ID: DekRZJayKIz
--HG--
extra : rebase_source : 1e3443e5f09c60bd0d7295bc35ecc08ca17b3dab
See https://code.google.com/p/android/issues/detail?id=209558 . On Devices
running Android 4 and below, VectorDrawable's can be corrupted due
to overzealous proguarding. This doesn't appear to have been
fixed in the support library yet, and even if it were fixed we
still wouldn't be able to switch to the most modern support
library without significant work.
MozReview-Commit-ID: 3ByogGygCEd
--HG--
extra : rebase_source : 2adeed63f88ca39a71feec60627fb812b76d3bb4
Previously if we could not compare two icon descriptions we'd always return the "right" one. This does
not create a consistent order if the parameters are flipped. As a result some operations on a TreeSet
can fail (like remove()).
MozReview-Commit-ID: EYPlhzGUEnD
--HG--
extra : rebase_source : f8918c022188401e21a03ac666628cff3e87f317
Also refactor MediaControlService to be test-friendly.
MozReview-Commit-ID: 344cEEuVroG
--HG--
extra : rebase_source : 14042bc3225538f621605b7aadb9d729c01ac62b
When the playing-media changes (ie. in Youtube click another
video when it is alreay playing one), there will be one more
event MEDIA_PLAYING_CHANGE, and the tab is still playing media.
This fix is to handle this situation then update state.
MozReview-Commit-ID: Aje2BBqFZKE
--HG--
extra : rebase_source : f7c8f80c1d49e3a9aef868d11a4cd9d722a5c221
This patch involve State into MediaControlService.
ACTION is behaviour for an intention, and so far we use it for storing
media state. Now involve enum to distinguish State from Action.
So flow becomes: Action happens -> Change State -> UI reflect state
changing.
MozReview-Commit-ID: FBHn02tgVO6
--HG--
extra : rebase_source : e1c57502a13669fad0ee2848c6cff420ebbe064f
