These tests are added per bug 1251519 comment 10.
test_move_cursor_to_front_by_dragging_caret_to_front_br_element() covers
example 1, and test_drag_caret_from_front_to_end_across_columns() covers
example 3. Example 4 is not easy to write in marionette test since it's
difficult to know whether an image is selected.
Both tests will fail if we clamp the dragging point by using only the
text frame rects as the patch attached in bug 1251519 comment 7.
MozReview-Commit-ID: CKZQKGI6YUw
--HG--
extra : rebase_source : 72f5c2a960c2659fe5015a3ab488d4baa1918059
CLOSED TREE
Backed out changeset 4fa5b5a25f04 (bug 1251372)
Backed out changeset 502cf531ec26 (bug 1250616)
Backed out changeset 2f25d03334b2 (bug 1250616)
- To avoid confusion, call the blinking cursor (nsCaret) "cursor" so that
AccessibleCaret can be called caret for short.
- Add second_caret_location() as a helper function, and use it in
selection mode tests.
MozReview-Commit-ID: IKN6KuR92HE
--HG--
extra : rebase_source : c247ad6b61bc1b1cc3c4d8784584e19d9ef5c1ea
* Inline some of the open_*_html methods since they're called only once.
* Save test running time by finding the elements needed in tests instead
of find all of the elements in open_*_html methods.
* Remove test_long_press_to_select_non_selectable_word() since it's
covered by test_focus_not_changed_by_long_press_on_non_selectable().
* Use hyphen for element ids.
* Replace "left" and "right" caret by "first" and "second" caret,
respectively.
MozReview-Commit-ID: Ey5m5zO3HYc
--HG--
extra : rebase_source : c94b84ced75560ce1167cda35ee94dd4cc81ee4d
The existing task's outcome is best achieved with a special purpose
build task, so here it is.
MozReview-Commit-ID: 3gYnAb69TdK
--HG--
rename : mobile/android/config/mozconfigs/android-api-15-frontend/nightly => mobile/android/config/mozconfigs/android-api-15-gradle-dependencies/nightly
rename : mobile/android/config/tooltool-manifests/android-frontend/releng.manifest => mobile/android/config/tooltool-manifests/android-gradle-dependencies/releng.manifest
extra : rebase_source : 252c283553d64bac17c2b922773023a349c297ea
extra : histedit_source : 2d8becbcdfa5d37829552e55b50fb7f9cbf56dea
This container formerly defined a special Gradle project for fetching
dependencies. This patch lays the ground-work to use the in-tree
Gradle project instead. Using the in-tree project looks like first
starting a local Nexus repository to collect downloaded dependencies
(before.sh); then running a build which populates that repository; and
then packaging up the downloaded dependencies (after.sh). The patch
after this will define the build which populates the repository.
Sadly there's no easy way to *inherit* from desktop-build, so this is
a copy-paste-modify clone.
MozReview-Commit-ID: Dd5Hj8hkJVk
--HG--
extra : rebase_source : dcfe245b23eb28e99b1506eebe053142c9e242b3
extra : histedit_source : f21014636de958c5ddf27ca2a1eb156e3c88bd78
When a built-in root certificate has its trust changed from the default value,
the platform has to essentially create a copy of it in the read/write
certificate database with the new trust settings. At that point, the desired
behavior is that the platform still considers that certificate a built-in root.
Before this patch, this would indeed happen for the duration of that run of the
platform, but as soon as it restarted, the certificate in question would only
appear to be from the read/write database, and thus was not considered a
built-in root. This patch changes the test of built-in-ness to explicitly
search the built-in certificate slot for the certificate in question. If found,
it is considered a built-in root.
MozReview-Commit-ID: HCtZpPQVEGZ
--HG--
extra : rebase_source : 898ef37459723f1d8479cfdc58658ccb00e782a9
xpcshell tests used to use head_*.js files so this adds those for global
discovery.
MozReview-Commit-ID: BOsoGIpwdgu
--HG--
extra : rebase_source : ef36531641cbd353625019f8deba333cfd352891
extra : source : 70eca07367f40a9b4fe8c6e23ec0aef73bf2a962
This defines a few additional globals but also turns on the browser environment
for everything in browser and toolkit. This may lead to some false negatives
but we have lots of code that runs in a browser context so in the name of
getting rules turned on I think this is a useful step.
MozReview-Commit-ID: BdWouZGK6d
--HG--
extra : rebase_source : a88116d149af76aa35ee0757b3b51b6f97646ebe
extra : source : 04c1740aa49904a56bd662ee0c8aed69e6f99f8b
This adds more of the scripts that browser.js relies on and also makes
browser-chrome head files import the browser.js globals.
The MOZ_JSDOWNLOADS block in contentAreaUtils only seems to hide a single
function, I don't see any need to keep hiding that now we're on by default.
MozReview-Commit-ID: 5zvF3JtJrZG
--HG--
extra : rebase_source : 94daff602b51d7ad57a24872d9eba9b304cf2da9
extra : source : b554c7ce41c42f16c2279ae88fd9567da7509bff
To properly lint XBL files we need to support things like import-globals-from
and other ESlint comment directives so we have to pass comments through to the
code blocks that ESlint parses. Unfortunately the way the XBL processor works
now is by passing a separate code block for every method/property/etc. in the
XBL and ESlint doesn't retain state across the blocks so we would have to prefix
every block with every comment. Instead this change makes us output just a
single block that roughly looks like this:
<comments>
var bindings = {
"<binding-id>": {
<binding-part-name>: function() { ... }
}
}
This has some interesting bonuses. Defining the same ID twice will cause a lint
failure. Same for the same field in a binding. The line mapping is a little
harder and there are still a few lines that won't map directly back to the
original file but they should be rare cases. The only downside is that since
some bindings have the same binding declared differently for different platforms
we have to exclude those from linting for now.
MozReview-Commit-ID: CAsPt5dtf6T
--HG--
extra : rebase_source : 91a60ef0359ef53093fe197ed63dbc4e1a9f10a5
extra : source : 01675e4828b524c04a9057d68b41e9cc01ca1bb9
While working on turning on no-undef I discovered that the various rules we
have for defining globals are a little inconsistent in whether the files they
load recurse through import-globals-from directives and none of them imported
eslint globals directives.
I think we're better off putting all this global parsing code in a single place
rather than spread across multiple rules. Have one rule to turn it on for
parsed files and one function to load globals from other files and make them
share most of the code so we won't get inconsistent. If we find us needing to
turn on/off individual features we can figure out a way to do that in the
future.
This patch does that, the globals.js file does all global parsing with a shared
object that receives events from the AST, either through from an ESlint rule
or from a simple AST walker using estraverse.
MozReview-Commit-ID: 9KQZwsNNOUl
--HG--
extra : rebase_source : 0f1cceca29ac398be97a55bbcd09fe58a8be1435
extra : source : 878db4caf845282f06542793bc4b5c24fa658c14
Steve Fink
Kim Moir
Carsten "Tomcat" Book
Joel Maher
Marco Castelluccio
Matthew Noorenberghe
Ting-Yu Lin
Gregor Wagner
Daisuke Akatsuka
Andreas Tolfsen
Ryo Motozawa
Phil Ringnalda
Rail Aliiev
Wes Kocher
Nick Alexander
Geoff Brown
Aki Sasaki
Andrew Halberstadt
Ehsan Akhgari
David Keeler
Johan Lorenzo
Dave Townsend
Aki Sasaki
Xidorn Quan
Brian Birtles