Instead of using long_press_without_contextmenu() with built-in long tap
injector in AccessibleCaretEventHub to select a word, we can use
DOMWindowUtis to send synthesized mouse long tap events to gecko. This
triggers the code path which is closer to the real events fired by APZ
on B2G.
This change also makes marionette tests cover the focus-changing code by
long tap in AccessibleCaretManager. This is subtle but significant since
it's possible to write focus changing tests via long tap now.
* Use word_location() and long_press_on_location() to implement
long_press_on_word.
* Use long_press_on_location() instead of
long_press_without_contextmenu().
* Eliminate the duplicated code for setting the preferences.
* Rename open_test_html() in test_selectioncarets2.py to
open_test_html_multirange() to avoid name collision.
This is slightly more involved than earlier changes because reftests
have a one-off mechanism for finding files. Essentially, the master
reftest manifest is loaded, directories are discovered, and every file
in those directories is packaged.
We add support to our test archive generation tool to read sources from
reftest manifests and tell it where the reftest manifests are.
print-manifest-dirs.py was only being used for staging reftest files.
Since we don't do that any more, the functionality doesn't need to exist
in a standalone file, so it has been moved inline into test_archive.py.
This change avoids copying ~26,000 tests consuming 131 MB during test
packaging. This is a majority of the file count that was remaining in
the stage directory at this point. On my machine (which hasn't typically
seen major wall time wins from not staging files due to its fast SSD),
this change made test packaging ~20% faster, reducing wall time from
~50s to ~40s!
A Try push seemed to indicate drastic results with the series up to this
point. Including the already landed changes to generate test archives
concurrently, test packaging times on OS X builders dropped from ~18:40
to 6:29! Times on Linux x64 remained about the same (~2:46). This is
possibly due to these machines already having SSDs and due to normal
variance in performance of builders and EC2 instances.
When inspecting the specified value of {transition,animation}-timing-
function on a declaration, we should omit the start/end keyword in a
steps() value if it was omitted in the style sheet.
The CSS Transitions and Animations specs define the computed value of
a {transition,animation}-timing-function property as being the same as
the specified value, so we should expose the specific value we recorded
on nsTimingFunction in Part 1 through nsComputedDOMStyle.
Since Keyframe.easing should reflect the {transition,animation}-timing-
function value relevant to each keyframe, we'll need to store on
nsTimingFunction the specific timing function value that was used, and
copy it down into ComputedTimingFunction for
KeyframeEffectReadOnly.getFrames() to access. This includes storing
whether the optional start/end keyword in a steps() function was
specified.
