- Dillo-dev - lists.mailman3.com

Refreshing pages with incomplete images

by jcid＠dillo.org

On Wed, Sep 22, 2010 at 12:43:03AM -0400, Dennis Nezic wrote: > Currently refreshing a page only redownloads the text portion (I > believe) and not the images, which is perfect IF the images have been > fully downloaded/cached. On my slow connection, image-downloads > frequently timeout, and refreshing doesn't retry to get them :'(. With a slow connection (e.g. dialup), use something like: http_max_conns=2 /* or 3 */ in dillorc (this solves most of the problem). If a long image download stalls anyway, you will have to reload the whole of it: right click image, "Isolate image", reload, back. -- Cheers Jorge.-

Sept. 22, 2010

Refreshing pages with incomplete images

by furaisanjin＠gmail.com

Hi. That's true. Probably we should have "reload image" in IMAGE OPTIONS menu. Regards, furaisanjin 2010/9/22 Dennis Nezic <dennisn(a)dennisn.dyndns.org>: > Currently refreshing a page only redownloads the text portion (I > believe) and not the images, which is perfect IF the images have been > fully downloaded/cached. On my slow connection, image-downloads > frequently timeout, and refreshing doesn't retry to get them :'(. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 22, 2010

Refreshing pages with incomplete images

by dennisn＠dennisn.dyndns.org

Currently refreshing a page only redownloads the text portion (I believe) and not the images, which is perfect IF the images have been fully downloaded/cached. On my slow connection, image-downloads frequently timeout, and refreshing doesn't retry to get them :'(.

Sept. 22, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Tue, Sep 21, 2010 at 01:39:47PM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote: > > On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote: > > > On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > > > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > Please test attached patch. It is a bit more involved than I had > > > > > > hoped, but it seems necessary after looking at the spec. > > > > > > > > > > en.wikipedia (with remote css off) gives me > > > > > "** WARNING **: No background color found!" msgs. > > > > > > > > > > > > > Yes, I think this is because I had to remove the > > > > background-color property from the user-agent style in css.cc. > > > > It's a bit weird: > > > > The spec says, that the canvas color should either be the background color > > > > assigned to the <html> tag, or if that has no background color, it > > > > should be the background color of the <body> tag. > > > > So we can't no longer set a background color in the user-agent > > > > style. > > > > If we assign it to the <html> tag, we will see a weird frame if page > > > > authors set a background-color on the <body> tag. > > > > If we assign it to the <body> tag, pages that set the > > > > background-color for the <html> tag will have a frame. > > > > > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > > > background-color if the page has no background-color on neither the > > > > <html> nor the <body> tag. > > > > Opinions? > > > > > > Can't we set both <html> and <body> ? > > > > Unfortunately no. > > If we do that and the page sets background-color for body, we would > > have a frame with our background-color and a box (for <body>) with > > the background-color defined in the page. > > Also if the page sets a background-color for <html>, we have a frame > > with the pages background-color and a box with our color. > > I see... > > IMHO, having just one place for setting the appearance is an > important asset (simplicity/orthogonality). > > If we can keep this feature without introducing an ugly hack > I'd go for it. Now, as you know much better the implementation > details, I leave it for you to decide. I fully agree, but currently I don't see any way to set the background color from the user-agent-, or user-stylesheet such that it works for pages that set background-color on the <html> element and for pages that set background-color on the <body> element. I will prepare the patch and sleep some nights over it. Then we can decide whether we commit it. Cheers, Johannes

Sept. 22, 2010

[bug]: ignored CSS attributes on html element

by jcid＠dillo.org

On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote: > On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote: > > On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > > Johannes wrote: > > > > > Please test attached patch. It is a bit more involved than I had > > > > > hoped, but it seems necessary after looking at the spec. > > > > > > > > en.wikipedia (with remote css off) gives me > > > > "** WARNING **: No background color found!" msgs. > > > > > > > > > > Yes, I think this is because I had to remove the > > > background-color property from the user-agent style in css.cc. > > > It's a bit weird: > > > The spec says, that the canvas color should either be the background color > > > assigned to the <html> tag, or if that has no background color, it > > > should be the background color of the <body> tag. > > > So we can't no longer set a background color in the user-agent > > > style. > > > If we assign it to the <html> tag, we will see a weird frame if page > > > authors set a background-color on the <body> tag. > > > If we assign it to the <body> tag, pages that set the > > > background-color for the <html> tag will have a frame. > > > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > > background-color if the page has no background-color on neither the > > > <html> nor the <body> tag. > > > Opinions? > > > > Can't we set both <html> and <body> ? > > Unfortunately no. > If we do that and the page sets background-color for body, we would > have a frame with our background-color and a box (for <body>) with > the background-color defined in the page. > Also if the page sets a background-color for <html>, we have a frame > with the pages background-color and a box with our color. I see... IMHO, having just one place for setting the appearance is an important asset (simplicity/orthogonality). If we can keep this feature without introducing an ugly hack I'd go for it. Now, as you know much better the implementation details, I leave it for you to decide. -- Cheers Jorge.-

Sept. 21, 2010

patch: clearer msg when something can't be displayed as an image

by corvid＠lavabit.com

I'm sure that our usual HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" sort of msg is confusing to users in a "What? Dillo doesn't understand that character set?" sort of way when an img src attr is supposed to be modified by javascript or something.

Sept. 21, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote: > On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > Johannes wrote: > > > > Please test attached patch. It is a bit more involved than I had > > > > hoped, but it seems necessary after looking at the spec. > > > > > > en.wikipedia (with remote css off) gives me > > > "** WARNING **: No background color found!" msgs. > > > > > > > Yes, I think this is because I had to remove the > > background-color property from the user-agent style in css.cc. > > It's a bit weird: > > The spec says, that the canvas color should either be the background color > > assigned to the <html> tag, or if that has no background color, it > > should be the background color of the <body> tag. > > So we can't no longer set a background color in the user-agent > > style. > > If we assign it to the <html> tag, we will see a weird frame if page > > authors set a background-color on the <body> tag. > > If we assign it to the <body> tag, pages that set the > > background-color for the <html> tag will have a frame. > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > background-color if the page has no background-color on neither the > > <html> nor the <body> tag. > > Opinions? > > Can't we set both <html> and <body> ? Unfortunately no. If we do that and the page sets background-color for body, we would have a frame with our background-color and a box (for <body>) with the background-color defined in the page. Also if the page sets a background-color for <html>, we have a frame with the pages background-color and a box with our color. Cheers, Johannes

Sept. 19, 2010

[bug]: segfault from CSS patch + table + drag and drop

by Johannes.Hofmann＠gmx.de

On Sun, Sep 19, 2010 at 03:36:18PM +0100, Jeremy Henty wrote: > > There is unfortunately a severe problem with the CSS patch that was > posted recently (the one that fixed the handling of CSS properties on > the HTML element). It makes Dillo segfault when you drag the cursor > across the text in a table cell. Test HTML and a gdb backtrace are > attached. You can see that dw::fltk::FltkViewBase::drawRectangle() is > called with a NULL color. That is probabely because I had to remove the background-color definition from the user-agent style (see the other mail regarding reintroduction of bg_color in dillorc). This should be fixed once we add bg_color or find another solution. Cheers, Johannes

Sept. 19, 2010

[bug]: segfault from CSS patch + table + drag and drop

by onepoint＠starurchin.org

There is unfortunately a severe problem with the CSS patch that was posted recently (the one that fixed the handling of CSS properties on the HTML element). It makes Dillo segfault when you drag the cursor across the text in a table cell. Test HTML and a gdb backtrace are attached. You can see that dw::fltk::FltkViewBase::drawRectangle() is called with a NULL color. I haven't determined exactly which circumstances trigger the problem - text in <p>s and <li>s appears to be OK, but text in a <td> reliably segfaults. Any suggestions as to other elements that I could test? (NB: I compile Dillo with -O0, your backtrace may look a bit different if you use a different optimisation level. Also, I always run Dillo from valgrind.) Regards, Jeremy Henty

Sept. 19, 2010

[bug]: ignored CSS attributes on html element

by jcid＠dillo.org

On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > Johannes wrote: > > > Please test attached patch. It is a bit more involved than I had > > > hoped, but it seems necessary after looking at the spec. > > > > en.wikipedia (with remote css off) gives me > > "** WARNING **: No background color found!" msgs. > > > > Yes, I think this is because I had to remove the > background-color property from the user-agent style in css.cc. > It's a bit weird: > The spec says, that the canvas color should either be the background color > assigned to the <html> tag, or if that has no background color, it > should be the background color of the <body> tag. > So we can't no longer set a background color in the user-agent > style. > If we assign it to the <html> tag, we will see a weird frame if page > authors set a background-color on the <body> tag. > If we assign it to the <body> tag, pages that set the > background-color for the <html> tag will have a frame. > > So maybe we need to reintroduce the bg_color dillorc option to set a > background-color if the page has no background-color on neither the > <html> nor the <body> tag. > Opinions? Can't we set both <html> and <body> ? -- Cheers Jorge.-

Sept. 19, 2010