May 2010 - Dillo-dev - lists.mailman3.com

Re: dillo question

by jcid＠dillo.org

On Wed, May 12, 2010 at 03:44:50PM -0400, Matthew Craig wrote: > Thanks for your response. Sorry that I am reluctant to join any mailing lists. > The Lemote laptop has alot of memory: 1GB and 2.7GB swap. I am > running GNOME without memory problems, and usage rarely rises over 50% > ... I am reluctant to presume Dillo is using all the memory up, but I > have been watching it today. > > Browsing to that website when Dillo is started fresh does indeed cause > an immediate crash. OK, that eliminates the memory shortage thesis... > mtc@freedomincluded:~$ dillo -g 999x666 > http://uaddit.com/discussions/showthread.php?t=5931 > paths: Cannot open file '/home/mtc/.dillo/keysrc' > paths: Using /usr/local/etc/dillo/keysrc > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' > Dns_server [0]: uaddit.com is 72.44.80.46 > Connecting to 72.44.80.46 > CssParser::parseImport(): @import > clientscript/vbulletin_css/style-01a90dc0-00011.css > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted > Please start dillo, disable css (tools button) and load the page. If it doesn't crash after the page loads, enable css again and see what happens (this is to check in what part of dillo the allocation problem is and to discard a race condition between css and html rendering). This bug is very interesting (probably there's something uninitialized in dillo or outside of it). I'll check with valgrind. Can someone else reproduce this bug? -- Cheers Jorge.-

May 14, 2010

Re: dillo question

by jcid＠dillo.org

Hi Matthew, Please follow this thread in dillo-dev. There's no better place to get good feedback. On Mon, May 10, 2010 at 08:00:39PM -0400, Matthew Craig wrote: > Hello Jorge, > I have been using dillo quite a bit on my Lemote Longsoon laptop, with > some success. But, there are often fatal crashes. Do you think this > is based on the MIPS architecture, or just Dillo not handling many web > pages well? Here is the output of the most recent crash. Dillo is very stable on several platforms. I don't believe it has to do with MIPS, but with memory usage. The crash output points to a memory allocating function. When there's no more memory, dillo just exits. Please let us know how much memory you have on the Lemote, and watch it with top or a memory profiler, to know how much is available after X is running. I'd expect the page not to crash if Dillo is the first and only application running and if it is the first page you open (i.e. with more memory available). > > Connecting to 216.250.116.45 > Dns_server [0]: feeds2.feedburner.com is 74.125.93.118 > Dns_server [1]: www.w3.org is 128.30.52.166 128.30.52.168 > 128.30.52.170 128.30.52.38 128.30.52.51 128.30.52.53 128.30.52.54 > Nav_open_url: new > url='http://francisshanahan.com/index.php/2005/primer-movie-scene-by-scene-expla…' > Connecting to 216.250.116.45 > Dns_server [0]: images.amazon.com is 207.123.55.126 209.84.20.126 > 204.160.127.126 > Dns_server [1]: www.gravatar.com is 72.233.61.123 72.233.61.125 > 72.233.69.4 72.233.69.5 72.233.44.59 72.233.44.61 > a_UIcmd_close_bw > Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' > Dns_server [0]: uaddit.com is 72.44.80.46 > Connecting to 72.44.80.46 > CssParser::parseImport(): @import > clientscript/vbulletin_css/style-01a90dc0-00011.css > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted > -- Cheers Jorge.-

May 11, 2010

Re: Bug in Dillo Text Entry

by Johannes.Hofmann＠gmx.de

On Mon, May 10, 2010 at 11:23:38PM +0100, higuita wrote: > hi again > > On Mon, 10 May 2010 05:21:14 +0200, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > > I just committed a fix which works for me. Please give it a try > > and report any focus weirdness. > > i'm getting mixed results in fluxbox... sometime it works, > others dont... > > On a dropdown menu, the focus always work, but in a textarea, > when i click on it, it works, and i can change the focus to other > apps as long as i want without any problem. > > if i then click again on the textarea, when i change focus to > other apps, i lose the textarea focus and will not work again, > until i click again on the textarea and gain focus one more time and > it will work fine until i click yet another time on the textarea... > making it stop working. > > So odd clicks on the textarea will work, even clicks fail to > work ... or was that the inverse!? :) Haha, I also see this now - weird. I will look into it.

May 11, 2010

Re: Bug in Dillo Text Entry

by higuita7＠yahoo.co.uk

hi again On Mon, 10 May 2010 05:21:14 +0200, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > I just committed a fix which works for me. Please give it a try > and report any focus weirdness. i'm getting mixed results in fluxbox... sometime it works, others dont... On a dropdown menu, the focus always work, but in a textarea, when i click on it, it works, and i can change the focus to other apps as long as i want without any problem. if i then click again on the textarea, when i change focus to other apps, i lose the textarea focus and will not work again, until i click again on the textarea and gain focus one more time and it will work fine until i click yet another time on the textarea... making it stop working. So odd clicks on the textarea will work, even clicks fail to work ... or was that the inverse!? :) Hope this helps cya higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

May 11, 2010

Re: Bug in Dillo Text Entry

by jcid＠dillo.org

On Mon, May 10, 2010 at 05:21:14AM +0200, Johannes Hofmann wrote: > On Sun, May 09, 2010 at 09:14:01AM -0400, Jorge Arellano Cid wrote: > > On Sun, May 09, 2010 at 07:23:38AM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx(a)sdf.org wrote: > > > > I posted to the mailing list sometime ago concerning a bug with Dillo > > > > text entry form. After some time, the text entry box in google search > > > > box (or on other websites) would only allow certain keys to be typed > > > > (ie. s and g, most other keys simply ignored when typed in text entry > > > > boxes). > > > > > > I can reproduce this now, however as you say, I think it just looses > > > focus, so here no keys work at all until I refocus the text input. > > > > > > > > > > > I've finally resolved this, or hacked around it to live with it better. > > > > > > Did you fix some code, or do you just refocus manually? > > > > > > > > > > > The bug occurs when a user of the DWM desktop moves Dillo from one > > > > virtual window to another virtual window using "Meta key + right mouse > > > > click" and the "right mouse click + virtual window number" to move a > > > > window to another virtual desktop within DWM. > > > > > > > > Once moved to the other window, the text entry box will exhibit the > > > > above keyboard entry anomly. Basically, I think it's just loosing > > > > focus. The user can get back regular keyboard entry by using "Meta Key > > > > + Tab" to toggle focus from the previous desktop and then again to > > > > regain focus of the virtual desktop containing Dillo, and should then be > > > > able to type normally again. All keys should work. > > > > > > > > Again, I think Dillo is just losing focus of the text entry box.. or > > > > something similar. > > > > > > As other fltk2 apps don't show this behaviour we should be able to > > > fix that in dillo, but I don't yet understand fully what is going > > > on. > > > > If this doesn't happen in other fltk2 apps, then the focus > > event (or similar) is correctly delivered by the WM and lost in > > the way by dillo's UI. I'd try to find what events a one-input > > widget-fltk2-program receives and how it handles it, and then see > > what happens in dillo. > > > > PS: This can be done simply by adding a custom handle() method > > with some printfs and that calls the old handle(). > > I just committed a fix which works for me. Please give it a try > and report any focus weirdness. It work great here. FWIW, I also noticed the problem with dw-resource-test, and it's fixed now. Kudos! -- Cheers Jorge.-

May 10, 2010

Re: Bug in Dillo Text Entry

by Johannes.Hofmann＠gmx.de

On Sun, May 09, 2010 at 09:14:01AM -0400, Jorge Arellano Cid wrote: > On Sun, May 09, 2010 at 07:23:38AM +0200, Johannes Hofmann wrote: > > Hi, > > > > On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx(a)sdf.org wrote: > > > I posted to the mailing list sometime ago concerning a bug with Dillo > > > text entry form. After some time, the text entry box in google search > > > box (or on other websites) would only allow certain keys to be typed > > > (ie. s and g, most other keys simply ignored when typed in text entry > > > boxes). > > > > I can reproduce this now, however as you say, I think it just looses > > focus, so here no keys work at all until I refocus the text input. > > > > > > > > I've finally resolved this, or hacked around it to live with it better. > > > > Did you fix some code, or do you just refocus manually? > > > > > > > > The bug occurs when a user of the DWM desktop moves Dillo from one > > > virtual window to another virtual window using "Meta key + right mouse > > > click" and the "right mouse click + virtual window number" to move a > > > window to another virtual desktop within DWM. > > > > > > Once moved to the other window, the text entry box will exhibit the > > > above keyboard entry anomly. Basically, I think it's just loosing > > > focus. The user can get back regular keyboard entry by using "Meta Key > > > + Tab" to toggle focus from the previous desktop and then again to > > > regain focus of the virtual desktop containing Dillo, and should then be > > > able to type normally again. All keys should work. > > > > > > Again, I think Dillo is just losing focus of the text entry box.. or > > > something similar. > > > > As other fltk2 apps don't show this behaviour we should be able to > > fix that in dillo, but I don't yet understand fully what is going > > on. > > If this doesn't happen in other fltk2 apps, then the focus > event (or similar) is correctly delivered by the WM and lost in > the way by dillo's UI. I'd try to find what events a one-input > widget-fltk2-program receives and how it handles it, and then see > what happens in dillo. > > PS: This can be done simply by adding a custom handle() method > with some printfs and that calls the old handle(). I just committed a fix which works for me. Please give it a try and report any focus weirdness. Cheers, Johannes

May 10, 2010

Re: Bug in Dillo Text Entry

by higuita7＠yahoo.co.uk

Hi On Sun, 9 May 2010 21:04:27 +0200, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > If I focus a textinput or textarea, then unfocus the window and > focus it again, the textinput has lost focus. (...) > Are others seeing that behaviour too? i can confirm this in fluxbox higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

May 10, 2010

Re: Bug in Dillo Text Entry

by corvid＠lavabit.com

Johannes wrote: > I now tried with another wm (twm) and also see the problem there, > also with dw-ui-test. > If I focus a textinput or textarea, then unfocus the window and > focus it again, the textinput has lost focus. > I'm not sure if that is really the same problem that rogerx > reported, but it is certainly not ok. > > Are others seeing that behaviour too? Yes. (fvwm)

May 9, 2010

Re: Bug in Dillo Text Entry

by Johannes.Hofmann＠gmx.de

On Sun, May 09, 2010 at 09:14:01AM -0400, Jorge Arellano Cid wrote: > On Sun, May 09, 2010 at 07:23:38AM +0200, Johannes Hofmann wrote: > > Hi, > > > > On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx(a)sdf.org wrote: > > > I posted to the mailing list sometime ago concerning a bug with Dillo > > > text entry form. After some time, the text entry box in google search > > > box (or on other websites) would only allow certain keys to be typed > > > (ie. s and g, most other keys simply ignored when typed in text entry > > > boxes). > > > > I can reproduce this now, however as you say, I think it just looses > > focus, so here no keys work at all until I refocus the text input. > > > > > > > > I've finally resolved this, or hacked around it to live with it better. > > > > Did you fix some code, or do you just refocus manually? > > > > > > > > The bug occurs when a user of the DWM desktop moves Dillo from one > > > virtual window to another virtual window using "Meta key + right mouse > > > click" and the "right mouse click + virtual window number" to move a > > > window to another virtual desktop within DWM. > > > > > > Once moved to the other window, the text entry box will exhibit the > > > above keyboard entry anomly. Basically, I think it's just loosing > > > focus. The user can get back regular keyboard entry by using "Meta Key > > > + Tab" to toggle focus from the previous desktop and then again to > > > regain focus of the virtual desktop containing Dillo, and should then be > > > able to type normally again. All keys should work. > > > > > > Again, I think Dillo is just losing focus of the text entry box.. or > > > something similar. > > > > As other fltk2 apps don't show this behaviour we should be able to > > fix that in dillo, but I don't yet understand fully what is going > > on. > > If this doesn't happen in other fltk2 apps, then the focus > event (or similar) is correctly delivered by the WM and lost in > the way by dillo's UI. I'd try to find what events a one-input > widget-fltk2-program receives and how it handles it, and then see > what happens in dillo. I now tried with another wm (twm) and also see the problem there, also with dw-ui-test. If I focus a textinput or textarea, then unfocus the window and focus it again, the textinput has lost focus. I'm not sure if that is really the same problem that rogerx reported, but it is certainly not ok. Are others seeing that behaviour too? > > PS: This can be done simply by adding a custom handle() method > with some printfs and that calls the old handle(). Tried that a bit, but no luck so far. Cheers, Johannes

May 9, 2010

setting image buffer and queueing resize

by jcid＠dillo.org

On Sun, May 09, 2010 at 07:34:29AM +0200, Johannes Hofmann wrote: > On Wed, Apr 28, 2010 at 05:21:56PM +0000, corvid wrote: > > I had just fixed the dw simple image test that hadn't requested a > > resize when setting the imgbuf. And now I just found that one of the > > scaled2 test's images needs it as well. > > > > Perhaps we should make the resize argument to setBuffer() mandatory. > > > > But, better yet, how about if Image::setBuffer() just does a queueResize() if > > either of its dimensions are LENGTH_AUTO? > > I also think we should get rid of the resize parameter of > setBuffer() entirely. > I'm not 100% sure about when we need the queueResize(), that would > need some testing. AFAIR the main idea is to queueResize() whenever a widget changes it size. That way several widgets can make the call and the resize process is done only once when the time arrives. BTW, I'm not oppossed at all in eliminating the resize parameter, but haven't looked at it in enough depth to assign any weight to my opinnion on the subject. ;-) -- Cheers Jorge.-

May 9, 2010