Bugs item #1190367, was opened at 2005-04-26 08:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113188&aid=1190367&group_id=13188

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Delayed socket communication while http posts

Initial Comment:

 The `browser::getURL" procedure (browser.tcl) checks
for another
 post to the same URL. If there is one, the procedure
emits an error
 and exits. If this post is a new one, it calls the
`pnExecute"
 procedure as in:
 
   pnExecute GetURL $slave [list $url]
 
 
 The `pnExecute" procedure (remoted.tcl) then perform a
remote
 procedure call using the rpi interface:
 
   ::rpi::invoke $::plugin::CLIENT [concat [list
::pn$cmd $key] $aList]
 
 
 in this case:
 
   ::rpi::invoke ::rpi::I1cli ::pnGetURL tclet1
{javascript:alert("hola");}
 
 
 The rpi invocation function then performs:
 
   1) Some initialization.
 
   2) Send the data via the `SendMsg" procedure.
 
   3) Wait for a specific time, returning with error if
the time is
      exceeded. This use the ::wait::hold procedure.
 
 
 The `SendMsg" procedure writes the passed data into
the socket:
 
   
   puts $socket $what
 
 
 in our case, it writes:
 
   puts sock15 {E 4 {::pnGetURL tclet1
{javascript:alert("hola");}}}
 
 
 
 So the remote `pnGetURL" procedure is supposed to be
executed on the
 remote interpreter.
 
 The `pn$api" procedures are generated on
`plugmain.tcl" from a
 template stored on the `pnAPIbody" variable. The
procedures actually
 generated that way are `pnGetURL", `pnStatus",
`pnOpenStream",
 `pnWriteToStream", `pnCloseStream", `pnPostURL",
`pnUserAgent" and
 `pnApiVersion". That is: this procedures implement the
API to the NPN
 procedures. 
 
 The template on `pnAPIbody" simply calls the
appropiate `pniAPI"
 procedure, that is the first one on the call chain
that is coded on
 the C part of the plugin. 
 
 In our case, `pniGetURL" is called. `pniGetURL" is a
Tcl-C interface
 procedure, defined on the `PnInit" C function
(npCmds.c). It
 interfaces to the `PnGetURLCmd" function, that is also
defined on
 `npCmds.c". 
 
 The `PnGetURLCmd" function then calls the actual
navigator NPN
 function for getting an url, stored on the
`NPNFuncs.geturl"
 variable (well, it really calls the `NPN_GetURL", that
in turn call
 `CallNPN_GetURLProc" with `NPNFuncs.geturl"). 
 
 
 So... ¿where is the delay?. The delay happens on the
remote procedure
 call. The caller executes `::rpi::invoke", which
correctly writes the
 message and then enters on the wait. There is a
timeout and an error
 is signalled. Meanwhile, the browser has not received
the javascript.
 
 Then i close the navigator window, or i perform a post
with the
 browser: ¡surprise!, the remote interpreter gets the
rpi and executes
 it, generating a browser window with "hola!".
 
 I think the bug could be on the communication via the
socket. But i am
 somewhat confused about the specific role of the "remote"
 interpreter. Could you please explain why are two tcl
processes
 running on the plugin, and why one of them is
"remote"? I need the
 "big picture" :)
 
 Sorry about my ignorance, but this is the first time i
get involved on
 plugin isssues.
 
 
     
     >  The bug arises with the following software
configuration (any 
     >  combination of):
     >  
     >       Mozilla suite 1.7           Tcl/Tk 8.4.9  
  Latest CVS tclplugin
     >       Mozilla firefox 1.x         Tcl/Tk 8.4
     >       IE 6.x
     >     
     >       Both x86 and PowerPC architectures (for
that matter).     
     
     So I assume this is Linux and Windows?
 
 
 Yes. It happens on GNU/Linux with Mozilla, on MS
Windows with IE 6x,
 and on MS Windows with Mozilla.
 
 
 
 Thanks.
 
 --
 José E. Marchesi    <jemarch@[...]..> 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113188&aid=1190367&group_id=13188


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Tclplugin-core mailing list
Tclplugin-core@[...].net
https://lists.sourceforge.net/lists/listinfo/tclplugin-core