Open Bug 996986 Opened 6 years ago Updated 1 year ago

test_movement_by_words.html broken on Linux/GTK+ for reasons other than those documented

Categories

(Core :: Widget: Gtk, defect, P5)

All
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mozilla3, Unassigned)

References

Details

Attachments

(1 file)

layout/generic/test/test_movement_by_words.html is disabled on Linux/GTK+ because "the shortcut keys are defined in system level.  So, it depends on the environment" (http://mxr.mozilla.org/mozilla-central/source/layout/generic/test/mochitest.ini#104).  However, on a Linux system with GTK+ 3.10.8 set to the default of Ctrl+Left/Right for word movement, the test fails anyway, which suggests that the test is broken on Linux/GTK+ for a more fundamental reason than variable shortcut keys.

If I leave wordModifiers (http://mxr.mozilla.org/mozilla-central/source/layout/generic/test/test_movement_by_words.html?force=1#30) set to the default of {ctrlKey:true}, or if I explicitly set any one of the Ctrl/Alt/Meta modifiers, I get behavior similar to the breakage described in bug 916143 (see attached log).  If I force wordModifiers to be empty, the test failures change to lines like "Right movement broken with eatSpace=false, stopAtPunctuation=true in "Hello Kitty"; sel.anchorNode.parentNode=[object HTMLDivElement] - got 1, expected 5" (note "1", instead of "0" as seen in the log).  This suggests to me that keypresses with modifiers are not being handled correctly, but I haven't been able to track down the problem.
Blocks: 907612
Masayuki, do you know which part of the code needs to be fixed?
Flags: needinfo?(masayuki)
Yeah, we need to generate and attach a native event to keypress event. Cocoa does it:

http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsChildView.mm#1646
http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/TextInputHandler.mm#4363

FYI: it's becoming nsIWidget::AttachNativeKeyEvent(), see bug 993714.

However, GdkEvent isn't managed by refcounting. So, we need to implement a way to release the generated native event. Perhaps, nsIWidget::DetachNativeKeyEvent()?
Flags: needinfo?(masayuki)
BTW, I strongly recommend to disable tests which depends on native key bindings on Linux since it may fail on some other environments.
I'm worried that testing only non-Linux platforms doesn't cover Linux sufficiently.
Component: Layout → Widget: Gtk
Hardware: x86_64 → All
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #3)
> BTW, I strongly recommend to disable tests which depends on native key
> bindings on Linux since it may fail on some other environments.

IMHO, it's reasonable to say "on Linux, these tests must be run with default key bindings".  There may be cases in which nonstandard bindings cause some functionality not to work correctly, but that shouldn't preclude testing that the functionality works with standard bindings.  And if someone (especially a developer) has changed the key bindings from the default, presumably they also know how to change them back for the purpose of testing.

If you really wanted to, you could probably even override the user key bindings for the test, perhaps with https://developer.gnome.org/gtk3/stable/gtk3-Bindings.html or some such.
native key bindings on linux depends on distribution and/or its version, sigh...

I struggled with it at writing following tests, but finally, I disabled them on Linux...

http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/text/tests/test_texteditor_keyevent_handling.html?force=1

http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/text/tests/chrome.ini#6
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)
> native key bindings on linux depends on distribution and/or its version,
> sigh...
> 
> I struggled with it at writing following tests, but finally, I disabled them
> on Linux...
> 
> http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/text/tests/
> test_texteditor_keyevent_handling.html?force=1
> 
> http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/text/tests/
> chrome.ini#6

Again, the fact that not all system configurations can run all tests should not preclude running those tests on the most common configurations.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)
> native key bindings on linux depends on distribution and/or its version

I don't think it's unreasonable to require that all Linux machines that we run
tests on centrally use the same key bindings, to some degree anyway.
(I'm assuming it's relatively easy to configure these key bindings as needed.)

I'm not at all worried about some tests failing locally, that happens a lot
already (for me anyway).
You need to log in before you can comment on or make changes to this bug.