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

RESOLVED FIXED in Firefox 65

Status

()

task
P2
normal
RESOLVED FIXED
2 years ago
19 days ago

People

(Reporter: bgrins, Assigned: mossop)

Tracking

(Blocks 3 bugs)

unspecified
mozilla65
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox65 fixed)

Details

(Whiteboard: [xbl-in-content][overhead:48k])

Attachments

(6 attachments, 2 obsolete attachments)

Reporter

Description

2 years ago
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
Priority: -- → P2
Reporter

Updated

Last year
Whiteboard: [xbl-special-cases] → [xbl-in-content]
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?
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 hidden (mozreview-request)
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!
Flags: needinfo?(bzbarsky)
This seems like a question for Olli...
Flags: needinfo?(bzbarsky) → needinfo?(bugs)
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...
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 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.
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.
You could use a magic-value placeholder that means "WidgetInputEvent::AccelModifier" in the array...
Comment hidden (mozreview-request)
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.
(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.
(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.
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.
Flags: needinfo?(bugs)
> 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).
Assignee: nobody → dtownsend
(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.
Flags: needinfo?(masayuki)
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
Flags: needinfo?(masayuki)
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.
Attachment #8990296 - Flags: feedback?(masayuki)
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()?
(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?
Flags: needinfo?(masayuki)
(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)?
Flags: needinfo?(masayuki)
Assignee

Updated

11 months ago
Attachment #8990296 - Attachment is obsolete: true
Attachment #8990296 - Flags: feedback?(masayuki)
Assignee

Comment 25

11 months ago
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.
Attachment #8998917 - Flags: feedback?(masayuki)
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?
Attachment #8998917 - Flags: feedback?(masayuki)
Assignee

Comment 27

10 months ago
(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.
Flags: needinfo?(masayuki)
I have no idea. Could you attach the updated file?
Flags: needinfo?(masayuki)
Assignee

Comment 29

10 months ago
I updated the patch in phabricator.
(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".
Assignee

Comment 31

10 months ago
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
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.
Reporter

Comment 33

10 months ago
(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
Reporter

Comment 34

10 months ago
(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?
Flags: needinfo?(masayuki)
Assignee

Comment 35

10 months ago
Ok, this was my bad (and some dumb JS accepted syntax) that was causing the issue.
Flags: needinfo?(masayuki)

Updated

10 months ago
Attachment #8998917 - Attachment description: Bug 1419091: Add keybinding tests. → Bug 1419091: Add keybinding tests. r=masayuki
Comment on attachment 8998917 [details]
Bug 1419091: Add keybinding tests. r=masayuki

Comments addressed
Attachment #8998917 - Flags: review?(masayuki)
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.
Attachment #9010009 - Flags: feedback?(masayuki)
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?
Flags: needinfo?(masayuki)
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.
Attachment #8998917 - Flags: review+
Comment on attachment 8998917 [details]
Bug 1419091: Add keybinding tests. r=masayuki

I gave r+ from Phabricator.
Flags: needinfo?(masayuki)
Attachment #8998917 - Flags: review?(masayuki)
(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 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.)
Attachment #9010009 - Flags: feedback?(masayuki)
Assignee

Updated

9 months ago
Keywords: leave-open
Attachment #9010009 - Attachment description: Bug 1419091: Switch to a compiled C++ table for html key bindings for browser and editor. → Bug 1419091: Switch to a compiled C++ table for html key bindings for browser and editor. 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.
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.
Removes the now unused platformHTMLBindings.xml.
Assignee

Updated

8 months ago
Flags: needinfo?(dtownsend)
Attachment #8998917 - Flags: review+
This is now ready to land however I'm going to hold off until after the next merge.
If https://phabricator.services.mozilla.com/D8907 lands before this bug the checks would need to be updated here.

Comment 51

8 months ago
Pushed by dtownsend@mozilla.com:
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

8 months ago
Backout by dvarga@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1bd4af34fe10
Backed out 5 changesets for reftest failure at tests/layout/reftests/bugs/1377447-1.html.
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
Flags: needinfo?(dtownsend)
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?
Flags: needinfo?(dtownsend) → needinfo?(ehsan)

Comment 55

8 months ago
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>
Flags: needinfo?(ehsan)

Comment 57

8 months ago
Pushed by dtownsend@mozilla.com:
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

Updated

8 months ago
Depends on: 1501960
Assignee

Updated

8 months ago
Attachment #8954524 - Attachment is obsolete: true
Assignee

Updated

8 months ago
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED

Updated

8 months ago
Keywords: leave-open
Target Milestone: --- → mozilla65
Assignee

Updated

8 months ago
No longer depends on: 1501960
Whiteboard: [xbl-in-content] → [xbl-in-content][overhead:48k]
Component: DOM → DOM: Core & HTML

Updated

19 days ago
Type: enhancement → task
You need to log in before you can comment on or make changes to this bug.