1419091 - Figure out an alternative to the key handling defined with XBL in the platformHTMLBindings.xml files

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, task, P2)

Description

[Brian Grinstead [:bgrins]]

There are a number of files used to define "inputFields", "textAreas", "browser", and "editor" bindings.

Note that "inputFields" and "textAreas" use the bindToUntrustedContent="true" attribute and are referenced via -moz-binding in forms.css: https://dxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css#106.

"browser" and "editor" are loaded in a different way in nsXBLSpecialDocInfo::LoadDocInfo: https://dxr.mozilla.org/mozilla-central/source/dom/xbl/nsXBLWindowKeyHandler.cpp#94 and have at least some special cased code used referencing it in nsXBLService::LoadBindingDocumentInfo: https://dxr.mozilla.org/mozilla-central/source/dom/xbl/nsXBLService.cpp#923-925. It's not clear to me if "inputFields" and "textAreas" are being loaded this way in addition to the reference in forms.css.

There are a total of 20 bindings here (4 bindings each in these 5 files):

- https://dxr.mozilla.org/mozilla-central/source/dom/xbl/builtin/android/platformHTMLBindings.xml
- https://dxr.mozilla.org/mozilla-central/source/dom/xbl/builtin/emacs/platformHTMLBindings.xml
- https://dxr.mozilla.org/mozilla-central/source/dom/xbl/builtin/mac/platformHTMLBindings.xml
- https://dxr.mozilla.org/mozilla-central/source/dom/xbl/builtin/win/platformHTMLBindings.xml
- https://dxr.mozilla.org/mozilla-central/source/dom/xbl/builtin/unix/platformHTMLBindings.xml

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I am trying to take a shot at this. I don't know about the previous conversation had, but what I have in mind, for <input> for example, is:

1. Intercept the key events here in |HTMLInputElement::PostHandleEvent| right before we do key handling for <input range>

https://dxr.mozilla.org/mozilla-central/rev/f7c5598e45c323547dc6d030bf8442850c15813b/dom/html/HTMLInputElement.cpp#4435

2. Get the applicable nsIController, which involve copy and reduce the function |nsXBLPrototypeHandler::GetController| into HTMLInputElement

https://dxr.mozilla.org/mozilla-central/rev/f7c5598e45c323547dc6d030bf8442850c15813b/dom/xbl/nsXBLPrototypeHandler.cpp#665-706

3. controller->DoCommand(...);

It would need some iterations to keep the code dry enough. Can this be the right approach?

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Here are a few interesting findings:

1. Copy/paste/select etc continue to work even when I removed all XBL <handler> on a Mac, including the ones on the browser and the editor binding. I guess the keys will get picked up by the OS if we don't handle it? I will try to test this out on Linux later.

2. I would need to make modifier filter code somehow accessible to both HTMLInputElement and HTMLTextAreaElement. Not sure the best way to do this (another C++ class maybe?)

https://dxr.mozilla.org/mozilla-central/rev/7208b6a7b11c3ed8c87a7f17c9c30a8f9583e791/dom/xbl/nsXBLPrototypeHandler.cpp#919-946

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: WIP bug 1419091

Review commit: https://reviewboard.mozilla.org/r/223578/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/223578/

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Hi bz,

Would you mind take a look at the patch I've attached? The basic idea is documented in comment 2 —- move the key handling to `HTML{Input|Textarea}Element::PostHandleEvent`. The WIP here only manually converts the part that I've commented out. I will move forward if you agree with the approach. Thanks!

Comment 5

[Boris Zbarsky [:bzbarsky]]

This seems like a question for Olli...

Comment 6

[Boris Zbarsky [:bzbarsky]]

But some concerns I have:

1) Is PostHandleEvent the right time to do this, conceptually?
2) The current setup is sort of nice in that you write down data and then all the code is shared.
   Not sure about performance, but it makes the maintainability a lot better.  It also allows
   modifications to the keys without changing C++ and recompiling.  I wonder whether we can
   preserve these properties somehow...
3) It looks like the new code can run on elements without frames (whereas I suspect the old code
   could not).  That might be OK as long as all the command machinery can deal...

Comment 7

[Boris Zbarsky [:bzbarsky]]

In particular, I would much prefer it if we stuck with a data table plus code to run on it even if this is all in C++.  It would be a lot more readable than open-coding the whole thing, I think.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

I think that you should hack native key bindings:
https://searchfox.org/mozilla-central/source/widget/cocoa/NativeKeyBindings.mm
https://searchfox.org/mozilla-central/source/widget/gtk/NativeKeyBindings.cpp

Unfortunately, you need to create them for Windows and Android newly, though.

However, this path must be safer than creating new path for the others because we've already used this path for respecting native key bindings especially on macOS.  For example, you can use emacs like shortcut keys in editor only on macOS even though we don't declare the key bindings.  The command comes with native key event of Cocoa and solved by NativeKeyBindings.

# I think that it'd be nicer if we don't need to recompile when we change the key bindings.  On the other hand, if we could *switch* key binding dynamically from C++ code, we might be able to provide other key bindings set for users. E.g., emacs key bindings and vim key bindings. Anyway, we need to hack editor a lot especially for supporting vim key bindings though.

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Thanks for the input.

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #7)
> In particular, I would much prefer it if we stuck with a data table plus
> code to run on it even if this is all in C++.  It would be a lot more
> readable than open-coding the whole thing, I think.

I haven't thought about what else can be done. I will keep investigating assuming it's still efficient for me to work on it.

For now, I have converted my patch to use a for loop to check through a static array for the matched key and modifiers. The caveat there being I cannot create the static array as a standalone one at the top of the file, because I cannot call WidgetInputEvent::AccelModifier() at that time.

Comment 10

[Boris Zbarsky [:bzbarsky]]

You could use a magic-value placeholder that means "WidgetInputEvent::AccelModifier" in the array...

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8954524 [details]
WIP bug 1419091

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/223578/diff/1-2/

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Comment on attachment 8954524 [details]
WIP bug 1419091

https://reviewboard.mozilla.org/r/223578/#review231158

I still don't understand why don't you hack NativeKeyBindings. I disagree with adding new shortcut key event handler into some places.

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #12)
> I still don't understand why don't you hack NativeKeyBindings. I disagree
> with adding new shortcut key event handler into some places.

I haven't look into your suggestions. It's not obvious to me how that could work. I'll need time to investigate. I was uploading my iteration of the previous attempt over the weekend for record-keeping — sorry about making you mistaken that.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #13)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #12)
> > I still don't understand why don't you hack NativeKeyBindings. I disagree
> > with adding new shortcut key event handler into some places.
> 
> I haven't look into your suggestions. It's not obvious to me how that could
> work. I'll need time to investigate. I was uploading my iteration of the
> previous attempt over the weekend for record-keeping — sorry about making
> you mistaken that.

WidgetKeyboardEvent can store edit commands with arrays:
https://searchfox.org/mozilla-central/rev/a70da6775d5341a9cca86bf1572a5e3534909153/widget/TextEvents.h#602-644

Those arrays are initialized with NativeKeyBindings:
https://searchfox.org/mozilla-central/rev/a70da6775d5341a9cca86bf1572a5e3534909153/widget/WidgetEventImpl.cpp#752-763

So, if you create a way to customize the key bindings with some code which are unnecessary to compile, resolving it in NativeKeyBindings make you can use existing path to make editor handle shortcut keys.

Note that some platform dependent shortcut keys are dynamically resolved by native key bindings. E.g., some basic edit commands on Linux and most edit commands including Emacs like key bindings on macOS.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

So masayuki and I talked extensively on his previous idea (comment 8). But we finally have landed to an alternative idea I have:

platformHTMLBindings.xml comes with four bindings, browser, editor, inputFields, and textAreas.

inputFields and textAreas bindings are bound to html:input and html:textarea by forms.css.

browser and editor bindings are bound to the document, not by any -moz-binding in a CSS file, but has their key handlers extracted and attached directly by nsXBLWindowKeyHandler.cpp.

This is the part that is interesting. The way nsXBLWindowKeyHandler does its thing today (mostly after bug 1203059) can be decoupled with the rest of the XBL infrastructure (except for nsXBLPrototypeHandler) if we could construct nsXBLPrototypeHandler from definitions in C++ arrays instead of <handler> in XBL.

Once we do that, we will be able to remove the browser and editor bindings defined in XBL.

As of the inputFields and textAreas bindings, masayuki suggests that I should handle it there also. Simply check the event target and switch to the different handler chain should do. I do however need to pay attention to event group and phase to make sure the priority of the event is correct (compare to native commands and key shortcuts from WebExtension).

He also expressed his preferences to keep the key definitions in ./widget/. That's something to be done once I proved the idea works.

This does imply that we will be keeping nsXBLWindowKeyHandler when we remove the XBL feature from codebase. I would imagine at that point we will probably be dropping "XBL" from the class, move it elsewhere. nsXBLPrototypeHandler can be greatly simplified and drop the "XBL" from its name too once nsXBLWindowKeyHandler is the only consumer.

Masayuki has also asked that we should write tests for native key binding testing, since we are able to synthesis them on Linux/Mac.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

> since we are able to synthesis them on Linux/Mac.

No, Windows and Mac.

If it's possible, we should test both in mochitest-chrome and mochitest(-plain-e10s).

Comment 17

[Dave Townsend [:mossop]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #16)
> > since we are able to synthesis them on Linux/Mac.
> 
> No, Windows and Mac.
> 
> If it's possible, we should test both in mochitest-chrome and
> mochitest(-plain-e10s).

Is there some documentation on the characters I should be using for synthesizing native keys? After skimming the tree I'm using \uF702 and \uF703 for left and right arrows on OSX but I don't know where those come from. I'm seeing weird effects where sometimes synthesizing a shift-left key will delete characters from an input box.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

You need to check what values are used in native when a key is pressed. You can get the information with following steps:

1. Run firefox (either opt or debug) with setting env to |MOZ_LOG=TextInputHandlerWidgets:3,sync| (and |MOZ_LOG_FILE=<path to log file>| if you want to get the log as a file).
2. Press a key combination which you want to synthesize.
3. Look for lines containing "TextInputHandler::HandleKeyDownEvent, aNativeEvent="
https://searchfox.org/mozilla-central/rev/1193ef6a61cb6e350460eb2e8468184d3cb0321d/widget/cocoa/TextInputHandler.mm#1714-1722

However, in most case, this method includes proper values:
https://searchfox.org/mozilla-central/rev/1193ef6a61cb6e350460eb2e8468184d3cb0321d/widget/tests/test_keycodes.xul#536

Comment 19

[Dave Townsend [:mossop]]

Attachment: Bug 1419091: Add tests for XBL keybindings.

Comment 20

[Dave Townsend [:mossop]]

Comment on attachment 8990296 [details]
Bug 1419091: Add tests for XBL keybindings.

Ok I've done that and seem to be sending the right things. Can you look at this test and see if you can see any problems? It seems to end up deleting the first "e" character in the text box most of the time.

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

I do not understand the reason why you add this test as mochitest-browser-chrome since bc is used for behavior interacting with browser UI and content. Additionally, nsIDOMWindow.sendNativeKeyEvent() is e10s-aware.  Even if you write the test as mochitest-e10s-plain, it sends request to emulate native key events to main-process's widget.  Then, dispatched event will come to focused remote process as usual. So, I think that you should write the test as mochitest-plain and you do not need to modify the test framework.

And also, you send characters and unmodified characters for arrow keys even on Windows but you souldn't do that. How about to create a wrapper method which computes native key code, characters and unmodified characters from KeyboardEvent.code value (i.e., physical key identifier), modifier state and platform before calling EventUtils.synthesizeNativeKey()?

Comment 22

[Dave Townsend [:mossop]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #21)
> I do not understand the reason why you add this test as
> mochitest-browser-chrome since bc is used for behavior interacting with
> browser UI and content. Additionally, nsIDOMWindow.sendNativeKeyEvent() is
> e10s-aware.  Even if you write the test as mochitest-e10s-plain, it sends
> request to emulate native key events to main-process's widget.  Then,
> dispatched event will come to focused remote process as usual. So, I think
> that you should write the test as mochitest-plain and you do not need to
> modify the test framework.

I originally wrote it as a mochitest-plain test but was having the same problems so I decided to try it from the main process to see if that had any benefit.

> And also, you send characters and unmodified characters for arrow keys even
> on Windows but you souldn't do that. How about to create a wrapper method
> which computes native key code, characters and unmodified characters from
> KeyboardEvent.code value (i.e., physical key identifier), modifier state and
> platform before calling EventUtils.synthesizeNativeKey()?

I'm not testing on Windows right now.

Any thoughts on why the test is failing on OSX?

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Dave Townsend [:mossop] from comment #22)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #21)
> > I do not understand the reason why you add this test as
> > mochitest-browser-chrome since bc is used for behavior interacting with
> > browser UI and content. Additionally, nsIDOMWindow.sendNativeKeyEvent() is
> > e10s-aware.  Even if you write the test as mochitest-e10s-plain, it sends
> > request to emulate native key events to main-process's widget.  Then,
> > dispatched event will come to focused remote process as usual. So, I think
> > that you should write the test as mochitest-plain and you do not need to
> > modify the test framework.
> 
> I originally wrote it as a mochitest-plain test but was having the same
> problems so I decided to try it from the main process to see if that had any
> benefit.

Really wired. For example, test_assign_event_data.html works fine with EventUtils.synthesizeNativeKey() even though it's mochitest-plain.
https://searchfox.org/mozilla-central/rev/28daa2806c89684b3dfa4f0b551db1d099dda7c2/widget/tests/test_assign_event_data.html#166-168

> > And also, you send characters and unmodified characters for arrow keys even
> > on Windows but you souldn't do that. How about to create a wrapper method
> > which computes native key code, characters and unmodified characters from
> > KeyboardEvent.code value (i.e., physical key identifier), modifier state and
> > platform before calling EventUtils.synthesizeNativeKey()?
> 
> I'm not testing on Windows right now.
> 
> Any thoughts on why the test is failing on OSX?

Do you mean failed on macOS due to JS error without the framework change? If so, I have no idea. Actually, we already have mochitest-plain which depend on EventUtils.synthesizeNativeKey()...

Could you attach the test which you wrote as mochitest-plain (if you still have it)?

Comment 24

[Dave Townsend [:mossop]]

Attachment: Bug 1419091: Add keybinding tests. r=masayuki

Comment 25

[Dave Townsend [:mossop]]

Comment on attachment 8998917 [details]
Bug 1419091: Add keybinding tests. r=masayuki

Here is the mochitest-plain test that fails intermittently. Sometimes it just gets strange values for the selection start and end (like +0), sometimes it somehow deletes some of the characters from the text box.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Comment on attachment 8998917 [details]
Bug 1419091: Add keybinding tests. r=masayuki

Ah, the callback of synthesizeNativeKey() is not useful for complicated tests.

It observes "keyevent" notification:
https://searchfox.org/mozilla-central/rev/aff5d4ad5d7fb2919d267cbc23b1d87ae3cf0110/testing/mochitest/tests/SimpleTest/EventUtils.js#1148-1149,1167-1169

It'll be dispatched by TabParent when it *synthesizes* native key events:
https://searchfox.org/mozilla-central/rev/aff5d4ad5d7fb2919d267cbc23b1d87ae3cf0110/dom/ipc/TabParent.cpp#1461,1468

This means that if all keyboard events should be sent to remote process, the notification is sent after *sending* synthesized keyup event. However, keypress event may be back to the main process as reply event to be handled as default action. The reply event is fired from here.
https://searchfox.org/mozilla-central/rev/aff5d4ad5d7fb2919d267cbc23b1d87ae3cf0110/dom/ipc/TabParent.cpp#2165,2169-2170,2196-2197

So, some default actions may be handled after the remote process receives the notification.

How about to resolve the promise when you detect expected result?

Comment 27

[Dave Townsend [:mossop]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #26)
> Comment on attachment 8998917 [details]
> Bug 1419091: Add keybinding tests.
> 
> Ah, the callback of synthesizeNativeKey() is not useful for complicated
> tests.
> 
> It observes "keyevent" notification:
> https://searchfox.org/mozilla-central/rev/
> aff5d4ad5d7fb2919d267cbc23b1d87ae3cf0110/testing/mochitest/tests/SimpleTest/
> EventUtils.js#1148-1149,1167-1169
> 
> It'll be dispatched by TabParent when it *synthesizes* native key events:
> https://searchfox.org/mozilla-central/rev/
> aff5d4ad5d7fb2919d267cbc23b1d87ae3cf0110/dom/ipc/TabParent.cpp#1461,1468
> 
> This means that if all keyboard events should be sent to remote process, the
> notification is sent after *sending* synthesized keyup event. However,
> keypress event may be back to the main process as reply event to be handled
> as default action. The reply event is fired from here.
> https://searchfox.org/mozilla-central/rev/
> aff5d4ad5d7fb2919d267cbc23b1d87ae3cf0110/dom/ipc/TabParent.cpp#2165,2169-
> 2170,2196-2197
> 
> So, some default actions may be handled after the remote process receives
> the notification.
> 
> How about to resolve the promise when you detect expected result?

I've updated the patch to add a 1s timeout after synthesizing the key. I would assume that to be plenty of time for the event to be sent and yet it still randomly fails by deleting letters from the input box or getting the selection values wrong.

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

I have no idea. Could you attach the updated file?

Comment 29

[Dave Townsend [:mossop]]

I updated the patch in phabricator.

Comment 30

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Dave Townsend [:mossop] from comment #27)
> I've updated the patch to add a 1s timeout after synthesizing the key. I
> would assume that to be plenty of time for the event to be sent

Yeah, 1sec is enough to long for that if it's opt build. I'm not sure the performance of debug build on your environment, though.

> and yet it
> still randomly fails by deleting letters from the input box or getting the
> selection values wrong.

"deleting letters" really odd since you synthesizes only arrow key events. Cannot you to check which keyboard event causes removing some text with breaking in editor?

Or, you can log native keyboard event handler on macOS with:

MOZ_LOG=TextInputHandlerWidgets:3,sync

And looking for lines containing ":HandleKeyDownEvent", ":InsertText" and/or ":HandleCommand".

Comment 31

[Dave Townsend [:mossop]]

Here is the logging when the letter is deleted. Before this is logged the text in the box is "Test text", the first "e" is selected. The synthesized key is supposed to be shift+left. After this logging the text in the box is "Tst text".

 0:09.02 INFO shift+left
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::HandleKeyDownEvent, aNativeEvent=0x103539200, type=NSKeyDown, keyCode=123 (0x7B), modifierFlags=0x20002, characters="", charactersIgnoringModifiers=""
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::HandleKeyDownEvent, calling interpretKeyEvents
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=1, length=1 }
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 IMEInputHandler::HasMarkedText, mMarkedRange={ location=9223372036854775807, length=0 }
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::InsertText, aAttrString="", aReplacementRange=0x7ffeec9327b8 { location=9223372036854775807, length=0 }, IsIMEComposing()=FALSE, keyevent=0x103539200, keydownDispatched=FALSE, keydownHandled=FALSE, keypressDispatched=FALSE, causedOtherKeyEvents=FALSE, compositionDispatched=FALSE
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=1, length=1 }
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 IMEInputHandler::MaybeDispatchKeydownEvent, aIsProcessedByIME=FALSE currentKeyEvent={ mKeyEvent(0x103539200)={ type=NSKeyDown, keyCode=LeftArrow (0x7B) } }, aIsProcessedBy=FALSE, IsDeadKeyComposing()=FALSE
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932150 TISInputSourceWrapper::InitKeyEvent, aNativeKeyEvent=0x103539200, aKeyEvent.mMessage=eKeyDown, aProcessedByIME=FALSE, aInsertString=0x7ffeec932520, IsOpenedIMEMode()=FALSE
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932150 TISInputSourceWrapper::ComputeGeckoKeyCode, aNativeKeyCode=0x7B, aKbType=0x28, aCmdIsPressed=FALSE, IsOpenedIMEMode()=FALSE, IsASCIICapable()=TRUE
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932150 TISInputSourceWrapper::InitKeyEvent, shift=ON, ctrl=off, alt=off, meta=off
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::HandleKeyDownEvent, called interpretKeyEvents
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::HandleKeyDownEvent, wasComposing=FALSE, IsIMEComposing()=FALSE
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932c30 TISInputSourceWrapper::InitKeyEvent, aNativeKeyEvent=0x103539200, aKeyEvent.mMessage=eKeyPress, aProcessedByIME=FALSE, aInsertString=0x0, IsOpenedIMEMode()=FALSE
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932c30 TISInputSourceWrapper::ComputeGeckoKeyCode, aNativeKeyCode=0x7B, aKbType=0x28, aCmdIsPressed=FALSE, IsOpenedIMEMode()=FALSE, IsASCIICapable()=TRUE
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932c30 TISInputSourceWrapper::InitKeyEvent, shift=ON, ctrl=off, alt=off, meta=off
 0:09.02 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::HandleKeyDownEvent, trying to dispatch eKeyPress event since it's not yet dispatched
 0:09.03 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::HandleKeyDownEvent, eKeyPress event has been dispatched
 0:09.03 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::HandleKeyDownEvent, keydown handled=FALSE, keypress handled=FALSE, causedOtherKeyEvents=FALSE, compositionDispatched=FALSE
 0:09.03 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets
 0:09.03 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x11e4fef30 TextInputHandler::HandleKeyUpEvent, aNativeEvent=0x1035392a0, type=NSKeyUp, keyCode=123 (0x7B), modifierFlags=0x20002, characters="", charactersIgnoringModifiers="", IsIMEComposing()=FALSE
 0:09.03 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932ed0 TISInputSourceWrapper::InitKeyEvent, aNativeKeyEvent=0x1035392a0, aKeyEvent.mMessage=eKeyUp, aProcessedByIME=FALSE, aInsertString=0x0, IsOpenedIMEMode()=FALSE
 0:09.03 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932ed0 TISInputSourceWrapper::ComputeGeckoKeyCode, aNativeKeyCode=0x7B, aKbType=0x28, aCmdIsPressed=FALSE, IsOpenedIMEMode()=FALSE, IsASCIICapable()=TRUE
 0:09.03 GECKO(20428) [Parent 20428: Main Thread]: I/TextInputHandlerWidgets 0x7ffeec932ed0 TISInputSourceWrapper::InitKeyEvent, shift=ON, ctrl=off, alt=off, meta=off

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Hmm, InsertText() is called with empty string unexpectedly. It means that IME or something tried to remove selected string if it's native input events. Do you reproduce it on tryserver? or your environment? If only the latter, it may be possible that your active keyboard layout or IME do something special since we post synthesized events into the native event queue.
https://searchfox.org/mozilla-central/rev/71ef4447db179639be9eff4471f32a95423962d7/widget/cocoa/TextInputHandler.mm#4984-4995,4999-5003

If you reproduce it on tryserver too. Perhaps, macOS has changed the behavior... If so, we need to stop sending chars and/or unmodifiedchars.

Comment 33

[Brian Grinstead [:bgrins]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #32)
> If you reproduce it on tryserver too. Perhaps, macOS has changed the
> behavior... If so, we need to stop sending chars and/or unmodifiedchars.

I see failures on try with the patch applied: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b981ba6aa42367216ca1dd436c63f78121811d5f&selectedJob=195370086

Comment 34

[Brian Grinstead [:bgrins]]

(In reply to Brian Grinstead [:bgrins] from comment #33)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #32)
> > If you reproduce it on tryserver too. Perhaps, macOS has changed the
> > behavior... If so, we need to stop sending chars and/or unmodifiedchars.
> 
> I see failures on try with the patch applied:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=b981ba6aa42367216ca1dd436c63f78121811d5f&selectedJob=1
> 95370086

Does the fact we see it on tryserver mean we need to make a change to how we send chars?

Comment 35

[Dave Townsend [:mossop]]

Ok, this was my bad (and some dumb JS accepted syntax) that was causing the issue.

Comment 36

[Dave Townsend [:mossop]]

Attachment: Bug 1419091: Switch to a compiled C++ table for html key bindings for browser and editor. r=masayuki

Comment 37

[Dave Townsend [:mossop]]

Comment on attachment 8998917 [details]
Bug 1419091: Add keybinding tests. r=masayuki

Comments addressed

Comment 38

[Dave Townsend [:mossop]]

Comment on attachment 9010009 [details]
Bug 1419091: Switch to a compiled C++ table for html key bindings for browser and editor. r=masayuki

This is a first pass at implementing handlers for browser and editor in C++ rather than XBL. It is only implemented for OSX right now but I wanted to get feedback before making it work for the other platforms.

Some of the complexity (like the GetHandlers function) is there to support doing something similar for input and textarea in a later patch.

Comment 39

[Dave Townsend [:mossop]]

I've been doing a lot of digging and experimentation with respect to input and textareas. The thing that surprised me is that if I remove the handlers from platformHTMLBindings.xml on mac, nothing breaks. The reason for this is that it turns out that for web content there are two backup places where keybindings are defined that can be used instead of platformHTMLBindings.xml. Here are the details, please correct me if I'm mistaken:

Every top-level window in every process has an instance of nsXBLWindowKeyHandler listening for events on the window's root EventTarget. This is responsible for firing commands based on the handlers defined in platformHTMLBindings. The <editor> handlers are used if a HTML WYSIWYG editor is currently focused, the <browser> handlers are used otherwise.

For every <keyset> defined in XUL an additional nsXBLWindowKeyHandler is created listening for events on the document's EventTarget and is responsible for firing commands based on the handlers defined in the <keyset>. This is used in preference to the nsXBLWindowKeyHandler for the top-level window.

For every element with an XBL binding (<input> and <textarea> fall into this camp), and <handler> elements are instantiated as a nsXBLPrototypeHandler and ... somehow listen for keyboard events (I'm a little fuzzy on this so far).

---

Given all that here is what seems to happen when you have an <input> element focused in a webpage in Firefox (so in a remote process) and you press a keyboard shortcut:

We look for an nsXBLPrototypeHandler from the <handler> elements defined in the <input> section of platformHTMLBindings.xml and attempt to execute the defined command.

If nothing matches then the nsXBLWindowKeyHandler for the top-level window in the content process sees the keypress and attempts to match it to a handler from the <browser> section (because no WYSIWYG element is focused) of platformHTMLBindings.xml.

If nothing matches here then we move up to the main process where an nsXBLWindowKeyHandler for the browser window's <keyset> is checked for a match.

Finally the main processes top-level window's nsXBLWindowKeyHandler checks for matches in the <browser> section of platformHTMLBindings.xml since the <browser> element is what appears to have focus in the main process.

Since keyboard shortcuts like Cmd+C etc. are defined in <input> for platformHTMLBindings.xml and <browser> for platformHTMLBindings.xml and the main browser window's <keyset>. we have to remove the shortcut from all three places before it stops working.

This seems a little odd. I mean, it works but it's a bit surprising that there are so many ways to catch this. It also means the existing test isn't totally testing the right thing. I'd expect an <input> element in a main-process top-level window without a <keyset> to fail when platformHTMLBindings.xml is cleared, so I need to write a test for that.

---

I think that we should do two things to make this a little cleaner and move the handlers away from platformHTMLBindings.xml:

Make nsXBLWindowKeyHandler check whether a browser element has focus and in that case clear its list of handlers. This is only the case when an element in a child process of the browser is actually focused so we should just let the child process find and handle events in that case.

Make nsXBLWindowKeyHandler check whether an <input> or <textarea> is focused and in that case use handlers defined in a C++ lookup table similar to the patch I have up for feedback already.

Then we can remove the <input> and <editor> bindings from platformHTMLBindings.xml.

--

This still leaves the handlers in the <keyset> in the main browser window, I'm not really sure what to do with those or if we even need to do anything.

How does this sound?

Comment 40

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Comment on attachment 8998917 [details]
Bug 1419091: Add keybinding tests. r=masayuki

Masayuki Nakano [:masayuki] (JST, +0900) (offline: 9/21-9/30) has approved the revision.

Comment 41

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Comment on attachment 8998917 [details]
Bug 1419091: Add keybinding tests. r=masayuki

I gave r+ from Phabricator.

Comment 42

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Dave Townsend [:mossop] (he/him) from comment #39)
> Every top-level window in every process has an instance of
> nsXBLWindowKeyHandler listening for events on the window's root EventTarget.

I'm not sure about content process. But at least on the main process, it's correct. However, if I designed e10s, I would make it as so in content process for improving the response time for every key stroke, for example, scrolling with keys.

> This is responsible for firing commands based on the handlers defined in
> platformHTMLBindings. The <editor> handlers are used if a HTML WYSIWYG
> editor is currently focused, the <browser> handlers are used otherwise.

Yeah, I understand so.

> For every <keyset> defined in XUL an additional nsXBLWindowKeyHandler is
> created listening for events on the document's EventTarget and is
> responsible for firing commands based on the handlers defined in the
> <keyset>.

I don't know about this. Do you mean nsXBLWindowKeyHandler is created for document node too?

> This is used in preference to the nsXBLWindowKeyHandler for the
> top-level window.

If so, must be correct.

> For every element with an XBL binding (<input> and <textarea> fall into this
> camp), and <handler> elements are instantiated as a nsXBLPrototypeHandler
> and ... somehow listen for keyboard events (I'm a little fuzzy on this so
> far).

Yeah, I understand so, and they are managed by nsXBLWindowKeyHandler, although I'm not sure who owns it... ah, nsXBLEventHandler?

> 
> ---
> 
> Given all that here is what seems to happen when you have an <input> element
> focused in a webpage in Firefox (so in a remote process) and you press a
> keyboard shortcut:
> 
> We look for an nsXBLPrototypeHandler from the <handler> elements defined in
> the <input> section of platformHTMLBindings.xml and attempt to execute the
> defined command.

Must be correct.

As you know, Gecko is platform of applications driven by DOM events. When user presses a key, we generate "keydown" and "keypress" events.  We'll stop (already stopped on Nightly) firing keypress event only on web apps if pressing key is non-printable, though, we keep dispatching keypress event for our internal use.

First, the main process's keydown event handler of nsXBLWindowKeyHandler at capturing phase in the system event group catches all keydown events.  Then, if it matches with a key combination which is registered to the nsXBLWindowKeyHandler, it makes stop its propagation in the main process.  Then, mark it as "main process requires the result of content" if it'll be sent to a remote process:
https://searchfox.org/mozilla-central/rev/94e37e71ffbfd39e6ad73ebcda5d77cce8d341ae/dom/xbl/nsXBLWindowKeyHandler.cpp#518,545-546
Then, content process will send reply whether the event's preventDefault() is called or not:
https://searchfox.org/mozilla-central/rev/94e37e71ffbfd39e6ad73ebcda5d77cce8d341ae/dom/ipc/TabChild.cpp#2125,2145
Then, main process's TabParent dispatches a keydown event for handling default action of it:
https://searchfox.org/mozilla-central/rev/94e37e71ffbfd39e6ad73ebcda5d77cce8d341ae/dom/ipc/TabParent.cpp#2188,2192-2193,2219-2220
Then, nsXBLWindowKeyHandler may handle shortcut key if it's not defaultPrevented:
https://searchfox.org/mozilla-central/rev/94e37e71ffbfd39e6ad73ebcda5d77cce8d341ae/dom/xbl/nsXBLWindowKeyHandler.cpp#497
In most cases, we register shortcut keys to listen keypress events.  So, same things are done for keypress event.

So, this allows content cancels our default action with calling KeyboardEvent.preventDefault().

Therefore, platformHTMLBindings.xml handles shortcut keys before nsXBLWindowKeyHandler in the content process and the main process.

However, be careful about this point. Only on macOS, our widget marks non-printable keypress events as "main process requires the result of content":
https://searchfox.org/mozilla-central/rev/94e37e71ffbfd39e6ad73ebcda5d77cce8d341ae/widget/cocoa/TextInputHandler.mm#3303-3312
Therefore, your investigation result may be different on the other platforms.

> Since keyboard shortcuts like Cmd+C etc. are defined in <input> for
> platformHTMLBindings.xml and <browser> for platformHTMLBindings.xml and the
> main browser window's <keyset>. we have to remove the shortcut from all
> three places before it stops working.
> 
> This seems a little odd. I mean, it works but it's a bit surprising that
> there are so many ways to catch this. It also means the existing test isn't
> totally testing the right thing. I'd expect an <input> element in a
> main-process top-level window without a <keyset> to fail when
> platformHTMLBindings.xml is cleared, so I need to write a test for that.

Yeah, so, inner-most (deepest) event handler from event target has the highest priority (because default action handlers are typically handling in bubbling phase). This is true even between multiple default action handlers in our UI. E.g., same key combination may work as differently when <input> has focus and when nobody has focus.

> 
> ---
> 
> I think that we should do two things to make this a little cleaner and move
> the handlers away from platformHTMLBindings.xml:
> 
> Make nsXBLWindowKeyHandler check whether a browser element has focus and in
> that case clear its list of handlers. This is only the case when an element
> in a child process of the browser is actually focused so we should just let
> the child process find and handle events in that case.

I think that just ignoring some handlers is easier. You can use WidgetEvent::WillBeSentToRemoteProcess() to check whether each keyboard event is sent do remote process. Note that some key combinations won't be sent to content process due to security reason. E.g., Accel+N, Accel+Q, etc (this is controllable by users per site, see "Override Keyboard Shortcuts" in "Permission" tab in "Page Info" dialog.

> Make nsXBLWindowKeyHandler check whether an <input> or <textarea> is focused
> and in that case use handlers defined in a C++ lookup table similar to the
> patch I have up for feedback already.
> 
> Then we can remove the <input> and <editor> bindings from
> platformHTMLBindings.xml.

Hopefully, but not sure. If other default action handlers may handle some shortcut key after <input> or <textarea> in bubbling phase, this model is broken. If we'd meet such case, we need to revisit my original suggestion (comment 14).

I'll check your patch soon.

Comment 43

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Comment on attachment 9010009 [details]
Bug 1419091: Switch to a compiled C++ table for html key bindings for browser and editor. r=masayuki

I don't check so deeply, though, looks fine to me at least for "editor" and "browser". However, as I mentioned above, I'm not sure if this works fine with <input> and <textarea> if conflicting with other default handles. (I didn't realize this issue when I discussed with Tim at the previous All Hands... Although, editor event listener can call stopImmediatePropagation() for preventing other event handlers handle different default action.)

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d432e26bd0b5
Add keybinding tests. r=masayuki

Comment 45

[Cristian Brindusan [:cbrindusan]]

Backed out changeset d432e26bd0b5 (Bug 1419091) for mochitest failures on dom/tests/mochitest/keyhandling/test_input.html.

Backout: https://hg.mozilla.org/integration/autoland/rev/2efb7ae0315fa250f001d82a994e3eae60f36857

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending,running,success,testfailed,busted,exception&revision=d432e26bd0b5ac9e3c3877592616fb7110b52142&selectedJob=200914418

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=200914418&repo=autoland&lineNumber=11861

Comment 46

[Dave Townsend [:mossop]]

Attachment: Bug 1419091: Define keybindings in a static C++ table. r=masayuki

Copies the keybindings from platformHTMLBindings.xml into an array of C structs
that can be easily used to instantiate an nsXBLPrototypeHandler (done in later
patches).

These were mechanically generated.

Comment 47

[Dave Townsend [:mossop]]

Attachment: Bug 1419091: Make TextInputListener handle non-native events for input and textarea too. r=masayuki

platformHTMLBindings attaches event handlers directly to the <input> and
<textarea> elements. This matches that by making TextInputListener look up and
call the <input> and <textarea> event handlers from the static C array.
There is a slight difference in that the event handlers are added to the system
bubbling phase as opposed to the regular bubbling phase but in tests this does
not seem to cause problems.

Comment 48

[Dave Townsend [:mossop]]

Attachment: Bug 1419091: Delete platformHTMLBindings.xml. r=masayuki

Removes the now unused platformHTMLBindings.xml.

Comment 49

[Dave Townsend [:mossop]]

This is now ready to land however I'm going to hold off until after the next merge.

Comment 50

[Tim Guan-tin Chien [:timdream] (please needinfo)]

If https://phabricator.services.mozilla.com/D8907 lands before this bug the checks would need to be updated here.

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/58d5a882493d
Add keybinding tests. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/72ccc9444916
Define keybindings in a static C++ table. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac56492b6ed6
Switch to a compiled C++ table for html key bindings for browser and editor. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/2224ee809328
Make TextInputListener handle non-native events for input and textarea too. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/15811bce212a
Delete platformHTMLBindings.xml. r=masayuki

Comment 52

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1bd4af34fe10
Backed out 5 changesets for reftest failure at tests/layout/reftests/bugs/1377447-1.html.

Comment 53

[Daniel Varga [:dvarga]]

Backed out 5 changesets (Bug 1419091) for reftest failure at tests/layout/reftests/bugs/1377447-1.html.

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=15811bce212a0bbe0603ff31f3f95934050afe95

Failure log: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=15811bce212a0bbe0603ff31f3f95934050afe95

[task 2018-10-22T22:15:10.593Z] 22:15:10     INFO -  REFTEST TEST-LOAD | http://10.0.2.2:8854/tests/layout/reftests/bugs/1377447-1.html | 238 / 271 (87%)
[task 2018-10-22T22:15:10.597Z] 22:15:10     INFO -  REFTEST TEST-LOAD | http://10.0.2.2:8854/tests/layout/reftests/bugs/1377447-1-ref.html | 238 / 271 (87%)
[task 2018-10-22T22:15:21.313Z] 22:15:21     INFO -  REFTEST TEST-UNEXPECTED-FAIL | http://10.0.2.2:8854/tests/layout/reftests/bugs/1377447-1.html == http://10.0.2.2:8854/tests/layout/reftests/bugs/1377447-1-ref.html | image comparison, max difference: 1, number of differing pixels: 1
[task 2018-10-22T22:15:21.318Z] 22:15:21     INFO -  REFTEST   IMAGE 1 (TEST): data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAPoCAYAAAAmy5qxAAAVOUlEQVR4nO3XK5IbQRBF0VmViYl33kif1lYkJgnXIOMm8q0J1zkRjydIcr8GAABA5Gv2AQAAwDoECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAACZwwC53+9j3/exbZvZx7fv+3g8HsWvAwDwAxwGyOl0Gu/3u7iFBT2fz3G5XGafAQBA5DBAtm0bY4zx6/eff30Li/r7YwAA/P8ECNMJEACAdQgQphMgAADrECBMJ0AAANYhQJhOgAAArEOAMJ0AAQBYhwBhOgECALAOAcJ0AgQAYB0ChOkECADAOgQI0wkQAIB1CBCmEyAAAOsQIEwnQAAA1iFAmE6AAACsQ4AwnQABAFiHAGE6AQIAsI7DADmfz+P1ehW3sKDn8zkul8vsMwAAiBwGyP1+H9frdWzbZvbx3W638Xg8il8HAOAHOAwQAACATxEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGS+AdW/5Qf7XuqeAAAAAElFTkSuQmCC
[task 2018-10-22T22:15:21.324Z] 22:15:21     INFO -  REFTEST   IMAGE 2 (REFERENCE): data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAPoCAYAAAAmy5qxAAAVOUlEQVR4nO3XIZIiQRRF0V7VmDGz8zIEUGwFHKCz1egyzM2OyXMinv/im/s1AAAAIl+zDwAAANYhQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADIHAbI/X4f+76PbdvMPr5938fj8Sh+HQCAH+AwQE6n03i/38UtLOj5fI7L5TL7DAAAIocBsm3bGGOMX7///OtbWNTfHwMA4P8nQJhOgAAArEOAMJ0AAQBYhwBhOgECALAOAcJ0AgQAYB0ChOkECADAOgQI0wkQAIB1CBCmEyAAAOsQIEwnQAAA1iFAmE6AAACsQ4AwnQABAFiHAGE6AQIAsA4BwnQCBABgHQKE6QQIAMA6BAjTCRAAgHUcBsj5fB6v16u4hQU9n89xuVxmnwEAQOQwQO73+7her2PbNrOP73a7jcfjUfw6AAA/wGGAAAAAfIoAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACDzDb0M5QTYpBKZAAAAAElFTkSuQmCC
[task 2018-10-22T22:15:21.325Z] 22:15:21     INFO -  REFTEST INFO | Saved log: START http://10.0.2.2:8854/tests/layout/reftests/bugs/1377447-1.html
[task 2018-10-22T22:15:21.326Z] 22:15:21     INFO -  REFTEST INFO | Saved log: [CONTENT] OnDocumentLoad triggering WaitForTestEnd
[task 2018-10-22T22:15:21.326Z] 22:15:21     INFO -  REFTEST INFO | Saved log: [CONTENT] WaitForTestEnd: Adding listeners
[task 2018-10-22T22:15:21.327Z] 22:15:21     INFO -  REFTEST INFO | Saved log: Initializing canvas snapshot
[task 2018-10-22T22:15:21.327Z] 22:15:21     INFO -  REFTEST INFO | Saved log: DoDrawWindow 0,0,800,1000

Comment 54

[Dave Townsend [:mossop]]

Ehsan, I'm a little out of my depth with this test failure. Basically it seems that no longer attaching a XBL binding to input boxes causes a single pixel difference in tests/layout/reftests/bugs/1377447-1.html (a pixel in the upper-left corner of the input box is a different colour) on android debug only. Even attaching an empty XBL binding makes the test pass (https://treeherder.mozilla.org/#/jobs?repo=try&revision=45d5ca0cf5264d88683d5e72752fcb246f0a99a0).

I'm assuming that this is something to do with paint timing but I'm not really sure how to solve it. Any suggestions?

Comment 55

[(no longer active)]

I don't think this is a rendering difference that we care about here, it's not really related to what the test is trying to test.  You can use the reftest fuzzy-if() annotation in order add some fuzz tolerance to this test on Android debug (I assume that's the place where you see this, perhaps elsewhere too).

There are many examples already <https://searchfox.org/mozilla-central/search?q=fuzzy-if&case=false&regexp=false&path=reftest.list> and docs: <https://searchfox.org/mozilla-central/rev/a7f4d3ba4fbfe3efbde832869f1d672fce7122f6/layout/tools/reftest/README.txt#146>

Comment 56

[Dave Townsend [:mossop]]

Attachment: Bug 1419091: Mark reftest that fails on Android debug when XBL bindings aren't attached as fuzzy. r=Ehsan

Comment 57

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d33100811e81
Add keybinding tests. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/0e7a8e653761
Define keybindings in a static C++ table. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac929295fea8
Switch to a compiled C++ table for html key bindings for browser and editor. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/69f747a1dc7d
Mark reftest that fails on Android debug when XBL bindings aren't attached as fuzzy. r=Ehsan
https://hg.mozilla.org/integration/mozilla-inbound/rev/40371ad81464
Make TextInputListener handle non-native events for input and textarea too. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/40036a4302c3
Delete platformHTMLBindings.xml. r=masayuki

Comment 58

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/d33100811e81
https://hg.mozilla.org/mozilla-central/rev/0e7a8e653761
https://hg.mozilla.org/mozilla-central/rev/ac929295fea8
https://hg.mozilla.org/mozilla-central/rev/69f747a1dc7d
https://hg.mozilla.org/mozilla-central/rev/40371ad81464
https://hg.mozilla.org/mozilla-central/rev/40036a4302c3

Comment 59

[Axel Grude]

Can somebody help me with an idea how to convert my (recommended) add-on Zombiekeys now that the main binding on platformHTMLBinding is gone? I need this to be compatible with Thunderbird 68 in August

This line is in one of my overlays is my problem:

<binding id="inputzombie"
extends="chrome://global/content/platformHTMLBindings.xml#inputFields">

Is there any way I can make a new binding without extending the existing ones? I am giving international keyboard support on all editable elements in the UI (message searchg, message filter, filter rules etc.) - my users and I need this so we can type diacritics / umlauts etc. in the chrome layer. It still works in the content layer (Composer).

Comment 60

[Axel Grude]

can you help me Dave Townsend / Masayuki Nakano? It looks like moving this code down to C++ makes it impossible to change from the JS layer? Any suggestions how I can save this without months of rewriting?

Comment 61

[Boris Zbarsky [:bzbarsky]]

Is there any way I can make a new binding without extending the existing ones?

XBL bindings are in the process of being removed entirely, so what you probably want to do is figure out a way to do whatever key binding bits you want to do without XBL, and filing bugs for extension APIs that are needed if there's no way to do it right now.

Comment 62

[Dave Townsend [:mossop]]

(In reply to Axel Grude from comment #59)

Can somebody help me with an idea how to convert my (recommended) add-on Zombiekeys now that the main binding on platformHTMLBinding is gone? I need this to be compatible with Thunderbird 68 in August

This line is in one of my overlays is my problem:

<binding id="inputzombie"
extends="chrome://global/content/platformHTMLBindings.xml#inputFields">

I'm not sure why this would have had any effect, the code changed here used to explicitly load its bindings from chrome://global/content/platformHTMLBindings.xml, extending it wouldn't have made any change.

Is there any way I can make a new binding without extending the existing ones? I am giving international keyboard support on all editable elements in the UI (message searchg, message filter, filter rules etc.) - my users and I need this so we can type diacritics / umlauts etc. in the chrome layer. It still works in the content layer (Composer).

You can create a new XBL binding and just not include the extends attribute. But as bz says XBL is going away entirely very soon so you probably need to find an alternative.

This is all probably better discussed outside of this bug though.