On Wednesday 31 December 2008 16:34, Tommy[D] wrote:
> Matthew Toseland schrieb:
> > We have a lot of complaints on the uninstall survey about the firefox 
breakage 
> > bug. IMHO we should deal with this as soon as possible. The easiest way to 
> > deal with it is to periodically and/or after firefox exits, check the 
> > profiles.ini file to see whether the freenet profile has become the 
default, 
> > and if so, switch to the old default. This is incredibly ugly and nextgens 
> > thinks it may risk corruption in itself (IMHO this is unlikely, the format 
is 
> > very simple). And we might have to poll regularly, which is horrible.
> > 
> > The real browser-related issues are these:
> > 1. Security: Browser history is accessible via javascript. There is no way 
to 
> > keep sites out of the browser history.
> > 2. Performance: Freenet requests can take a long time. If the requests 
> > are "blocking", then the default browser connection limits are a big 
problem.
> > 
> > There are 3 basic options AFAICS:
> > 
> > 1. Keep the system as it is, and implement whatever hacks are needed to 
> > prevent the default firefox profile becoming the freenet one.
> > 
> > 2. Attempt to use a normal browser to access Freenet, and use javascript 
to 
> > circumvent the problems above. Delete the location bar, make a fake one of 
> > our own, don't actually change the URL so it doesn't go into the history, 
> > load stuff via XmlHttpRequest's to change the body. Implement a loading 
> > screen and poll every few seconds via XmlHttpRequest's (faster than 
> > refreshing) to update it. Do something similar with inlines. If javascript 
is 
> > turned off, fall back to current behaviour (with a basic loading screen) 
and 
> > warn the user (dismissably) that they must either turn javascript on or 
use a 
> > different browser on the web at large.
> > 
> > 3. Implement our own browser using XULRunner. XULRunner provides a basic 
> > browser template that we can customise, the problem is it is absurdly 
basic - 
> > there is no right click menu for example! However it does solve the 
history 
> > problem more cleanly, and allows us to update the progress pages in real 
> > time.
> > 
> > Any views? IMHO option 1 is acceptable for the time being, the main 
ugliness 
> > is that we need to poll regularly from when the Browse Freenet script is 
run 
> > until after the browser exits; since the browser is run with -no-remote, 
it 
> > should run until the user quits it, and then return ...
> > 
> > There is significant support for option 3 on freenet.uservoice.com, 
however 
> > IMHO some of that results from the current poorness of the web interface.
> 
> I would vote for option 2 or 3.
> 
> Less changes to the user system and less chances of breakage.
> 
> While 2 seems to be clear, what would you like to do at 3? Require xulrunner 
to be installed? Bundle
> a browser based on it?

Bundle XULRunner. Would obviously be platform specific; on some systems (i.e. 
probably everything except windows), we'd have to ask the user to install it 
first.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20081231/1aae8fd8/attachment.pgp>

Reply via email to