RE: Safari / Konqueror JS

Mr. FoRK wrote:
> Adam, has anybody tested the JS client on Safari?

Yes, still not working.  The closest we got is...


| From [email protected]  Wed May 14 12:44:02 2003
| Subject: Re: KJS
| 
| On Wednesday 14 May 2003 12:34, Scott wrote:
| > Hi Alex,
| >
| > Wow, any help you can give would be great! Here's a link to the
| > uncompressed JS microserver in SourceForge WiewCVS (mind the wrap):
| >
| > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mod-pubsub/mod_pubsub/kn_apps/kn_lib/pubsub_raw.js?rev=3DHEAD&content-type=3Dtext/vnd.viewcvs-markup
| >
| > ....but, I'm thinking the problem is in the way KJS/KHTML handles frameset
| > access. Maybe there's a bug, or subtle security restrictions, or maybe
| > it's OS X-specific (I have no idea if it works in Konqueror for other
| > platforms).
| > 
| > In a nutshell, the persistent connection is handled by a hidden frame. In
| > Safari, it looks like that initial connection isn't being established at
| > all. It's almost like a document.location.replace() call isn't working
| > where we expect it to. Look for the _kn_launchTunnel() function, that's
| > what initializes the connection.
| 
| I'll send you a patch later today or tomorrow (mind if I clean up some
| stylistic stuff in there while I'm at it?)
| 
| > ....but, I'm thinking the problem is in the way KJS/KHTML handles
| > frameset access. Maybe there's a bug, or subtle security
| > restrictions, or maybe it's OS X-specific (I have no idea if it
| > works in Konqueror for other platforms).
| 
| I've seen this before.
| 
| There's an uber-annoying bug with Konq regarding frame elements that
| aren't visible. (sorry, don't have the cash to plunk down for a Mac
| so I'm still mac-less) In essence, if the frame isn't visible, its
| contents won't render and its location can't be reliably changed. In
| netWindows, I've worked around this by setting a timer that shows and
| hides the iframe we use every couple of seconds. The hiding was
| necessaray to remove a problem that seemed to require that the iframe
| be clicked on in order to function. So oscilating visibility seems to
| work w/ the Konq 3.0.x codebase.
| 
| As for more recent Konq versions (which it seems the Safari team is
| syncing with), they're even less deterministic regarding "hidden"
| loading of contents via frames. Instead of oscillation determining
| whether or not content will load, it seems timing playes a more
| critical role. Locations specified for loading into hidden iframe
| elements prior to onload of the element.
| 
| I'll see if I can put togeather a test case to exercise the bug, and
| I'll keep you posted. Most of my experience with this problem has
| been of the trial-and-error nature, so a more thorough investigation
| would probably benefit a lot of people.




-----Original Message-----
From: Mr. FoRK [mailto:[email protected]]
Sent: Thursday, June 12, 2003 7:59 AM
To: Adam Rifkin
Subject: Fw: Fork in real time

Adam,
Has anybody tested the JS client on Safari?

----- Original Message ----- 
From: "Adam L Beberg" <[email protected]>
To: "Mr. FoRK" <[email protected]>
Sent: Wednesday, June 11, 2003 11:34 PM
Subject: Re: Fork in real time

> On Wednesday, June 11, 2003, at 11:24  PM, Mr. FoRK wrote:
> 
> > or this:
> > http://www.mod-pubsub.org/kn_apps/chat2/?/fork
> 
> You killed Safari, you bastard!
> 
> Since I cant even remember that happening lately, there must be some 
> foobar shiznit in there.
> 
> - Adam L. Beberg - [email protected]
>    http://www.mithral.com/~beberg/
> 
> ----
> FoRK FoRK FoRK FoRK
> http://www.xent.com/pipermail/fork/


-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5