Alon,

Sorry for the late reply. I was caught up with some work so didn't manage 
to find the time to fix this. I have already submitted a pull request for 
this issue. Please let me know if you have any comments.

On Thursday, September 3, 2015 at 5:55:30 AM UTC+8, Alon Zakai wrote:
>
> I think you only need to do that on the keydown event. grep for 'keydown' 
> or 'preventDefault' in the emscripten SDL2 ports repo, they do the same 
> thing there - perhaps we should have a helper function in emscripten that 
> both places call?
>
> On Tue, Sep 1, 2015 at 10:04 PM, awt <[email protected] <javascript:>> 
> wrote:
>
>> 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]> 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] <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.

Reply via email to