Then please open a bug for it (Marcel, please add your observations as
comments there). If you can narrow it down to some specifics of the
application that are triggers (size, specific API's used, ...), that
would be awesome.
T.
On 09/15/2011 03:03 PM, Robert Nimax wrote:
Hi all,
I´ve been analysing exactly this issue the wohle morning until I read
this mail accedentially. :)
We migrated from 1.4 to 1.5 last week and everything was fine so far.
This morning I tried to install a new version of one of our
applications (build with qooxdoo 1.5) in a "real" environment, and I
ran into the same problem. I was heavily puzzled, bacause we have been
testing a lot (and still doing), and I didn´t get the picture, why the
bootstrap crashes this time.
I think it´s a timing issue depending on the browsers behaviour and
accordingly the sequence of the jobs a browser is doing (load a scipt,
execute a script, prepare the DOM, ...), because in our case the
problem only occurs when running the application on a remote server.
On a local system, i.e. there is a local web server serving the
resources (js, etc.), the probability to reproduce this issue is
rather low. Maybe because the operation system doesn´t go full stack
(tcp/ip) on a local call or maybe because there is no network
latency...I do not know.
Loading the bootstrap script in the body-section (instead of in the
head-section) solved the problem like Marcel told us. BTW Thanks for
that.:)
We build the app using a custom build job, but this job just extends
the regular build job ("build") and makes some environment settings -
that´s all, nothing special.
The Webserver is Apache (Tomcat Servlet Container), but I don´t think,
this will help to reproduce it.
I think it´s a just a timing issue or an unfortunate cominbation
caused by the browser. Maybe qooxdoo can catch this problem by waiting
(via timeouts) until the browser is ready or the body is
present...something like that...?
I tested it with FF 6.02 and Chrome 13. Both browsers show the same
behaviour which I didn´t expect...but it´s like that.:)
HTH,
Rob.
>>> thron7 <[email protected]> 9/15/2011 1:05 >>>
Marcel,
On 09/14/2011 07:02 PM, Marcel Ruff wrote:
It was my stupidity, I never checked the HTML (as it worked fine for
some years now).
The javascript include was in the <head> section,
moving it to <body> all runs fine - so simple ...
this is by no means simple, as all our skeleton index.html's load the
code in the <head> section. If this is an issue under certain
circumstances, we need to learn about it, and potentially address it
in a bug. Please go back to my last mail, and actually provide answers
to the questions I posted there. This will allow us to assess the
possibility to come up with a reproducable error sample, which would
be very helpful for a bug.
Thanks,
T.
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
