Alon, you are right, I commented out preventDefault() in the following code
and was able to see the keypress event with the corresponding charCode in
the console log:
['keydown', 'keyup', 'keypress', 'blur',
'visibilitychange'].forEach(function(event) {
document.addEventListener(event, function(event) {
console.log('event type:' + event.type + ' charCode:' + event.charCode);
worker.postMessage({ target: 'document', event: cloneObject(event) });
//event.preventDefault();
});
});
But I am not sure if commenting out this code will cause other regressions
though.
On Sunday, August 30, 2015 at 1:52:00 PM UTC+8, Alon Zakai wrote:
>
> If it's keypress that isn't getting sent, I suspect we need to not
> preventDefault() on keydown or possibly keyup. I think SDL2 has some hacks
> in place for this exact issue. I also think I remember there were browser
> inconsistencies that necessitated the hacks.
>
> Code always runs to completion, including EM_ASM blocks, unless it does
> special magic to perform an async operation, or calls a method that does
> so. So that EM_ASM block will finish, then the mouse callback will finish,
> then the code calling emscripten_sleep_with_yield will resume operation.
>
> On Fri, Aug 28, 2015 at 5:20 PM, awt <[email protected] <javascript:>>
> wrote:
>
>> Sorry, I meant to say that "the *keypress* event isn't captured, only
>> the keyup and keydown events are captured".
>>
>> Suppose I use EM_ASM to execute native Javascript inside my
>> mouse_callback when my program is sleeping
>> during emscripten_sleep_with_yield. What happens when the sleep ends and
>> the program resumes from emscripten_sleep_with_yield? Will Emscripten allow
>> my native Javascript to run to completion before resuming
>> from emscripten_sleep_with_yield?
>>
>> Thanks for your help.
>>
>> On Saturday, August 29, 2015 at 1:56:19 AM UTC+8, Alon Zakai wrote:
>>>
>>> 1. It's fine that memcpy and strlen are not interpreted. They just need
>>> to be on the list of methods it is ok to call while async (which now both
>>> are). malloc might be a problem, since it can call sbrk which is an ffi. If
>>> that turns out to be a problem we'll need to figure something out.
>>>
>>> 2. "But for some reason, the keydown event isn't captured, only the
>>> keyup and keydown events are captured. " - did you mean another event than
>>> keydown in the first part of that sentence?
>>>
>>> Maybe we need to not call preventDefault on a previous event for the one
>>> that is missing - can you look at the stream of incoming events and try
>>> that?
>>>
>>> On Fri, Aug 28, 2015 at 4:14 AM, awt <[email protected]> wrote:
>>>
>>>> Thanks for the quick fix Alon :) I just have 2 more questions:
>>>>
>>>> 1) I noticed that functions like _memcpy, _malloc, _strlen are also not
>>>> emterpreted. Will you be fixing this as well?
>>>> 2) Another issue is that the code currently does not post the keypress
>>>> event over to the worker. After looking at the code,
>>>>
>>>> ['keydown', 'keyup', 'keypress', 'blur',
>>>> 'visibilitychange'].forEach(function(event) {
>>>> document.addEventListener(event, function(event) {
>>>> worker.postMessage({ target: 'document', event: cloneObject(event)
>>>> });
>>>> event.preventDefault();
>>>> });
>>>> });
>>>>
>>>> I realized that we are capturing keypress events for the document. But
>>>> for some reason, the keydown event isn't captured, only the keyup and
>>>> keydown events are captured. This is an issue for me because I need to
>>>> capture the exact char returned from the key and not just the keycode
>>>> itself. As of now, there's no way in which I can differentiate between
>>>> upper and lowercase characters.
>>>>
>>>> Is there a way in which we can post the charcode over to the worker? I
>>>> debugged this issue by simply printing out the event type in the code
>>>> above. Thanks for your help.
>>>>
>>>> On Friday, August 28, 2015 at 2:21:42 AM UTC+8, Alon Zakai wrote:
>>>>>
>>>>> That was a bug - we have a list of functions we avoid interpreting for
>>>>> performance reasons, but weren't aware of that in another part of the
>>>>> compiler. This would have been caught but we didn't have an iostream test
>>>>> during async. Fixed on incoming and added a test.
>>>>>
>>>>> On Thu, Aug 27, 2015 at 4:08 AM, awt <[email protected]> wrote:
>>>>>
>>>>>> Thanks for your reply Alon, I managed to get the mouse callback to
>>>>>> trigger by doing some debugging. This is my code as of now:
>>>>>>
>>>>>> helloworld.cpp:
>>>>>>
>>>>>> #include <stdio.h>
>>>>>> #include <iostream>
>>>>>> #include <emscripten.h>
>>>>>> #include <html5.h>
>>>>>> using namespace std;
>>>>>>
>>>>>> extern "C" {
>>>>>> EM_BOOL mouse_callback(int eventType, const EmscriptenMouseEvent *e,
>>>>>> void* userData)
>>>>>> {
>>>>>> cout << "mouse_callback+" << endl;
>>>>>> return 0;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> void handleMouseEvent()
>>>>>> {
>>>>>> emscripten_sleep_with_yield(100);
>>>>>> }
>>>>>>
>>>>>> int main() {
>>>>>> cout << "HelloWorld" << endl;
>>>>>>
>>>>>> //emscripten_set_mousemove_callback("#canvas",0,1,
>>>>>> mouse_callback);
>>>>>> emscripten_set_mousedown_callback("#canvas", 0, 1,
>>>>>> mouse_callback);
>>>>>>
>>>>>> emscripten_set_main_loop(handleMouseEvent, 0, 0);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> My build commands:
>>>>>> emcc helloworld.cpp --proxy-to-worker -s EMTERPRETIFY=1 -s
>>>>>> EMTERPRETIFY_ASYNC=1 -s NO_EXIT_RUNTIME=1 -s
>>>>>> EXPORTED_FUNCTIONS="['_mouse_callback', '_main']" -o helloworld.html
>>>>>>
>>>>>> Unfortunately, when I click on the canvas, I see the following abort
>>>>>> in the console:
>>>>>>
>>>>>> Uncaught abort(-12) at Error
>>>>>> at jsStackTrace (http://localhost:8000/helloworld.js:1166:13)
>>>>>> at stackTrace (http://localhost:8000/helloworld.js:1183:22)
>>>>>> at abort (http://localhost:8000/helloworld.js:24467:44)
>>>>>> at _strlen (http://localhost:8000/helloworld.js:20487:26)
>>>>>> at emterpret (http://localhost:8000/helloworld.js:11969:11)
>>>>>> at emterpret (http://localhost:8000/helloworld.js:11520:4)
>>>>>> at emterpret (http://localhost:8000/helloworld.js:11520:4)
>>>>>> at Array._mouse_callback (
>>>>>> http://localhost:8000/helloworld.js:16841:2)
>>>>>> at dynCall_iiii (http://localhost:8000/helloworld.js:20532:41)
>>>>>> at Object.Runtime.dynCall (
>>>>>> http://localhost:8000/helloworld.js:280:39)
>>>>>> This error happened during an emterpreter-async save or load of the
>>>>>> stack. Was there non-emterpreted code on the stack during save (which is
>>>>>> unallowed)? You may want to adjust EMTERPRETIFY_BLACKLIST,
>>>>>> EMTERPRETIFY_WHITELIST.
>>>>>> This is what the stack looked like when we tried to save it: 1,Error
>>>>>> at Object.EmterpreterAsync.handle (
>>>>>> http://localhost:8000/helloworld.js:8152:40)
>>>>>> at _emscripten_sleep_with_yield (
>>>>>> http://localhost:8000/helloworld.js:8177:24)
>>>>>> at emterpret (http://localhost:8000/helloworld.js:12550:6)
>>>>>> at Array.__Z16handleMouseEventv (
>>>>>> http://localhost:8000/helloworld.js:20629:2)
>>>>>> at dynCall_v (http://localhost:8000/helloworld.js:20670:31)
>>>>>> at Object.Runtime.dynCall (
>>>>>> http://localhost:8000/helloworld.js:284:39)
>>>>>> at http://localhost:8000/helloworld.js:6409:21
>>>>>> at Object.Browser.mainLoop.runIter (
>>>>>> http://localhost:8000/helloworld.js:6471:13)
>>>>>> at Browser_mainLoop_runner (
>>>>>> http://localhost:8000/helloworld.js:6405:26)
>>>>>> at http://localhost:8000/helloworld.js:23845:7
>>>>>> abort @ helloworld.js:24473_strlen @ helloworld.js:20487emterpret @
>>>>>> helloworld.js:11969emterpret @ helloworld.js:11520emterpret @
>>>>>> helloworld.js:11520_mouse_callback @ helloworld.js:16841dynCall_iiii @
>>>>>> helloworld.js:20532Runtime.dynCall @ helloworld.js:280handlerFunc @
>>>>>> helloworld.js:7301jsEventHandler @ helloworld.js:7204(anonymous
>>>>>> function) @
>>>>>> helloworld.js:23955fireEvent @ helloworld.js:23954onmessage @
>>>>>> helloworld.js:24230
>>>>>>
>>>>>> I took a look at the _strlen code and saw the following:
>>>>>>
>>>>>> function _strlen(ptr) {
>>>>>> ptr = ptr | 0;
>>>>>> var curr = 0;
>>>>>> curr = ptr;
>>>>>> asyncState ? abort(-12) | 0 : 0;
>>>>>> while (HEAP8[curr >> 0] | 0) {
>>>>>> curr = curr + 1 | 0;
>>>>>> }
>>>>>> return curr - ptr | 0;
>>>>>> }
>>>>>>
>>>>>> I find it strange that _strlen will abort when the program is in an
>>>>>> async state. From what I understand, all the functions would already
>>>>>> have
>>>>>> been emterpreted when I use -s EMTERPRETIFY=1 -s EMTERPRETIFY_ASYNC=1.
>>>>>> Is
>>>>>> my understanding correct or do I have to manually add _strlen to the
>>>>>> whitelist as well? I am using emsdk 1.34.1.
>>>>>>
>>>>>> On Thursday, August 27, 2015 at 11:11:27 AM UTC+8, Alon Zakai wrote:
>>>>>>>
>>>>>>> Not sure where the problem is (I didn't implement that API myself,
>>>>>>> not very familiar with the code) but you might take a look at
>>>>>>> tests/test_html5_mouse.c for example, which tests that API, and is
>>>>>>> known to
>>>>>>> work.
>>>>>>>
>>>>>>> On Wed, Aug 26, 2015 at 5:41 PM, awt <[email protected]> wrote:
>>>>>>>
>>>>>>>> Thanks for your reply Alon, are there other APIs that I can use to
>>>>>>>> capture mouse and keyboard events in Emscripten
>>>>>>>> besides emscripten_set_click_callback? Or do you think the issue lies
>>>>>>>> with
>>>>>>>> my mouse_callback itself?
>>>>>>>>
>>>>>>>> On Thursday, August 27, 2015 at 6:01:35 AM UTC+8, Alon Zakai wrote:
>>>>>>>>>
>>>>>>>>> The mouse_callback doesn't seem to work without --proxy-to-worker
>>>>>>>>> either, so proxying isn't the issue either. I'm not sure offhand what
>>>>>>>>> is
>>>>>>>>> wrong there, but it should be easier to debug without proxying.
>>>>>>>>>
>>>>>>>>> On Wed, Aug 26, 2015 at 2:59 PM, Alon Zakai <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Yes, the JS running in the HTML needs a Module object, so that we
>>>>>>>>>> can find the canvas element to render to, text area to show stdout
>>>>>>>>>> to, and
>>>>>>>>>> so forth. If you emit an html file instead of js, that will be
>>>>>>>>>> emitted for
>>>>>>>>>> you. Otherwise, you need to create it in the HTML.
>>>>>>>>>>
>>>>>>>>>> It's definitely an error that we fail in this way, though. I
>>>>>>>>>> fixed this on incoming, we'll show a warning now, and provide some
>>>>>>>>>> basic
>>>>>>>>>> Module functionality if one is not defined (writing to console.log
>>>>>>>>>> for
>>>>>>>>>> stdout, etc.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Aug 25, 2015 at 11:59 PM, awt <[email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I was trying to generate a javascript output for a simple hello
>>>>>>>>>>> world program and insert it into my own html file. These are my
>>>>>>>>>>> build
>>>>>>>>>>> commands:
>>>>>>>>>>>
>>>>>>>>>>> emcc helloworld.cpp --proxy-to-worker -o helloworld.js
>>>>>>>>>>>
>>>>>>>>>>> This is my helloworld.html file:
>>>>>>>>>>>
>>>>>>>>>>> <html>
>>>>>>>>>>> <header></header>
>>>>>>>>>>> <body>
>>>>>>>>>>> <script src="helloworld.js"></script>
>>>>>>>>>>> </body>
>>>>>>>>>>> </html>
>>>>>>>>>>>
>>>>>>>>>>> This is my cpp file:
>>>>>>>>>>>
>>>>>>>>>>> #include <stdio.h>
>>>>>>>>>>> #include <iostream>
>>>>>>>>>>>
>>>>>>>>>>> using namespace std;
>>>>>>>>>>> int main() {
>>>>>>>>>>> cout << "HelloWorld" << endl;
>>>>>>>>>>> return 0;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> I get the following error:
>>>>>>>>>>> Uncaught ReferenceError: Module is not defined
>>>>>>>>>>>
>>>>>>>>>>> at the following line of code in helloworld.js:
>>>>>>>>>>>
>>>>>>>>>>> ['mousedown', 'mouseup', 'mousemove', 'DOMMouseScroll',
>>>>>>>>>>> 'mousewheel', 'mouseout'].forEach(function(event) {
>>>>>>>>>>> Module.canvas.addEventListener(event, function(event) {
>>>>>>>>>>> worker.postMessage({ target: 'canvas', event:
>>>>>>>>>>> cloneObject(event) });
>>>>>>>>>>> event.preventDefault();
>>>>>>>>>>> }, true);
>>>>>>>>>>>
>>>>>>>>>>> Do I need to manually declare the Module object in
>>>>>>>>>>> helloworld.html? Or should I just include helloworld.worker.js in
>>>>>>>>>>> helloworld.html directly?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>> Google Groups "emscripten-discuss" group.
>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>> it, send an email to
>>>>>>>>>>> [email protected].
>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "emscripten-discuss" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to [email protected].
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "emscripten-discuss" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "emscripten-discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
