- Dillo-dev - lists.mailman3.com

a couple of patches: referer and image_off

by place＠gobigwest.com

Jorge wrote: > On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > > In brief, using the same URI, the three options offer good > > > privacy (because no new information is sent), and if we ever > > > enable using the referring page, the old comments apply. > > > > Whew. > > > > See, I ran on the equivalent of "host" for > > at least a year, and then have been using the > > equivalent of "path" for at least a year, so > > the idea that I had somehow been doing something > > wrong was alarming :) > > :-) > > Well, in that case you can provide good advice on which is > better as a default. Well, I tried "path" one day when "host" didn't work for some site, and I had the impression that "path" worked more consistently, but I wasn't being very scientific about it. Nowadays, if I bother to look at why an image doesn't want to load, it usually turns out that it was a redirection. I'd been sort of curious why dillo doesn't follow redirections for non-root urls, but hadn't gotten around to asking...

Feb. 2, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > In brief, using the same URI, the three options offer good > > privacy (because no new information is sent), and if we ever > > enable using the referring page, the old comments apply. > > Whew. > > See, I ran on the equivalent of "host" for > at least a year, and then have been using the > equivalent of "path" for at least a year, so > the idea that I had somehow been doing something > wrong was alarming :) :-) Well, in that case you can provide good advice on which is better as a default. -- Cheers Jorge.-

Feb. 1, 2008

Re: patch: cookies string leak

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote: > Also, what would you think of me either > > - stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url) OK. Basically the same way referer is handled. > or > - adding a function to http.c to accomplish the same thing? > ...with a_Cookies_get() changed to show a distinction between > don't-want-cookies and don't-have-cookies. > > I almost never have any cookies enabled, so I'd prefer not to send > the Cookie2 header all of the time when I don't want their cookies. No problem. Leak patch committed. -- Cheers Jorge.-

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by jcid＠dillo.org

Hi, On Fri, Feb 01, 2008 at 07:49:43PM +0000, Jeremy Henty wrote: > On Fri, Feb 01, 2008 at 03:15:13PM -0300, Jorge Arellano Cid wrote: > > On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote: > > > > > > (BTW, I still think there is a case for reworking Dillo's ROWSPAN > > > algorithms along the lines I suggested, but it's nice to fix bugs > > > without such efforts.) > > > > If you want to go further, please keep in the O(n) realm. > > I will. It is easy to calculate the minimum cumulative depths of the > rows in a single pass over the cells, treating all ROWSPAN values in > the same way. (In fact it needs only a small modification to the > current code: my previous patch was so ridiculously over-engineered > that I'm quite embarrassed by it.) The problem is that if you use > those depths then you squash everything up to the top, so that when a > cell spans several rows all the extra space goes into the bottom row. > That might be mathematically correct but it will look just plain > wrong. > > It is easy to do a second pass from the bottom-up to find the > *maximum* cumulative depths (subject to the total height of the table > being minimal); the challenge is to find a way to average those two > sets of values that (a) does something sensible in all cases, (b) does > the obvious right thing in simple cases, ie. if one cell spans n rows > then any spare space is distributed evenly between those rows, and (c) > takes O(n). I think I can do it, but haven't yet coded it. The "obvious right thing" may vary. For instance, what the algorithm currently does is to proportionally apportion the extra space (just as Firefox). e.g. <table border=1> <tr> <td rowspan=3> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 <td>A <tr><td>A B <tr> <td>A B C </tr> </table> Although most probably you're thinking of a more complex case. -- Cheers Jorge.-

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by onepoint＠starurchin.org

On Fri, Feb 01, 2008 at 03:15:13PM -0300, Jorge Arellano Cid wrote: > On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote: > > > > (BTW, I still think there is a case for reworking Dillo's ROWSPAN > > algorithms along the lines I suggested, but it's nice to fix bugs > > without such efforts.) > > If you want to go further, please keep in the O(n) realm. I will. It is easy to calculate the minimum cumulative depths of the rows in a single pass over the cells, treating all ROWSPAN values in the same way. (In fact it needs only a small modification to the current code: my previous patch was so ridiculously over-engineered that I'm quite embarrassed by it.) The problem is that if you use those depths then you squash everything up to the top, so that when a cell spans several rows all the extra space goes into the bottom row. That might be mathematically correct but it will look just plain wrong. It is easy to do a second pass from the bottom-up to find the *maximum* cumulative depths (subject to the total height of the table being minimal); the challenge is to find a way to average those two sets of values that (a) does something sensible in all cases, (b) does the obvious right thing in simple cases, ie. if one cell spans n rows then any spare space is distributed evenly between those rows, and (c) takes O(n). I think I can do it, but haven't yet coded it. Regards, Jeremy Henty

Feb. 1, 2008

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hello, let's get more agressive regarding these excessive redraws :-) Below are two patches. The first one adds a own run method to FltkPlatform. It is pretty similar to what fltk delivers, but this way we can tweak it as we like. Especially when to call our idle functions. The other patch changes resizeIdle() a bit. As stated in the comments, resizeIdle() can queue a new resizeIdle(). So instead of drawing the preliminary layout, then change it and redraw again, we now wait until the layout is settled and then draw it. Please note, that the provided run method was tuned for my computer, so it may need other values on slower/faster machines. Play around with other strategies! Johannes diff --git a/dw/fltkplatform.cc b/dw/fltkplatform.cc --- a/dw/fltkplatform.cc +++ b/dw/fltkplatform.cc @@ -25,6 +25,7 @@ #include <fltk/draw.h> #include <fltk/run.h> #include <fltk/events.h> +#include <fltk/Window.h> #include <stdio.h> namespace dw { @@ -185,6 +186,9 @@ container::typed::HashTable <dw::core::s new container::typed::HashTable <dw::core::style::ColorAttrs, dw::core::style::Color> (false, false); +container::typed::List <FltkPlatform> *FltkPlatform::idlePlatforms = + new container::typed::List <FltkPlatform> (0); + FltkPlatform::FltkPlatform () { layout = NULL; @@ -200,8 +204,7 @@ FltkPlatform::FltkPlatform () FltkPlatform::~FltkPlatform () { - if(idleFuncRunning) - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef(this); delete idleQueue; } @@ -241,11 +244,6 @@ int FltkPlatform::textWidth (core::style FltkFont *ff = (FltkFont*) font; setfont (ff->font, ff->size); return (int) getwidth (text, len); -} - -void FltkPlatform::generalStaticIdle (void *data) -{ - ((FltkPlatform*)data)->generalIdle(); } void FltkPlatform::generalIdle () @@ -263,7 +261,7 @@ void FltkPlatform::generalIdle () if(idleQueue->isEmpty()) { idleFuncRunning = false; - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef (this); } } @@ -277,8 +275,9 @@ int FltkPlatform::addIdle (void (core::L * idle function, the passed idle function is put into a queue. */ if(!idleFuncRunning) { - add_idle (generalStaticIdle, (void*)this); idleFuncRunning = true; + idlePlatforms->removeRef (this); + idlePlatforms->append (this); } idleFuncId++; @@ -306,7 +305,7 @@ void FltkPlatform::removeIdle (int idleI } if(idleFuncRunning && idleQueue->isEmpty()) - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef (this); } @@ -409,5 +408,30 @@ void FltkPlatform::detachResource (ui::F resources->removeRef (resource); } + +int FltkPlatform::run () { + int skipped = 0; + + while (::fltk::Window::first()) { + int r = fltk::wait (0.01); + + if (r == 0 || skipped >= 50) { + skipped = 0; + + for (container::typed::Iterator <FltkPlatform> it = idlePlatforms->iterator (); + it.hasNext (); ) { + FltkPlatform *p = it.getNext (); + + p->generalIdle (); + } + + } else { + skipped++; + } + } + + return 0; +} + } // namespace fltk } // namespace dw diff --git a/dw/fltkplatform.hh b/dw/fltkplatform.hh --- a/dw/fltkplatform.hh +++ b/dw/fltkplatform.hh @@ -94,7 +94,7 @@ private: bool idleFuncRunning; int idleFuncId; - static void generalStaticIdle(void *data); + static container::typed::List <FltkPlatform> *idlePlatforms; void generalIdle(); container::typed::List <FltkView> *views; @@ -163,6 +163,8 @@ public: void attachResource (ui::FltkResource *resource); void detachResource (ui::FltkResource *resource); + + static int run(); }; } // namespace fltk diff --git a/config.h.in b/config.h.in diff --git a/src/dillo.cc b/src/dillo.cc --- a/src/dillo.cc +++ b/src/dillo.cc @@ -23,6 +23,8 @@ #include <fltk/Window.h> #include <fltk/run.h> + +#include "dw/fltkcore.hh" #include "dir.h" #include "uicmd.hh" @@ -103,5 +105,5 @@ int main(int argc, char **argv) a_Nav_push(bw, prefs.start_page); } - return fltk::run(); + return dw::fltk::FltkPlatform::run(); } diff --git a/dw/layout.cc b/dw/layout.cc --- a/dw/layout.cc +++ b/dw/layout.cc @@ -520,58 +520,61 @@ void Layout::updateBgColor () void Layout::resizeIdle () { - // Reset already here, since in this function, queueResize() may be - // called again. - resizeIdleId = -1; - - if (topLevel) { - Requisition requisition; - Allocation allocation; - - topLevel->sizeRequest (&requisition); - - allocation.x = allocation.y = 0; - allocation.width = requisition.width; - allocation.ascent = requisition.ascent; - allocation.descent = requisition.descent; - topLevel->sizeAllocate (&allocation); - - canvasWidth = requisition.width; - canvasAscent = requisition.ascent; - canvasDescent = requisition.descent; - emitter.emitCanvasSizeChanged (canvasWidth, canvasAscent, canvasDescent); + while (resizeIdleId != -1) { + // Reset already here, since in this function, queueResize() may be + // called again. + resizeIdleId = -1; - // Tell the views about the new world size. - for (typed::Iterator <View> it = views->iterator (); it.hasNext (); ) { - View *view = it.getNext (); - view->setCanvasSize (canvasWidth, canvasAscent, canvasDescent); - view->queueDrawTotal (); - } + if (topLevel) { + Requisition requisition; + Allocation allocation; - if (usesViewport) { - int actualHScrollbarThickness = - (canvasWidth > viewportWidth) ? hScrollbarThickness : 0; - int actualVScrollbarThickness = + topLevel->sizeRequest (&requisition); + + allocation.x = allocation.y = 0; + allocation.width = requisition.width; + allocation.ascent = requisition.ascent; + allocation.descent = requisition.descent; + topLevel->sizeAllocate (&allocation); + + canvasWidth = requisition.width; + canvasAscent = requisition.ascent; + canvasDescent = requisition.descent; + + emitter.emitCanvasSizeChanged (canvasWidth, canvasAscent, canvasDescent); + + // Tell the views about the new world size. + for (typed::Iterator <View> it = views->iterator (); it.hasNext (); ) { + View *view = it.getNext (); + view->setCanvasSize (canvasWidth, canvasAscent, canvasDescent); + view->queueDrawTotal (); + } + + if (usesViewport) { + int actualHScrollbarThickness = + (canvasWidth > viewportWidth) ? hScrollbarThickness : 0; + int actualVScrollbarThickness = (canvasAscent + canvasDescent > viewportWidth) ? vScrollbarThickness : 0; - - if (!canvasHeightGreater && - canvasAscent + canvasDescent - > viewportHeight - actualHScrollbarThickness) { - canvasHeightGreater = true; - setSizeHints (); - /* May queue a new resize. */ - } - // Set viewport sizes. - for (typed::Iterator <View> it = views->iterator (); - it.hasNext (); ) { - View *view = it.getNext (); - if (view->usesViewport ()) - view->setViewportSize (viewportWidth, viewportHeight, - actualHScrollbarThickness, - actualVScrollbarThickness); + if (!canvasHeightGreater && + canvasAscent + canvasDescent + > viewportHeight - actualHScrollbarThickness) { + canvasHeightGreater = true; + setSizeHints (); + /* May queue a new resize. */ + } + + // Set viewport sizes. + for (typed::Iterator <View> it = views->iterator (); + it.hasNext (); ) { + View *view = it.getNext (); + if (view->usesViewport ()) + view->setViewportSize (viewportWidth, viewportHeight, + actualHScrollbarThickness, + actualVScrollbarThickness); + } } }

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote: > > OK, please ignore my previous attempt at reworking Dillo's ROWSPAN > handling. I have a simple fix for the bugs I reported at > http://starurchin.singularity/dillo/bugs/table_rowspan.html . This > patch tweaks dw::Table::apportionRowSpan() to handle the special case > where all the rows being spanned have zero height. This fixes the > special cases that were breaking without changing the behaviour in any > other case. Committed. > (BTW, I still think there is a case for reworking Dillo's ROWSPAN > algorithms along the lines I suggested, but it's nice to fix bugs > without such efforts.) If you want to go further, please keep in the O(n) realm. -- Cheers Jorge.-

Feb. 1, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 12:39:41AM +0000, place wrote: > Jorge wrote: > > >From the updated dillorc2: > > > > # Set the HTTP Referer information (WARNING: affects privacy) > > * # We use the same URI, not the refering page (to avoid cross-site tracking). > > # none : No referer at all (full privacy). > > # host : Default value. Send same URI's hostname (no sensible info is sent). > > # path : same URI is sent (NO PRIVACY). > > http_referer=host > > What do you mean by "NO PRIVACY"? I meant that if we send the referring page's path, there would be no privacy. Later I changed the referer approach by using the same URI, which worked surprisingly well on tests, and this new approach obsoleted the comments. Note that "path" is not sending the same URI, it strips the query and fragment parts. In brief, using the same URI, the three options offer good privacy (because no new information is sent), and if we ever enable using the referring page, the old comments apply. i.e. Using Same URI: # none : No referer at all (nothing is sent) # host : Default value. Send same URI's hostname (no new info is sent). # path : same URI is sent (no new info is sent). Using referring page (not implemented): # none : No referer at all (nothing is sent) # host : Default value. Send URI's hostname (referring hostname is known). # path : referring URI is sent (NO PRIVACY, fine grained tracking # of the pages/sites you visit). Using referring page only if hostname matches (not implemented): # none : No referer at all (nothing is sent) # host : Default value. Send URI's hostname (no new info is sent). # path : referring URI is sent (NO PRIVACY, fine-grained per-site # tracking of the pages you visit). I'll fix the comments (of implemented part) upon finishing this thread. Thanks for the question. -- Cheers Jorge.-

Feb. 1, 2008

patch: [Dillo-dev] a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 01:50:35AM +0000, place wrote: > linebreaks... Ooops!, committed. -- Cheers Jorge.-

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by onepoint＠starurchin.org

OK, please ignore my previous attempt at reworking Dillo's ROWSPAN handling. I have a simple fix for the bugs I reported at http://starurchin.singularity/dillo/bugs/table_rowspan.html . This patch tweaks dw::Table::apportionRowSpan() to handle the special case where all the rows being spanned have zero height. This fixes the special cases that were breaking without changing the behaviour in any other case. (BTW, I still think there is a case for reworking Dillo's ROWSPAN algorithms along the lines I suggested, but it's nice to fix bugs without such efforts.) Regards, Jeremy Henty

Feb. 1, 2008