- Dillo-dev - lists.mailman3.com

Style sheet question (centering and list-style-type)

by furaisanjin＠gmail.com

Hi all. I'm wondering how this web page will be rendered. <HTML> <HEAD> <style></style> <TITLE>test</TITLE> </HEAD> <BODY> <div id="menu"> <ul> <li><a href="http://xxx.xxx.xxx/1">first second</a> </ul> </div> </BODY> </HTML> Recent dillo splits "first" and "second" words above and the first one is aligned on the left. Regards, furaisanjin

Nov. 4, 2009

Crashes at bizmakoto.jp

by furaisanjin＠gmail.com

2009/11/4 Jorge Arellano Cid <jcid(a)dillo.org>: > ?Please try Hg tip and report. OK, now the problem is solved. > ?BTW, are you using some BSD? Yes, I'm using FreeBSD as I reported in compilation problem. Regards, furaisanjin

Nov. 4, 2009

Crashes at bizmakoto.jp

by jcid＠dillo.org

On Tue, Nov 03, 2009 at 03:10:31PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Nov 03, 2009 at 09:19:50AM +0900, furaisanjin wrote: > > > Hi. > > > > > > I don't try all pages but at least there are several pages where dillo > > > keeps crashing. One example is > > > http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace > > > shows something like this. > > > > It doesn't crash here... :P > > > > The were a couple of patches for cleanup_at_close, please > > try from the repository without them (upto 1404:d4a8309dc63c), > > and let us know how it goes. > > I don't see where the tag variable is set to anything at all in tip. > I don't get a crash, but I get gibberish in the page bugs. Right, I made hurried modifications to a good patch and that bug slipped in. -- Cheers Jorge.-

Nov. 4, 2009

Crashes at bizmakoto.jp

by jcid＠dillo.org

On Wed, Nov 04, 2009 at 09:04:40PM +0900, furaisanjin wrote: > 2009/11/4 corvid <corvid(a)lavabit.com>: > > I don't see where the tag variable is set to anything at all in tip. > > Agree. > > > I don't get a crash, but I get gibberish in the page bugs. > > That's interesting aspect in Linux, isn't it? How can you access to > memory pointed by none-initialized variable in Linux? Please try Hg tip and report. BTW, are you using some BSD? -- Cheers Jorge.-

Nov. 4, 2009

Crashes at bizmakoto.jp

by furaisanjin＠gmail.com

2009/11/4 corvid <corvid(a)lavabit.com>: > I don't see where the tag variable is set to anything at all in tip. Agree. > I don't get a crash, but I get gibberish in the page bugs. That's interesting aspect in Linux, isn't it? How can you access to memory pointed by none-initialized variable in Linux? Regards, furaisanjin

Nov. 4, 2009

PATCH: don't force selection of first element in multi-select input.

by dtikhonov＠yahoo.com

> It looks like that would change the behaviour for size > 1 even if > multiple is not set. I see what you mean, there's a bug in my patch. I did not see that rows == 1 && multi == false in Html_tag_open_select(). I will try to come up with a new one... I need to save the 'multi' somewhere and then be able to check it in Html_tag_close_select(). C++ is not my forte. - Dmitri.

Nov. 4, 2009

PATCH: don't force selection of first element in multi-select input.

by corvid＠lavabit.com

Dmitri wrote: > Hi all, Hi Dmitri > Great job on dillo! :) > Below is a patch that prevents the browser from selecting the first element of a multi-select input. It looks like that would change the behaviour for size > 1 even if multiple is not set. *digs into the spec a little* Technically, section 17.6.1 just says that "If no OPTION element has the selected attribute set, user agent behavior for choosing which option is initially selected is undefined", as opposed to coming out and saying that we don't have to preselect _any_ for the multiple case if we don't want to. Checking good old firefox, let's see... If size is 1 and multiple is not set, one has to be selected in the option menu, of course. If size > 1, it does not force a selection, regardless of whether multiple is set. For some reason, that seems more reasonable to me in the multiple case than in the non-multiple case. But if we want to simply copy firefox here and we know that it doesn't break websites, I'd be all right with that.

Nov. 3, 2009

PATCH: don't force selection of first element in multi-select input.

by dtikhonov＠yahoo.com

Hi all, Great job on dillo! Below is a patch that prevents the browser from selecting the first element of a multi-select input. Thanks, - Dmitri. --- a/src/form.cc Mon Nov 02 13:41:37 2009 -0300 +++ b/src/form.cc Tue Nov 03 12:57:02 2009 -0500 @@ -767,8 +767,8 @@ void Html_tag_close_select(DilloHtml *ht DilloHtmlInput *input = Html_get_current_input(html); DilloHtmlSelect *select = input->select; - // BUG(?): should not do this for MULTI selections - select->ensureSelection (); + if (DILLO_HTML_INPUT_SEL_LIST != input->type) + select->ensureSelection (); SelectionResource *res = (SelectionResource*)input->embed->getResource(); select->addOptionsTo (res);

Nov. 3, 2009

Big changes in DPI framework and API

by corvid＠lavabit.com

dillo-dev wrote: > Jorge wrote: > > On Mon, Nov 02, 2009 at 08:14:40PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Mon, Nov 02, 2009 at 07:26:49PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > > > > > > > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > > > > > > > [...] > > > > > > > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > > > > > > > had them before, and got error msgs instead of working dpis. > > > > > > > > Would it make more sense for me to dig in now to understand what > > > > > > > > is happening, or are the docs and patches coming very soon? > > > > > > > > > > > > > > I should write Docs soon (before Friday). There were no changes > > > > > > > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > > > > > > > check here... > > > > > > > > > > > > After changing the table colors in file.dpi, more or less it > > > > > > worked with: > > > > > > > > > > > > make > > > > > > dpidc stop > > > > > > mkdir -p ~/.dillo/dpi/file > > > > > > cp file.dpi ~/.dillo/dpi/file > > > > > > dillo . > > > > > > > > > > > > It may be that you already have dpis there, and those will not > > > > > > work with the new code. They need convertion to the new dsh API. > > > > > > If this is the case, you can wait a bit for the docs, or give a > > > > > > look to the respective "convert to dsh API" patch in the repo. > > > > > > > > > > When dillo tries to talk to dpid: > > > > > After connect(), lsof -i shows me ESTABLISHED for both sides > > > > > After write(), the dpid side is gone and dillo says CLOSE_WAIT > > > > > After shutdown(), both sides are gone. > > > > > Then Dpi_get_server_port: can't read server port from dpid. > > > > > and ** ERROR **: dpi.c: can't start dpi daemon > > > > > > > > There may be an old dpid binary around. Try this in two > > > > terminal windows: > > > > > > > > 1.- 2.- > > > > cd src/dpid cd src/dpid > > > > ./dpid ./dpidc stop > > > > > > > > > > > > If dpid stops, it's OK. Most probably an old dpid is started. > > > > > > > > > > > > Is anybody else seeing this problem? > > > > > > But that dpid had been listening on the port advertised in > > > dpid_comm_keys, which an old dpid wouldn't have been doing. > > > > OK. The error looks like a problem in the authentication phase, > > but I'm not sure. Does the above test work for you? Are you > > testing on GNU/Linux or other OS? Is there a chance of another > > app trying to talk to the same port (DPID_BASE_PORT)? > > The test starts and stops dpid. > GNU/Linux. > lsof -i doesn't show anything else doing anything. > > > Are you trying to run all from ~/.dillo, or a global install? > > All from ~/.dillo I removed the dpidrc and was looking at things, wasn't enlightened, wrote a new one, and now it's working. Evidently there was something wrong in the first one. Hurray! I did notice that dpid was making 8 dpi service entries from local, and then 8 more because it's regarding (perhaps rightly) my dpi_dir line as pointing to system dpis even though it's just pointing to the local ones. The 16 entries didn't seem to be harming anything, though.

Nov. 3, 2009

Big changes in DPI framework and API

by corvid＠lavabit.com

Jorge wrote: > On Mon, Nov 02, 2009 at 08:14:40PM +0000, corvid wrote: > > Jorge wrote: > > > On Mon, Nov 02, 2009 at 07:26:49PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > > > > > > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > > > > > > [...] > > > > > > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > > > > > > had them before, and got error msgs instead of working dpis. > > > > > > > Would it make more sense for me to dig in now to understand what > > > > > > > is happening, or are the docs and patches coming very soon? > > > > > > > > > > > > I should write Docs soon (before Friday). There were no changes > > > > > > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > > > > > > check here... > > > > > > > > > > After changing the table colors in file.dpi, more or less it > > > > > worked with: > > > > > > > > > > make > > > > > dpidc stop > > > > > mkdir -p ~/.dillo/dpi/file > > > > > cp file.dpi ~/.dillo/dpi/file > > > > > dillo . > > > > > > > > > > It may be that you already have dpis there, and those will not > > > > > work with the new code. They need convertion to the new dsh API. > > > > > If this is the case, you can wait a bit for the docs, or give a > > > > > look to the respective "convert to dsh API" patch in the repo. > > > > > > > > When dillo tries to talk to dpid: > > > > After connect(), lsof -i shows me ESTABLISHED for both sides > > > > After write(), the dpid side is gone and dillo says CLOSE_WAIT > > > > After shutdown(), both sides are gone. > > > > Then Dpi_get_server_port: can't read server port from dpid. > > > > and ** ERROR **: dpi.c: can't start dpi daemon > > > > > > There may be an old dpid binary around. Try this in two > > > terminal windows: > > > > > > 1.- 2.- > > > cd src/dpid cd src/dpid > > > ./dpid ./dpidc stop > > > > > > > > > If dpid stops, it's OK. Most probably an old dpid is started. > > > > > > > > > Is anybody else seeing this problem? > > > > But that dpid had been listening on the port advertised in > > dpid_comm_keys, which an old dpid wouldn't have been doing. > > OK. The error looks like a problem in the authentication phase, > but I'm not sure. Does the above test work for you? Are you > testing on GNU/Linux or other OS? Is there a chance of another > app trying to talk to the same port (DPID_BASE_PORT)? The test starts and stops dpid. GNU/Linux. lsof -i doesn't show anything else doing anything. > Are you trying to run all from ~/.dillo, or a global install? All from ~/.dillo

Nov. 3, 2009