js.io usage experience and found bugs

[Sergii Boiko]

Hi, all.

I'm using js.io library with my custom CSP-server written in Erlang(it
will be opensourced as soon as it is ready for production).

I want to describe some issues and quirks when trying to use js.io
with it.

1) Compiling js.io with jsio_compile
* Currently via easy_install you can get only old version of
jsio_compile, which isn't working with tag v3.2
* Manual install of jsio_compile(version 0.2.3) can build tag v3.2,
but not the HEAD of master-branch. It will be cool to have ability to
install last version via easy_install.

So, I sticked with tag v3.2 of js.io

2) Loading throbber in Chrome
Chrome(haven't check this in Safary) has bug with not disappering
loading throbber. It disappers only after finishing first longpoll
request. As workaround, after several seconds server sends empty frame
and throbber is disappeared.

3) Opera(tested in 10.61) related issues
a) Loading throbber doesn't disappered even with empty-frame
workaround. In Orbited 0.7.10 I don't have such issue, nor with
sse(which is predictable) nor with longpolling transport.

b) Regular session reestablishment. I don't know why, but js.io in
Opera time-to-time(short period about 10-15 seconds) closes current
session and establishes a new one.

I wonder whether hookbox has the same (a) and (b) issues in Opera?
Maybe Michael knows what is a difference in implementation of
longpolling in Orbited and in jsio+CSP? I'm quite interest in this
bugfix and if you don't have time, provide me some hint and I'll try
to fix it.

4) Clash of underscore.js and js.io in Chrome
This peace of code makes Chrome to delete '_' var from global scope
and after that underscore.js library can't be used.
// file: packages/jsio.js, function execModule, line 464 in tag 'v3.2'
var code = "(function(_){with(_){delete _;(function(){" + module.src +
"\n}).call(this)}})";

The cause is in combination of with+delete. Change '_' to any other
name and it also delete this var from global scope. Bug in Chrome JS-
implementation, works normally in FF.

This fix works quite good:
var code = "(function(_any){with(_any){delete _any;(function(){" +
module.src + "\n}).call(this)}})";

Another possible issue - it's a clash of underscore library in util
module of js.io and user local version of the same lib. Can it be
addressed in some way, so for example i can use one version of
underscore.js and js.io another, or maybe jsio can use my version?

5) Session reestablishment
In my case it's not very good scenario, when closed old and opened new
session. Because in this time gap new message for user can arrive and
it will be lost(unless i'll provide some buffering per-user and not
only per-session as described in CSP).

In which case this can be issued from client side? It's a normal
behaviour, maybe some presetted timeout, or another reason? (current
Opera frequent session reestablishment i treat as a bag and i'll
investigate why it is now)

[Martin]

On Sep 8, 5:02 am, Sergii Boiko <cris.k...@gmail.com> wrote:
> Hi, all.
>
> I'm using js.io library with my custom CSP-server written in Erlang(it
> will be opensourced as soon as it is ready for production).
>
> I want to describe some issues and quirks when trying to use js.io
> with it.
>
> 1) Compiling js.io with jsio_compile
> * Currently via easy_install you can get only old version of
> jsio_compile, which isn't working with tag v3.2
> * Manual install of jsio_compile(version 0.2.3) can build tag v3.2,
> but not the HEAD of master-branch. It will be cool to have ability to
> install last version via easy_install.
>

We'll look into updating the easy_install version for jsio_compile.
There is no more planned development for jsio_compile, but we will
still accept community patches if anyone wants to continue adding
support to jsio_compile for future versions of jsio. Instead, the
next tagged release of jsio will feature a purely JavaScript-based
compiler. It will run on top of any jsio environment (even the
browser), but we are primarily targeting the node environment so that
we can integrate more easily with the closure compiler.

> So, I sticked with tag v3.2 of js.io
>
> 2) Loading throbber in Chrome
> Chrome(haven't check this in Safary) has bug with not disappering
> loading throbber. It disappers only after finishing first longpoll
> request. As workaround, after several seconds server sends empty frame
> and throbber is disappeared.
>

Not really sure what the problem is. If you have a test page that
exhibits the behavior, we could probably fix it fairly quickly. My
guess, though, is that csp requests initiated before the page onload
event that don't complete until after the page onload event cause the
loading indicator to display. There are probably two easy fixes:

1. register a page onload event handler and force a restart of the
long poll when this happens (might be tricky -- could require a
setTimeout on the restart or some other trickery depending on how
webkit tracks page resources).
2. don't initiate a csp connection until after the page onload event
fires.

> 3) Opera(tested in 10.61) related issues
> a) Loading throbber doesn't disappered even with empty-frame
> workaround. In Orbited 0.7.10 I don't have such issue, nor with
> sse(which is predictable) nor with longpolling transport.
>
> b) Regular session reestablishment. I don't know why, but js.io in
> Opera time-to-time(short period about 10-15 seconds) closes current
> session and establishes a new one.

We don't fully support Opera. However, last I heard, Orbited is in
the process of integrating js.io for its comet connections, so I
believe patches to Orbited's JS will eventually make it into js.io.
Just a guess.

>
> I wonder whether hookbox has the same (a) and (b) issues in Opera?
> Maybe Michael knows what is a difference in implementation of
> longpolling in Orbited and in jsio+CSP? I'm quite interest in this
> bugfix and if you don't have time, provide me some hint and I'll try
> to fix it.
>
> 4) Clash of underscore.js and js.io in Chrome
> This peace of code makes Chrome to delete '_' var from global scope
> and after that underscore.js library can't be used.
> // file: packages/jsio.js, function execModule, line 464 in tag 'v3.2'
> var code = "(function(_){with(_){delete _;(function(){" + module.src +
> "\n}).call(this)}})";
>
> The cause is in combination of with+delete. Change '_' to any other
> name and it also delete this var from global scope. Bug in Chrome JS-
> implementation, works normally in FF.
>
> This fix works quite good:
> var code = "(function(_any){with(_any){delete _any;(function(){" +
> module.src + "\n}).call(this)}})";
>
> Another possible issue - it's a clash of underscore library in util
> module of js.io and user local version of the same lib. Can it be
> addressed in some way, so for example i can use one version of
> underscore.js and js.io another, or maybe jsio can use my version?
>

Every module gets its own namespace. The abstraction isn't entirely
airtight -- as you've noticed, it occasionally causes errors,
particularly when code relies on global variables. The easiest way to
fix this would be to import the underscore library into your module's
namespace. The version of the underscore library included in js.io is
used in exactly this way - whenever we need the underscore library in
a particular module, we import it into that module. Since it's in the
default js.io packages, you can import the variable "_" from the file
jsio/lib/underscore.js into your module by calling:

jsio('from lib.underscore import _');

This actually allows you to do (potentially) useful things like use
different versions of the underscore library in different modules.
Say I have version 1.1 in a folder called myProject/dependencies/
underscore1.1.js. Then I can just say:

jsio('from ./myProject/dependencies/underscore1.1 import _');

and in that module I'll have access to underscore1.1. We could also
do:

jsio('from lib.underscore import _ as underscore_old');
jsio('from ./myProject/dependencies/underscore1.1 import _ as
underscore_1_1');

and now I will have access to both versions of the underscore library
with the variables 'underscore_old' and 'underscore_1_1'.

As a side benefit, since we're using jsio to import the module, the
jsio compiler will automatically pull in these sources during compile
time and add them to the compressed output.

> 5) Session reestablishment
> In my case it's not very good scenario, when closed old and opened new
> session. Because in this time gap new message for user can arrive and
> it will be lost(unless i'll provide some buffering per-user and not
> only per-session as described in CSP).
>
> In which case this can be issued from client side? It's a normal
> behaviour, maybe some presetted timeout, or another reason? (current
> Opera frequent session reestablishment i treat as a bag and i'll
> investigate why it is now)

Session reestablishment should be implemented in the server using
CSP. One common way of doing this is keeping a queue of messages to
send to the client and deleting them only when the client acknowledges
this. I think that's what you hint at when you say 'buffering per-
user'. You'll have the same problem regardless of what protocol you
use (e.g. when a mobile phone goes out of service range and is
receiving messages from a server, upon reconnect the program running
on the phone will have to rerequest any missed messages). CSP has
fairly good built-in session recovery -- if a server is unreachable
momentarily, the csp session can auto-recover and receive any missed
messages. If the session itself dies, then the server is responsible
for what data to send or resend when a new session is initiated.


Martin

[Sergii Boiko]

> 1. register a page onload event handler and force a restart of the
> long poll when this happens (might be tricky -- could require a
> setTimeout on the restart or some other trickery depending on how
> webkit tracks page resources).
> 2. don't initiate a csp connection until after the page onload event
> fires.

You were right. I've set some little timeout for onload callback and
loading throbber has disappeared in Chrome even without server-side
hack.

> We don't fully support Opera.  However, last I heard, Orbited is in
> the process of integrating js.io for its comet connections, so I
> believe patches to Orbited's JS will eventually make it into js.io.
> Just a guess.

I've investigated this issue deeply. Second bug was in my realization
of CSP. I've returned incorrect reply on comet close. Loading throbber
issue is concerned with jsonp transport. When using in some-domain
application everything is ok. Transport is xhr. js.io switch Opera to
jsonp in not the same-domain environment. As I understand from
googling, Opera can do Cross-Domain requests only via postMessage
transport in iframes(and I remember such peace of code in Orbited with
appropriate comment exactly for Opera).

I haven't found solution to fix Opera loading throbber in jsonp
transport. Maybe someone knows solution? In any case, currently I'll
try to use postMessage transport and see whether it can be added
smoothly into js.io for xhr transport to work.

[Sergii Boiko]

> I haven't found solution to fix Opera loading throbber in jsonp
> transport. Maybe someone knows solution? In any case, currently I'll
> try to use postMessage transport and see whether it can be added
> smoothly into js.io for xhr transport to work.

It's turn out, that js.io already has functionality to fix this issue
with jsonp in Opera. But this fix is enabled only for Firefox. I've
added Opera to the party and it's fixed issue. In some cases(like when
you do action which issue new loading action, for example image
loading) throbber can appear again till the next jsonp-frame. But it's
good enough for most cases.

[Jo]

Hello Sergii,
I'm currently working with an opera browser and I have the issue with
the loading throbber.
What did you exactly do to solve the problem?
I'm working with hookbox. After about 1 minute it kills the
connection.

It would be great if you would help me with this.

Best regards,
Jo


On 16 Sep., 13:03, Sergii Boiko <cris.k...@gmail.com> wrote:
> > I haven't found solution to fixOperaloading throbber in jsonp

> > transport. Maybe someone knows solution? In any case, currently I'll
> > try to use postMessage transport and see whether it can be added
> > smoothly into js.io for xhr transport to work.
>
> It's turn out, that js.io already has functionality to fix this issue

> with jsonp inOpera. But this fix is enabled only for Firefox. I've
> addedOperato the party and it's fixed issue. In some cases(like when

[Sergii Boiko]

Hi Jo

I've submitted patch to js.io github, which fixes somehow loading
throbber. But in reality it turns out, that Opera works really bad
with jsonp transport(which is used for Opera when you put your comet
server on different port/host with your web-server).

My observation is that Opera sends request, get headers(my server
sends headers in first packet) and close connection immediately. And
continue trying to get some packets from server. It must be some bug
in Opera or maybe it sends HEAD-request. I haven't checked last idea.

Correct way to handle this for opera is to implement combination of xhr
+postMessage API to bypass cross-domain restriction in Opera. Other
browsers use headers like 'Allow-Origin-*' for cross-domain ajax.
Opera allows this only via postMessage.

Currently js.io doesn't have means to work in this fashion. Maybe
after month I'll implement such transport for Opera, but in short time
I don't have time to do it.

[Jo]

Hi Sergii,
thank you for your fast reply.
I changed the file packages/net/csp/transports.js in line 420
to "var killLoadingBar = BrowserDetect.isFirefox ||
BrowserDetect.isOpera ? function() {", like you did it.
But it didn't work for me, because I have to use the Opera Version 9.7
on a Set-top Box.

It would be really great if you would make js.io to work with Opera.
Unfortunately, I can not help you very much, since I'm not so good in
programming javascript.
If I can test something or help you in a different way, then please
let me know.

Thank you,
Jo

On 29 Sep., 10:24, Sergii Boiko <cris.k...@gmail.com> wrote:
> Hi Jo
>
> I've submitted patch to js.io github, which fixes somehow loading

> throbber. But in reality it turns out, thatOperaworks really bad
> with jsonp transport(which is used forOperawhen you put your comet

> server on different port/host with your web-server).
>

> My observation is thatOperasends request, get headers(my server

> sends headers in first packet) and close connection immediately. And
> continue trying to get some packets from server. It must be some bug

> inOperaor maybe it sends HEAD-request. I haven't checked last idea.
>
> Correct way to handle this foroperais to implement combination of xhr
> +postMessage API to bypass cross-domain restriction inOpera. Other
> browsers use headers like 'Allow-Origin-*' for cross-domain ajax.Operaallows this only via postMessage.

>
> Currently js.io doesn't have means to work in this fashion. Maybe

> after month I'll implement such transport forOpera, but in short time

> I don't have time to do it.
>
> On Sep 28, 9:23 pm, Jo <johannes.bo...@googlemail.com> wrote:
>
>
>
> > Hello Sergii,

> > I'm currently working with anoperabrowser and I have the issue with

[Sergii Boiko]

Hi Jo,

Currently I can't fix this issue because of the lack of time. I can
back to this issue only after 3-4 weeks. And if it is not fixed till
that moment, I'll take care of this bug.