56389 - need to set up event loop in xpcshell

Status: RESOLVED INVALID

(Core :: XPConnect, defect)

Description

[Mike Shaver (:shaver emeritus)]

I'm writing networking test cases and prototype code with xpcshell, which is
really quite pleasant.

Except that it bails as soon as netwerk tries to access the event queue.

Is the right thing here to make Process sit in a select loop, servicing the
event queue?

Comment 1

[John Bandhauer]

This was asked for once in bug 37895 to which I replied "show me how". Ruslan 
decided he no longer cared and marked that bug invalid. If this makes sense and 
doesn't break anything or add bad dependencies then it's all the same to me. 
Show me how.

Comment 2

[Mike Shaver (:shaver emeritus)]

Blizzard has shared his wisdom with me: it looks like we need to have xpcshell
sit in a mainloop, making the EQS monitor the script-input file descriptors --
added and removed from the select list in Process, I suspect -- and feeding data
to the JS engine as it arrives.  (I wouldn't be surprised if this was different,
and perhaps simpler, on non-Unix platforms.)

I think this will interact very poorly with readline, since it doesn't seem to
give a way to hand it data in a controlled fashion, but I can live without
readline to get the EQS running.

Comment 3

[Brendan Eich [:brendan]]

Adding mccabe, master of readline and JS_BufferIsCompileableUnit.

/be

Comment 4

[Mike McCabe]

Maybe, yes.  Readline (and editline) seem to be hardcoded to take uncooked (?)
input from stdin.  And wait while doing so... would it be possible to do
something thread-friendly, e.g. have readline in a different thread, collecting
keystrokes to be passed to the main thread whenever a full line is collected? 
Or, for that matter, a JS_BufferIsCompilableUnit buffer...

Out of my depth on this topic.  Sure, jettisoning readline for this case would
be just fine, if that's what it takes.  (Maybe a commandline flag?)

Comment 5

[Paul Wyskoczka]

This bug is blocking the testing of the embed apis.
Added Embed keyword and upgrade severity to blocker

Comment 6

[lchiang]

jband - are you the right person for this bug?  If not, pls let us know so we
can redirect this bug to another person.  Thanks!

Comment 7

[John Bandhauer]

lchiang: in the sense that I'm the author and owner of xpcshell, I'm the right
person. In the sense that I don't know what is expected I'm not.

I don't understand what code will service the event loop and when it will run.
Is it expected that one will be able to run a .js file and have xpcshell somehow
yield to an event loop while the .js file is executed? I don't know how to do
that automatically. I'm not sure that one whould want events to be processed on
the main thread except from within native calls that the running JS code
*expects* to have yield to an event loop and potentially process events.

Or, is it enough to yield between interactive scripts entered manually at the
prompt? (who uses the xpcshell as a test engine interactively?) As shaver
pointed out above, this is also problematic.

I think that what really has to happen here is that the JS code being run needs
to do its own yielding (implicitly in components it calls, or explicitly by
running a scriptable event loop). I'm not seeing how the xpcshell application
would need to be changed to support this. Unless maybe we want to have xpcshell
expose some JS callable method to do the yielding.

Nevertheless, people are claiming something is needed here (and even that it is
blocking them) but no one is saying exactly what is needed and how the running
scripts will use the new feature.

Comment 8

[Judson Valeski]

I'm not sure *exactly* how this is being used either. I get requests like "I
want to receive nsIWebProgressListener callbacks in my JS" all the time. Or "I
want to receive nsIStreamListener callbacks." QA would like to be able to "test"
these interfaces (and others) using xpcshell. Because I don't know how their
already using it I can't speak for them, but I suspect they have .js files that
they currently test return parameters from synchronous function/method calls,
and they'd like to modify those files to handle callbacks too. Assuming that's
the case, I think it's reasonable to have the .js have it's own while(1) loop
(main loop) that processes a scriptable event loop interface. Rather than have
the xpcshell app implicitly do this (which does indeed seem odd/hard). Does that
provide some direction?

Comment 9

[lchiang]

jband: I am just the messenger here :-)  Let me inquire with paw and gerardo and
get more facts for you.  Thanks.

Comment 10

[Phil Peterson]

This is not a blocker for embedding anymore. We're going to use JS in web pages
to test callbacks. Removing embed keyword and demoting severity to normal. Would
still be nice to do this so we can test using xpcshell, but we'll survive
without it.

Comment 11

[John Bandhauer]

mass reassign of xpconnect bugs to [e-mail]

Comment 12

[Patrick C. Beard]

I will post a workaround, it is fairly trivial to code an event loop in JS for 
special purposes.

Comment 13

[Kevin A. Burton]

What is the status here?  I would really like to see this bug fixed. I too want
to use nsIStreamListener and network IO from javascript/xpcshell.  Mostly so
that I can test/debug my code from within Emacs.  

Any chance on seeing that workaround?

I am going to look into building my own workaround.  I think I have an idea of
how to proceed.

Kevin

Comment 14

[Nickolay_Ponomarev]

With the solution in comment 7 implemented (see http://mxr.mozilla.org/seamonkey/source/tools/test-harness/xpcshell-simple/head.js), is there anything that needs to be done in this bug? Since there were no specific suggestions, marking the bug invalid.