For test_bug648573.html and test_bug644768.html, we no longer need to
create an iframe to turn off the preferences. I move the content of
iframe.src back to the test files.
For test_bug648573.html and test_bug644768.html, we no longer need to
create an iframe to turn off the preferences. I move the content of
iframe.src back to the test files.
We already had focus changing tests covered by
_test_focus_obtained_by_long_press(). This patch adds tests for focus
not being changed from an editable element after long-pressing on a
non-selectable element.
These tests will fail after reverting this change.
"Bug 1197739 - Do not change focus too early unless the frame is selectable"
https://hg.mozilla.org/mozilla-central/rev/4f2822bbbdb2
TouchCaret does not have this issue since it clamps the dragging point
to the editable content boundary.
Fix this bug by porting TouchCaret::GetContentBoundary() to
AccessibleCaret. I apply the clamp logic to both cursor mode and
selection mode if the focus node is on an editable content, which makes
carets dragging in selection mode smoother than SelectionCarets.
Test the second carets can still be dragging after its appearance
changing from Normal to NormalNotShown then back to Normal again. This
test is only for AccessibleCaret, not for SelectionCarets.
word_location() did not work if there are multiple spaces between words.
We split by \S+ which is non-spaces, so tokens[0] is an space token.
Test cases are added to ensure the correctness.
To get the same behavior across all platforms for carets test, disable
'layout.word_select.eat_space_to_next_word'. In this way, we don't need
to worry about the spaces being selected on Windows, and those strip()
in individual tests can be eliminated.
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.
The CSS scroll snapping specification defines percentages to be
`relative to same axis of the padding-box of the scroll container`,
which means that y-axis should be based no height, not width.
When a TEXTAREA element is focused it returns the cursor to the last
position was at, or places it last. INPUT @type="text" (or any other
textual input element) places the caret at the beginning. Because of
this we move the caret to the end of the input field. The next time
the element is focussed, the cursor should move to the end.
The layout touch caret tests relied on the caret being left in its
previous position. This patch addresses that by using the advanced user
interaction API for these test cases.
r=jgriffin
This functions is for hiding caret in cursor mode on desktop browser
when receiving NS_WHEEL_WHEEL, which is never used on B2G in production.
On desktop browser, a proper wheel scroll cycle begins by NS_WHEEL_START
and ends by NS_WHEEL_STOP, which was covered by gtest. Move the three
marionette test for TouchCaret only.
This is the patch which fixed the bug.
When calling OnScrollPositionChanged in cursor mode, we want the
appearance of the caret to be preserved since the caret might be hidden
due to timeout. We should respect the old appearance of the caret.
Add a marionette test to ensure the caret does not appear due to
ScrollPositionChanged.
There is a common pattern on the web where a click listener is registered on a
container element high up in the DOM tree, and based on the target of the click
events, it performs the appropriate action. In such cases, our existing fluffing
code was not getting activated anywhere inside the container, because the entire
container was considered clickable. However, this is not user-friendly because
often the actual targets inside the container are small and hard to hit. Also,
the fluffing code will often take the container element itself as the target,
even if the user actually hit something inside the container.
This patch changes this behaviour so when an event hits inside a clickable
container, fluffing still occurs, but is restricted to DOM descendants of the
container. This allows fluffing to work in the above scenarios, and since the
events will bubble up to the container, the listeners on the container are
guaranteed to still trigger.
There is a common pattern on the web where a click listener is registered on a
container element high up in the DOM tree, and based on the target of the click
events, it performs the appropriate action. In such cases, our existing fluffing
code was not getting activated anywhere inside the container, because the entire
container was considered clickable. However, this is not user-friendly because
often the actual targets inside the container are small and hard to hit. Also,
the fluffing code will often take the container element itself as the target,
even if the user actually hit something inside the container.
This patch changes this behaviour so when an event hits inside a clickable
container, fluffing still occurs, but is restricted to DOM descendants of the
container. This allows fluffing to work in the above scenarios, and since the
events will bubble up to the container, the listeners on the container are
guaranteed to still trigger.
These are SpiderMonkey-proprietary legacy feature which has been deprecated
and is expected to be removed in due course.
This commit also fixes a number of bugs in test_bug708874.xul. In particular,
because of the semicolon after the for head, the (alleged) loop body was only
executed for the final element of the array ({}), and because each of the
functions under test threw an exception, only the first call was executed.
I do not know of a way to test the changes in frame-verify.js, so I can't
guarantee they actually work.
