On Sunday 24 February 2008 16:28, Ian Clarke wrote: > On Sat, Feb 23, 2008 at 1:57 PM, Matthew Toseland <toad at amphibian.dyndns.org> > wrote: > > > On Saturday 23 February 2008 00:07, Ian Clarke wrote: > > > Just upgraded to the current testing snapshot (sh update.sh testing), > > and I > > > am still finding that it takes a rediculous amount of time for FProxy to > > > show up the first time (my browser has now been hanging for well over a > > > minute). > > > > Define "hanging". > > > The browser is requesting the fproxy page, but *none* of the page has been > delayed yet.
According to the stack trace there are multiple fetches going on from Freenet. At the client layer, not generated code. Therefore, for some bizarre reason the browser is waiting for the images to be loaded before rendering the HTML which it must have already loaded. What browser are you using? :| > > > According to the below thread dump, fproxy is fetching > > something from Freenet. Presumably this is one of the activelinks, so when > > you say your browser is hanging, you mean it hasn't finished loading all > > the > > images on the front page? > > No, none of the front page has loaded. See above. > > > Given that the front page contains activelinks (which are sourced from > > freesites), it's not so unreasonable to expect it to take a while to > > completely finish loading the pictures (especially as this involves > > loading > > the whole container which can be quite big in many cases). Having said > > that, > > when I have tested this it has occasionally appeared to me that fproxy > > requests started before freenet has any connections can get stuck and not > > complete even when it does get some. I will investigate. > > As I mention above, its not just a few images on the page that aren't > loading, its the entire page. Fproxy is fetching images. Check the stack trace: we have freenet.clients.http threads waiting in FetchWaiter's. Therefore the browser has already got enough HTML to recognise that it needs to load the images. Therefore logically it ought to be able to render the page, unless there is something really strange happening. The browser might conceivably be (over-) optimised for broadband and therefore wait for the images to load before rendering the HTML to avoid rerendering? > Clearly this is a fatal usability problem, > any newbie that had just installed Freenet would be stopped in their tracks > at this point - and we would have lost a potential user. And it's at least 70% the browser's fault. But there may be a workaround. That is, unless you have an alternative explanation for the fproxy fetches? > > Ian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080226/8f4cf174/attachment.pgp>
