- Dillo-dev - lists.mailman3.com

Re: dillo question

by Johannes.Hofmann＠gmx.de

On Fri, May 14, 2010 at 08:51:33AM -0400, Jorge Arellano Cid wrote: > 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? Works fine for me. Are there any process limits set in your environmen (ulimit -a)? Cheers, Johannes

May 14, 2010

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. > > 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 I can't reproduce it with valgrind... :-P ...but, from the above output, the last debug message comes from cssparser.cc:1428 and it calls a_Html_load_stylesheet() which should print "NumPendingStyleSheets=1" (html.cc:2985). So, the problem is in this tiny spot. Please run gdb, set a break point in a_Html_load_stylesheet() and follow it carefully step by step until it crashes to know in what line the problem is triggered. -- Cheers Jorge.-

May 14, 2010

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

Re: Bug in Dillo Text Entry

by jcid＠dillo.org

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(). -- Cheers Jorge.-

May 9, 2010

setting image buffer and queueing resize

by Johannes.Hofmann＠gmx.de

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.

May 9, 2010

Re: Bug in Dillo Text Entry

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes PS: Good to see that there is other dwm + dillo users out there :-)

May 9, 2010

Re: commit 3e01d83fd6d1 draws too large background box

by Johannes.Hofmann＠gmx.de

Hi, sorry for the delay... On Tue, Apr 27, 2010 at 11:40:11PM +0200, Johannes Hofmann wrote: > On Tue, Apr 27, 2010 at 09:04:49PM +0000, corvid wrote: > > > commit 3e01d83fd6d1 (draw background for all Words, not just text) > > > draws a too large background box e.g. in this example: > > > > > > <html><body> > > > foo <div style="background-color: blue; margin-top: 100px">bar</div> > > > </body></html> > > > > > > The margin should not be blue. > > > What is the reason for this change anyway? Shouldn't each widget be > > > responsible for it's drawing (including the background)? > > > > This is when I was looking at the rectangles of color on the fltk.org > > page around, e.g., "FLTK Apps", "FLTK Library"... > > > > The rectangle of color (which came from the style of the A element, iirc) > > is "supposed" to be taller than the little rounded-corner images, judging > > by what firefox does. > > Ah, I think I see the problem now. Textblock has to draw the > background for the <A> element - even at places where it is covered > by child widgets, as they might be transparent. > On the other hand margins are always transparent (see > http://www.w3.org/TR/CSS2/box.html) so there is a problem in the > current implementation. > I guess I need some time to think about this. > > > > > So if the margin is part of the child, then... > > how should this be disentangled? > > Does it come down to being one of those things that have to wait until > > we have more of a real box model? > > > > We already have a proper box model for block boxes, what we are missing > is proper handling of inline boxes (e.g. drawing borders around > <a>-elements). Ok, the general problem is that a single Textblock widget can handle multiple HTML elements. E.g. in this case: <a href=foo style="background-color: red">foo <b>bar</b></a> there is just a single Textblock drawing the whole thing. The style of the word "bar" would normally not have a background color set, but the red of the <a> element would shine through, but as the textblock simply draws one word after the other, we do not draw the whole <a> element and then draw the <b> element on top. To make the background color work nevertheless, I had introduced the inheritBackgroundColor hack, which will pass the red background to the style of the child element (<b> in this case). However, this hack does not work properly if the child element has a margin: <a href=foo style="background-color: red">foo <img src=foo.png alt=bar style="margin:1em"></a> So I think we should remove the whole inheritBackgroundColor() hack and replace it with some code in textblock.cc, that draws the proper background color for all words as necessary. We need to be careful though to not draw word backgrounds if they are the same color as the whole textblock to avoid excessive drawing. This would still not allow things like: <b style="border: 1px solid black">foo</b> but I currently don't see a simple way to make that work. Cheers, Johannes

May 9, 2010

[rogerx@sdf.org: Bug in Dillo Text Entry]

by jcid＠dillo.org

-- Cheers Jorge.-

May 8, 2010

setting image buffer and queueing resize

by corvid＠lavabit.com

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?

April 28, 2010

Re: style.css font-family misses redraw

by dennisn＠dennisn.dyndns.org

On Tue, 27 Apr 2010 20:54:37 +0200, Johannes Hofmann wrote: > On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > > > * { font-family:sans-serif } > > > > > > > > And then visit a page like: > > > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > > > ... it will produce "ghost" lines from the previous rendering > > > > before the css was applied. Moving the window, or doing > > > > anything else that forces a redraw, cleans it up. (Let me know > > > > if you don't see this and I can provide a screenshot.) > > > > > > Hm, the page does not seem to contain any CSS, so it renders with > > > just the user agent style and the user style (~/.dillo/style.css) > > > even the first time it draws. Maybe it's because of the images > > > that change the layout once loaded? > > > Can you reproduce the issue with load_images=NO? > > > > > > I've alse seen "ghost" lines on some pages, but could never find > > > the real reason. I only remeber that it depended on timing > > > somehow. > > > > The issue does not appear with load_images=NO ... ie. when it only > > occurs when images are loaded, and the table cells redrawn, but > > apparently not rendered automatically. (Until one moves the window, > > etc.) > > > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > > > > Can you please test this patch > http://flpsed.org/tmp/ghostlines.diff > It fixes the issue I could reproduce here. Problem solved! :D

April 28, 2010

Re: style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > * { font-family:sans-serif } > > > > > > And then visit a page like: > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > the css was applied. Moving the window, or doing anything else that > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > and I can provide a screenshot.) > > > > Hm, the page does not seem to contain any CSS, so it renders with > > just the user agent style and the user style (~/.dillo/style.css) > > even the first time it draws. Maybe it's because of the images that > > change the layout once loaded? > > Can you reproduce the issue with load_images=NO? > > > > I've alse seen "ghost" lines on some pages, but could never find > > the real reason. I only remeber that it depended on timing somehow. > > The issue does not appear with load_images=NO ... ie. when it only > occurs when images are loaded, and the table cells redrawn, but > apparently not rendered automatically. (Until one moves the window, > etc.) > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > Can you please test this patch http://flpsed.org/tmp/ghostlines.diff It fixes the issue I could reproduce here. Cheers, Johannes

April 27, 2010

Re: style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Tue, Apr 27, 2010 at 12:41:09PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > > > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > > > > > * { font-family:sans-serif } > > > > > > > > > > And then visit a page like: > > > > > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > > > the css was applied. Moving the window, or doing anything else that > > > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > > > and I can provide a screenshot.) > > > > > > > > Hm, the page does not seem to contain any CSS, so it renders with > > > > just the user agent style and the user style (~/.dillo/style.css) > > > > even the first time it draws. Maybe it's because of the images that > > > > change the layout once loaded? > > > > Can you reproduce the issue with load_images=NO? > > > > > > > > I've alse seen "ghost" lines on some pages, but could never find > > > > the real reason. I only remeber that it depended on timing somehow. > > > > > > The issue does not appear with load_images=NO ... ie. when it only > > > occurs when images are loaded, and the table cells redrawn, but > > > apparently not rendered automatically. (Until one moves the window, > > > etc.) > > > > > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > > > > Is anyone else seeing this issue on that page? It seems to work fine > > here, but I know that there is a problem, it's just hard to > > reproduce. > > Dennis: Do you know when the problem was introduced? I can now see a similar issue with this HTML fragment: <img src="http://flpsed.org/tmp/blank.gif" alt="Ico"> Name But it depends on your font settings. The point seems to be that the alt text is almost the same width as the image itself, so you might need to tweak the alt text for your font settings.

April 27, 2010

Re: style.css font-family misses redraw

by corvid＠lavabit.com

Johannes wrote: > On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > > > * { font-family:sans-serif } > > > > > > > > And then visit a page like: > > > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > > the css was applied. Moving the window, or doing anything else that > > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > > and I can provide a screenshot.) > > > > > > Hm, the page does not seem to contain any CSS, so it renders with > > > just the user agent style and the user style (~/.dillo/style.css) > > > even the first time it draws. Maybe it's because of the images that > > > change the layout once loaded? > > > Can you reproduce the issue with load_images=NO? > > > > > > I've alse seen "ghost" lines on some pages, but could never find > > > the real reason. I only remeber that it depended on timing somehow. > > > > The issue does not appear with load_images=NO ... ie. when it only > > occurs when images are loaded, and the table cells redrawn, but > > apparently not rendered automatically. (Until one moves the window, > > etc.) > > > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > > Is anyone else seeing this issue on that page? It seems to work fine > here, but I know that there is a problem, it's just hard to > reproduce. Dennis: Do you know when the problem was introduced?

April 27, 2010

Re: style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > * { font-family:sans-serif } > > > > > > And then visit a page like: > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > the css was applied. Moving the window, or doing anything else that > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > and I can provide a screenshot.) > > > > Hm, the page does not seem to contain any CSS, so it renders with > > just the user agent style and the user style (~/.dillo/style.css) > > even the first time it draws. Maybe it's because of the images that > > change the layout once loaded? > > Can you reproduce the issue with load_images=NO? > > > > I've alse seen "ghost" lines on some pages, but could never find > > the real reason. I only remeber that it depended on timing somehow. > > The issue does not appear with load_images=NO ... ie. when it only > occurs when images are loaded, and the table cells redrawn, but > apparently not rendered automatically. (Until one moves the window, > etc.) > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg Is anyone else seeing this issue on that page? It seems to work fine here, but I know that there is a problem, it's just hard to reproduce.

April 27, 2010

Re: style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Sun, Apr 25, 2010 at 11:35:20AM -0400, Dennis Nezic wrote: > On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > > > * { font-family:sans-serif } > > > > > > And then visit a page like: > > > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > > > ... it will produce "ghost" lines from the previous rendering before > > > the css was applied. Moving the window, or doing anything else that > > > forces a redraw, cleans it up. (Let me know if you don't see this > > > and I can provide a screenshot.) > > > > Hm, the page does not seem to contain any CSS, so it renders with > > just the user agent style and the user style (~/.dillo/style.css) > > even the first time it draws. Maybe it's because of the images that > > change the layout once loaded? > > Can you reproduce the issue with load_images=NO? > > > > I've alse seen "ghost" lines on some pages, but could never find > > the real reason. I only remeber that it depended on timing somehow. > > The issue does not appear with load_images=NO ... ie. when it only > occurs when images are loaded, and the table cells redrawn, but > apparently not rendered automatically. (Until one moves the window, > etc.) > > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg > http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg > I'm pretty sure it has to do with the redraw optimization. But it seems to be depending on download speed or timing somehow, as I don's see it here. I will try to find the problem, but I remember looking into a similar issue without success. Cheers, Johannes

April 26, 2010

Re: style.css font-family misses redraw

by dennisn＠dennisn.dyndns.org

On Fri, 23 Apr 2010 23:37:31 +0200, Johannes Hofmann wrote: > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > * { font-family:sans-serif } > > > > And then visit a page like: > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > ... it will produce "ghost" lines from the previous rendering before > > the css was applied. Moving the window, or doing anything else that > > forces a redraw, cleans it up. (Let me know if you don't see this > > and I can provide a screenshot.) > > Hm, the page does not seem to contain any CSS, so it renders with > just the user agent style and the user style (~/.dillo/style.css) > even the first time it draws. Maybe it's because of the images that > change the layout once loaded? > Can you reproduce the issue with load_images=NO? > > I've alse seen "ghost" lines on some pages, but could never find > the real reason. I only remeber that it depended on timing somehow. The issue does not appear with load_images=NO ... ie. when it only occurs when images are loaded, and the table cells redrawn, but apparently not rendered automatically. (Until one moves the window, etc.) http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines.jpg http://dennisn.dyndns.org/guest/pubstuff/dillo-ghostlines-gone.jpg

April 25, 2010

image background colors

by Johannes.Hofmann＠gmx.de

On Sat, Apr 24, 2010 at 07:43:38PM +0000, corvid wrote: > Johannes wrote: > > On Wed, Apr 21, 2010 at 10:28:46AM +0200, Johannes Hofmann wrote: > > > On Wed, Apr 21, 2010 at 05:01:11AM +0000, corvid wrote: > > > > Is this anywhere near correct? > > > > > > It is definately better than what we have now, but somehow this > > > image background handling is a bit of a hack all together. > > > Basically the Image Widget should get the background color via > > > Widget::getBgColor() at drawing time. > > > That would avoid any special handling in html.cc and would allow to > > > modify the background color by setting a different style. > > > However I can't see any easy way to achive this atm. > > > > It seems that dw/imgbuf.hh supports RGBA images already. We > > probabely want to use them instead of just RGB with merged in > > background color. Otherwise we will have problems as in the > > following example (due to the shared image buffer): > > I played with this some time ago > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-May/004265.html > and had some difficulties. > > I'll have to see whether I still have that code around somewhere... That would be cool. I'd really like to remove the image background handling from src/* and use RGBA image buffers instead.

April 24, 2010

image background colors

by corvid＠lavabit.com

Johannes wrote: > On Wed, Apr 21, 2010 at 10:28:46AM +0200, Johannes Hofmann wrote: > > On Wed, Apr 21, 2010 at 05:01:11AM +0000, corvid wrote: > > > Is this anywhere near correct? > > > > It is definately better than what we have now, but somehow this > > image background handling is a bit of a hack all together. > > Basically the Image Widget should get the background color via > > Widget::getBgColor() at drawing time. > > That would avoid any special handling in html.cc and would allow to > > modify the background color by setting a different style. > > However I can't see any easy way to achive this atm. > > It seems that dw/imgbuf.hh supports RGBA images already. We > probabely want to use them instead of just RGB with merged in > background color. Otherwise we will have problems as in the > following example (due to the shared image buffer): I played with this some time ago http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-May/004265.html and had some difficulties. I'll have to see whether I still have that code around somewhere...

April 24, 2010

image background colors

by Johannes.Hofmann＠gmx.de

On Wed, Apr 21, 2010 at 10:28:46AM +0200, Johannes Hofmann wrote: > On Wed, Apr 21, 2010 at 05:01:11AM +0000, corvid wrote: > > Is this anywhere near correct? > > It is definately better than what we have now, but somehow this > image background handling is a bit of a hack all together. > Basically the Image Widget should get the background color via > Widget::getBgColor() at drawing time. > That would avoid any special handling in html.cc and would allow to > modify the background color by setting a different style. > However I can't see any easy way to achive this atm. It seems that dw/imgbuf.hh supports RGBA images already. We probabely want to use them instead of just RGB with merged in background color. Otherwise we will have problems as in the following example (due to the shared image buffer): <div style="background-color: green"> <img src="http://www.libpng.org/pub/png/img_png/stefan_pal_rgba.png" /> </div> <div style="background-color: red"> <img src="http://www.libpng.org/pub/png/img_png/stefan_pal_rgba.png" /> </div> Cheers, Johannes

April 24, 2010

style.css font-family misses redraw

by corvid＠lavabit.com

Johannes wrote: > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > * { font-family:sans-serif } > > > > And then visit a page like: > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > ... it will produce "ghost" lines from the previous rendering before > > the css was applied. Moving the window, or doing anything else that > > forces a redraw, cleans it up. (Let me know if you don't see this and I > > can provide a screenshot.) > > Hm, the page does not seem to contain any CSS, so it renders with > just the user agent style and the user style (~/.dillo/style.css) > even the first time it draws. Maybe it's because of the images that > change the layout once loaded? > Can you reproduce the issue with load_images=NO? > > I've alse seen "ghost" lines on some pages, but could never find > the real reason. I only remeber that it depended on timing somehow. I didn't see a problem, either. I'm usually using buffered_drawing=2, if that's relevant, and all I ever see is that sometimes when I load an image that enlarges a table, it...leaves a line for the old bottoms of neighboring cells, or something like that. I don't remember exactly for sure what happens. It's rare, and I ignore it in any case because I would prefer not to dig into the table code...

April 24, 2010

style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > If you specify a font-family in ~/.dillo/style.css, such as: > > * { font-family:sans-serif } > > And then visit a page like: > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > ... it will produce "ghost" lines from the previous rendering before > the css was applied. Moving the window, or doing anything else that > forces a redraw, cleans it up. (Let me know if you don't see this and I > can provide a screenshot.) Hm, the page does not seem to contain any CSS, so it renders with just the user agent style and the user style (~/.dillo/style.css) even the first time it draws. Maybe it's because of the images that change the layout once loaded? Can you reproduce the issue with load_images=NO? I've alse seen "ghost" lines on some pages, but could never find the real reason. I only remeber that it depended on timing somehow. Cheers, Johannes

April 23, 2010

style.css font-family misses redraw

by dennisn＠dennisn.dyndns.org

If you specify a font-family in ~/.dillo/style.css, such as: * { font-family:sans-serif } And then visit a page like: http://www.linuxfromscratch.org/lfs/downloads/6.6/ ... it will produce "ghost" lines from the previous rendering before the css was applied. Moving the window, or doing anything else that forces a redraw, cleans it up. (Let me know if you don't see this and I can provide a screenshot.)

April 23, 2010

zero-delay refresh, but no URL

by jcid＠dillo.org

On Fri, Apr 23, 2010 at 01:19:28AM +0000, corvid wrote: > Jorge wrote: > > > So perhaps the nav redirection stuff should use bw->redirect_level. > > > > This looks like a good idea. > > If you want to make a patch go ahead, I'll look at the expect url > > issue with zero-delay refresh now. > > I see that, in Cache_process_queue(), redirect_level is zeroed if > CA_Redirect isn't set. I wonder whether, since this is http-equiv, > it should reach into cache in a way that's similar to Content-Type > and let us rip out the nav redirection code. This may be a sleeping dragon. It could look cleaner if handled in cache, but there's a need to sync the redirecting-URL not to end in the history stack, while at the same time letting the resource finish loading and to assert repush works OK (part of this is achieved by using a timeout in nav). Maybe it can be done easily, I don't know yet. Although I remember very well that "charset" given by HTML's META was a royal PITA to handle! (chicken/egg problem). ATM we're handling zero-delay redirection for root URLs only. I see little use for generalizing it to child resources. I see clear gain in the case of HTTP redirection. My point is: it could take a significative effort that would be better spent on something more urgent/strategic for the project. -- Cheers Jorge.-

April 23, 2010

zero-delay refresh, but no URL

by corvid＠lavabit.com

Jorge wrote: > > So perhaps the nav redirection stuff should use bw->redirect_level. > > This looks like a good idea. > If you want to make a patch go ahead, I'll look at the expect url > issue with zero-delay refresh now. I see that, in Cache_process_queue(), redirect_level is zeroed if CA_Redirect isn't set. I wonder whether, since this is http-equiv, it should reach into cache in a way that's similar to Content-Type and let us rip out the nav redirection code.

April 23, 2010

zero-delay refresh, but no URL

by corvid＠lavabit.com

Jorge wrote: > On Thu, Apr 22, 2010 at 05:53:00AM +0000, corvid wrote: > > http://www.algo-prog.info/ocmc/ > > contains > > <meta http-equiv="refresh" content="0;web/" /> > > > > For refresh, we assume there will be an '=' from "URL=". > > Unfortunately there's no standard for the content string in a META > refresh. The example by W3C uses "URL=" so it looks OK to expect it. I was tempted to complain in my previous mail about how it was underspecified :) Some sufficiently old html specs didn't show the URL=, incidentally http://www.w3.org/TR/1998/REC-html40-19980424/struct/global.html#h-7.4.4

April 22, 2010

zero-delay refresh, but no URL

by jcid＠dillo.org

On Thu, Apr 22, 2010 at 05:53:00AM +0000, corvid wrote: > http://www.algo-prog.info/ocmc/ > contains > <meta http-equiv="refresh" content="0;web/" /> > > For refresh, we assume there will be an '=' from "URL=". Unfortunately there's no standard for the content string in a META refresh. The example by W3C uses "URL=" so it looks OK to expect it. > Since there isn't one, we refresh the same URL over and over and over... > > We could refuse to follow a zero-delay refresh without a new URL, > but I seem to recall back in the never-follow days that sometimes > a page _wanted_ to be immediately refreshed once, after which it > would provide the contents (I always wondered why). > > So perhaps the nav redirection stuff should use bw->redirect_level. This looks like a good idea. If you want to make a patch go ahead, I'll look at the expect url issue with zero-delay refresh now. -- Cheers Jorge.-

April 22, 2010

zero-delay refresh, but no URL

by corvid＠lavabit.com

http://www.algo-prog.info/ocmc/ contains <meta http-equiv="refresh" content="0;web/" /> For refresh, we assume there will be an '=' from "URL=". Since there isn't one, we refresh the same URL over and over and over... We could refuse to follow a zero-delay refresh without a new URL, but I seem to recall back in the never-follow days that sometimes a page _wanted_ to be immediately refreshed once, after which it would provide the contents (I always wondered why). So perhaps the nav redirection stuff should use bw->redirect_level.

April 22, 2010

image background colors

by Johannes.Hofmann＠gmx.de

On Wed, Apr 21, 2010 at 05:01:11AM +0000, corvid wrote: > Is this anywhere near correct? It is definately better than what we have now, but somehow this image background handling is a bit of a hack all together. Basically the Image Widget should get the background color via Widget::getBgColor() at drawing time. That would avoid any special handling in html.cc and would allow to modify the background color by setting a different style. However I can't see any easy way to achive this atm. > > (This at least makes the background colors right for the rounded-corner > images on the top row of links at fltk.org. > Of course it still looks funny because valign top isn't obeyed...) > > diff -r 3e01d83fd6d1 src/html.cc > --- a/src/html.cc Wed Apr 21 03:46:20 2010 +0000 > +++ b/src/html.cc Wed Apr 21 04:52:00 2010 +0000 > @@ -2119,7 +2119,10 @@ > > /* Add a new image widget to this page */ > Image = a_Image_new(alt_ptr, 0); > - if (HT2TB(html)->getBgColor()) > + > + if (html->styleEngine->style()->backgroundColor) > + Image->bg_color =html->styleEngine->style()->backgroundColor->getColor(); > + else if (HT2TB(html)->getBgColor()) > Image->bg_color = HT2TB(html)->getBgColor()->getColor(); > > load_now = prefs.load_images || > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 21, 2010

classes and pseudoclasses

by Johannes.Hofmann＠gmx.de

On Wed, Apr 21, 2010 at 02:45:10AM +0000, corvid wrote: > I was looking at how the fltk site appears, and noticed that > dillo and firefox have different ideas of what to do for: > > <html><head><style> > A:link {color: #ff0000} > A.unsel {color: #000000; background-color: #00ff00} > </style></head><body> > <a class=unsel href=http://www.dillo.org>a link</a> > </body></html> Both selectors have the same specificity and therefore the ordering is relevant - the later one should beat the first one (http://www.w3.org/TR/CSS2/cascade.html#cascading-order) dillo stores the selectors in several hash maps and lists for fast access and unfortunately in this case the two selectors end up in separate lists and so the ordering information is lost. The same thing can happen if an element has more than one class: <html><head><style> A.foo {color: #ff0000} A.bar {color: #000000; background-color: #00ff00} </style></head><body> <a class="foo bar" href=http://www.dillo.org>a link</a> </body></html> The obvious fix is to store order information in the selectors and sort them before applying. The question is how to do that efficient (memory and CPU-wise).

April 21, 2010

image background colors

by corvid＠lavabit.com

Is this anywhere near correct? (This at least makes the background colors right for the rounded-corner images on the top row of links at fltk.org. Of course it still looks funny because valign top isn't obeyed...)

April 21, 2010

classes and pseudoclasses

by corvid＠lavabit.com

I was looking at how the fltk site appears, and noticed that dillo and firefox have different ideas of what to do for: <html><head><style> A:link {color: #ff0000} A.unsel {color: #000000; background-color: #00ff00} </style></head><body> <a class=unsel href=http://www.dillo.org>a link</a> </body></html>

April 21, 2010

Dillo: being removed from Debian

by jcid＠dillo.org

FYI, corvid wrote: > Johannes wrote: > > On Tue, Apr 20, 2010 at 10:14:56AM -0400, Jorge Arellano Cid wrote: > > > On Tue, Apr 20, 2010 at 03:31:47PM +0300, Jari Aalto wrote: > > > > > > > > Dillow in in danger being removed from debian > > > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575240 > > > > > > > > This is mostly due to RC bugs (grace, serious, important) listed in: > > > > > > > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dillo;dist=unstabl > > > > > > > > The current Debian maintainer does not seem to repond any longer, so I > > > > could offer my help to keep the package in Debian: > > > > > > > > Would you take a look at the Debian bug listing and see their > > > > Could be solved or if they already are in latest version? > > > > > > > > Thanks for any help, > > > > Jari > > > > > > I'd be happy if dillo1 is removed from Debian: > > > > > > > > > * It's full of bugs (+ i18n's patch bugs) > > > * Uses GTK1 (this misleads developers, packagers and distros to > > > think that dillo is still a GTK1-based project). > > > * When people hear about dillo, or find our website, they try a simple > > > 'apt-get dillo' and get the wrong picture. Then they find out it > > > haven't had patches in years <-> dead project. Who would like to > > > put his effort into that project? > > > * It states that is not the official dillo and that dillo.org developers > > > should not be bothered with its bugs (my request at the time), but > > > this chains the question: why did the trusty Debian maintainers chose > > > the unnoficial version? There must be problems with the official on > > > * Dillo1 has been unmaintained for years. > > > > > > Then I'd be even happier if we can get dillo/fltk-1.3 into Debian, > > > in the short term. > > > > > > I guess it's easier by first removing dillo1 and then pushing dillo2, > > > but don't know about Debian policies. > > > > > > I'd answer Jari along the above lines, CC'ing dillo-dev. > > > > > > What do you guys think? > > > > I fully agree > > *agrees* -- Cheers Jorge.-

April 20, 2010

make instant meta-refresh optional?

by jcid＠dillo.org

On Fri, Apr 16, 2010 at 12:24:17AM +0000, corvid wrote: > Scott wrote: > > * Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > The problem is that W3C has zero delay redirection as an > > > standard. I think a "follow_zero_redirects" dillorc option is > > > a good solution. > > > > Sounds perfect! > > > > Sorry I didn't include a patch to implement it... I'm not sure > > how the config mechanisms work, and didn't know whether there was > > any chance of getting the change accepted. > > If you take a look at how other prefs are introduced, e.g. > http://hg.dillo.org/dillo/rev/c47ab3201464 > it's not too complicated. > > I would lean toward using a name more like follow_zero_delay_refresh... +1 -- Cheers Jorge.-

April 16, 2010

make instant meta-refresh optional?

by corvid＠lavabit.com

Scott wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > The problem is that W3C has zero delay redirection as an > > standard. I think a "follow_zero_redirects" dillorc option is > > a good solution. > > Sounds perfect! > > Sorry I didn't include a patch to implement it... I'm not sure > how the config mechanisms work, and didn't know whether there was > any chance of getting the change accepted. If you take a look at how other prefs are introduced, e.g. http://hg.dillo.org/dillo/rev/c47ab3201464 it's not too complicated. I would lean toward using a name more like follow_zero_delay_refresh...

April 16, 2010

make instant meta-refresh optional?

by dillo-dev＠toykeeper.net

* Jorge Arellano Cid <jcid(a)dillo.org> wrote: > The problem is that W3C has zero delay redirection as an > standard. I think a "follow_zero_redirects" dillorc option is > a good solution. Sounds perfect! Sorry I didn't include a patch to implement it... I'm not sure how the config mechanisms work, and didn't know whether there was any chance of getting the change accepted. -- Scott

April 16, 2010

make instant meta-refresh optional?

by jcid＠dillo.org

On Wed, Apr 14, 2010 at 07:19:42PM -0600, Scott Scriven wrote: > I was just trying to look up a local place on Google Maps, and > found that the page wouldn't render any more. So I investigated, > and it turns out to be a combination of two problems: > > - Dillo now follows instant meta-refresh commands, instead of > letting the user decide. > > - Google Maps redirects to a 'mobile' version of the site, > which fails to recognize Dillo's user-agent string and > returns WML instead of HTML. (I sent them info about this > bug a few moments ago; hopefully they'll fix it) > > Would it be possible to make that first one optional? Maybe a > config variable or something? I liked the old behavior much > better. The problem is that W3C has zero delay redirection as an standard. I think a "follow_zero_redirects" dillorc option is a good solution. -- Cheers Jorge.-

April 15, 2010

Re: make instant meta-refresh optional?

by dillo-dev＠toykeeper.net

* Dennis Nezic <dennisn(a)dennisn.dyndns.org> wrote: > On Wed, 14 Apr 2010 19:19:42 -0600, Scott Scriven wrote: > > - Google Maps redirects to a 'mobile' version of the site, > > which fails to recognize Dillo's user-agent string and > > returns WML instead of HTML. (I sent them info about this > > bug a few moments ago; hopefully they'll fix it) > I was just about to post about the second point :P. Fixing the first > still wouldn't make the second work? If I disable meta refresh, I can still use the maps site to a limited extent. Or, if I change the user-agent to Mozilla, I can use the HTML version of the mobile interface. Unfortunately, changing the user-agent breaks images.google, because it sends fancy AJAX stuff with no static fallback. And I kinda like to keep Dillo in my user-agent as a way to advertise. > (Why can't dillo read WML?) ... because Dillo is a HTML browser? WML is a totally different language. -- Scott

April 15, 2010

Re: make instant meta-refresh optional?

by dennisn＠dennisn.dyndns.org

On Wed, 14 Apr 2010 19:19:42 -0600, Scott Scriven wrote: > I was just trying to look up a local place on Google Maps, and > found that the page wouldn't render any more. So I investigated, > and it turns out to be a combination of two problems: > > - Dillo now follows instant meta-refresh commands, instead of > letting the user decide. > > - Google Maps redirects to a 'mobile' version of the site, > which fails to recognize Dillo's user-agent string and > returns WML instead of HTML. (I sent them info about this > bug a few moments ago; hopefully they'll fix it) I was just about to post about the second point :P. Fixing the first still wouldn't make the second work? (Why can't dillo read WML?)

April 15, 2010

make instant meta-refresh optional?

by corvid＠lavabit.com

Scott wrote: > I was just trying to look up a local place on Google Maps, and > found that the page wouldn't render any more. So I investigated, > and it turns out to be a combination of two problems: > > - Dillo now follows instant meta-refresh commands, instead of > letting the user decide. > > - Google Maps redirects to a 'mobile' version of the site, > which fails to recognize Dillo's user-agent string and > returns WML instead of HTML. (I sent them info about this > bug a few moments ago; hopefully they'll fix it) > > Would it be possible to make that first one optional? Maybe a > config variable or something? I liked the old behavior much > better. I rather liked the old behavior as well.

April 15, 2010

make instant meta-refresh optional?

by dillo-dev＠toykeeper.net

I was just trying to look up a local place on Google Maps, and found that the page wouldn't render any more. So I investigated, and it turns out to be a combination of two problems: - Dillo now follows instant meta-refresh commands, instead of letting the user decide. - Google Maps redirects to a 'mobile' version of the site, which fails to recognize Dillo's user-agent string and returns WML instead of HTML. (I sent them info about this bug a few moments ago; hopefully they'll fix it) Would it be possible to make that first one optional? Maybe a config variable or something? I liked the old behavior much better. The change was introduced here: changeset: 1037:a72e5506e280 user: Jorge Arellano Cid <jcid(a)dillo.org> date: Sat Apr 18 16:16:18 2009 -0400 summary: Implemented Instant client-side redirects (META refresh with delay=0) For now, I've been building with this small patch: --- a/src/html.cc Wed Apr 07 22:07:07 2010 +0000 +++ b/src/html.cc Wed Apr 14 19:15:12 2010 -0600 @@ -2883,7 +2883,7 @@ mr_url = dStrdup(content); } - if (delay == 0) { + if (0) { /* zero-delay redirection */ html->stop_parser = true; DilloUrl *new_url = a_Url_new(mr_url, URL_STR(html->base_url)); -- Scott

April 15, 2010

Dillo's jealous of Google

by onepoint＠starurchin.org

furaisanjin wrote: > Do you have filter_auto_requests=all in your dillorc? No: $ grep filter /etc/dillo/dillorc ~/.dillo/dillorc /etc/dillo/dillorc:#filter_auto_requests=same_domain > There may be another mechanism to prevent image/style sheet > redirection. I know that you might want to prevent such things, but right now the mechanism is stopping Google from redirecting me to another one of it's own domains. It clearly needs to be made more specific. Thanks for helping me investigate. Hopefully I can look into this some more this weekend. Regards, Jeremy Henty

April 14, 2010