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]> 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]. > 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.
