On Mon, Jul 11, 2011 at 09:53:26PM +0200, Landry Breuil wrote:
> On Mon, Jul 11, 2011 at 10:20:53AM -0500, Marco Peereboom wrote:
> > On Mon, Jul 11, 2011 at 05:02:58PM +0200, Landry Breuil wrote:
> > > On Mon, Jul 11, 2011 at 08:51:12AM -0500, Marco Peereboom wrote:
> > > > So the following patch seems to make webkit 1.4.2 mostly usable.
> > > > 
> > > > This doesn't fix all issues with epiphany or xxxterm.  I have been
> > > > making updates to xxxterm to work around some issues.  I started working
> > > > with the upstream guys but they are less than interested because "linux
> > > > works".  The core of the issue is that they reset ulimit values despite
> > > > being set properly by the browser.
> > > 
> > > Why not fixing that code instead ? Do you have references to the 
> > > discussion
> > > with upstream ?
> > 
> > http://comments.gmane.org/gmane.os.opendarwin.webkit.gtk/575
> > 
> > That is the public debate.
> 
> Yeah, so why not trying the approach given in
> http://permalink.gmane.org/gmane.os.opendarwin.webkit.gtk/603 ?

I am going to once I find this magical line of code.  This does not fix
webkit magically though.  This is one of the many little things that are
broken and contribute to the shaky 1.4 behavior.

> 
> That looks to make sense, it shouldnt override the values given (which
> are NOT ulimits..) - make a proper bug report so that it's not lost ?
> 
> > > > Secondly web sockets keep half open
> > > > connections around longer because they never issue a close and it is
> > > > trivially simple to run out of file descriptors.
> > > 
> > > What about adding that close() properly instead, through a proper bug
> > > report ?
> > 
> > I have been told this is a function of libsoup + web sockets that can't
> > be fixed.  When the remote site sends a close libsoup does (can?) not
> > receive an event so the connection lingers using up a file descriptor.
> > I am unaware of any awesomeness web sockets brings us btw.  My non
> > scientific observations seem to confirm that disabling websockets makes
> > the browser a little more snappy.
> > 
> > > 
> > > You're trying to slip disable-link-prefetch in, wasnt it supposed to be
> > > a pref exposed through the api ?
> > 
> > No.  It is disabled by default what I am trying to do is to keep it
> > that way.
> 
> Pointless..
> 
> > > And what is the other patch ? Is it reported somewhere upstream ?
> > 
> > Sent it to the mailing list.  Haven't heard back.  I am not sure this is
> > an OpenBSD only issue either.
> 
> Sending the patch to a mailing list is the best way to make sure it gets
> lost, when everything happens in bugzilla...

Nothing happens in bugzilla on the gtk version.  What I have observed is
that gtk is considered the bastard version and issues get simply closed
as irrelevant because safari or chromium don't care.

I am yet again puzzled by your reluctance to fix things.  Webkit 1.4 is
broken and upstream moves at the speed of molasses so lets keep it
broken?

> Landry
> 

Reply via email to