Hi, More or less we entered "feature freeze" mode implicitly. What is left pending? I remember: - the mini_bug.xpm FLTK2 fix. - the focused textarea callback issue. -- Cheers Jorge.-
Jorge wrote:
More or less we entered "feature freeze" mode implicitly.
What is left pending?
I remember:
- the mini_bug.xpm FLTK2 fix. - the focused textarea callback issue.
My alt-X crash in the menu. I guess I'll look into giving it a timeout. I think the 128 tabs and some other hardcoded 128 in there that Johannes found are still there. My leaving-the-window nav_expecting problem would be nice if possible.
On Thu, Oct 02, 2008 at 05:44:32PM +0000, corvid wrote:
Jorge wrote:
More or less we entered "feature freeze" mode implicitly.
What is left pending?
I remember:
- the mini_bug.xpm FLTK2 fix. - the focused textarea callback issue.
My alt-X crash in the menu. I guess I'll look into giving it a timeout.
I think the 128 tabs and some other hardcoded 128 in there that Johannes found are still there.
My leaving-the-window nav_expecting problem would be nice if possible.
OK, so we have: 1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. Status: 1: There's a simple workaround. 2: Waiting for comment from Johannes. 3: There's a simple workaround. Valgrind may shed some light... 4: We may ship with dillo-hardcoded maxtabs. Right? 5: Doesn't happen with XFCE... Will test icewm and fvwm. BTW, I noticed the nice new screnshots. Good! From a purely aesthetic point of view, why are WM decorations left out? -- Cheers Jorge.-
On Thu, Oct 02, 2008 at 02:01:35PM -0400, Jorge Arellano Cid wrote:
On Thu, Oct 02, 2008 at 05:44:32PM +0000, corvid wrote:
Jorge wrote:
More or less we entered "feature freeze" mode implicitly.
What is left pending?
I remember:
- the mini_bug.xpm FLTK2 fix. - the focused textarea callback issue.
My alt-X crash in the menu. I guess I'll look into giving it a timeout.
I think the 128 tabs and some other hardcoded 128 in there that Johannes found are still there.
My leaving-the-window nav_expecting problem would be nice if possible.
OK, so we have:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem.
6.- redraw storms related to the MenuTabPager (noticed by Jeremy)
Status:
1: There's a simple workaround. 2: Waiting for comment from Johannes. 3: There's a simple workaround. Valgrind may shed some light... 4: We may ship with dillo-hardcoded maxtabs. Right? 5: Doesn't happen with XFCE... Will test icewm and fvwm.
6: Using the ShrinkTabPager avoids the problem Cheers, Johannes
On Thu, Oct 02, 2008 at 08:01:58PM +0200, Johannes Hofmann wrote:
6.- redraw storms related to the MenuTabPager (noticed by Jeremy) [...] 6: Using the ShrinkTabPager avoids the problem
Here's a (tiny) patch to use the ShrinkTabPager . Personally I find dillo almost unusable without it, but that may be because I like to open lots of tabs. Regards, Jeremy Henty
On Thu, Oct 02, 2008 at 10:18:42PM +0100, Jeremy Henty wrote:
On Thu, Oct 02, 2008 at 08:01:58PM +0200, Johannes Hofmann wrote:
6.- redraw storms related to the MenuTabPager (noticed by Jeremy) [...] 6: Using the ShrinkTabPager avoids the problem
Here's a (tiny) patch to use the ShrinkTabPager.
Committed as workaround for redraw storms. -- Cheers Jorge.-
Jorge wrote:
OK, so we have:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem.
Status:
1: There's a simple workaround. 2: Waiting for comment from Johannes. 3: There's a simple workaround. Valgrind may shed some light...
We know the problem. No valgrind necessary. http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-September/004981.htm...
4: We may ship with dillo-hardcoded maxtabs. Right? 5: Doesn't happen with XFCE... Will test icewm and fvwm.
BTW, I noticed the nice new screnshots. Good! From a purely aesthetic point of view, why are WM decorations left out?
WM decorations: Unfortunate, yeah. I still use xwd. I don't know what people use nowadays. Probably something heavyweight.
On Thu, Oct 02, 2008 at 06:27:11PM +0000, corvid wrote:
Jorge wrote:
OK, so we have:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem.
Status:
1: There's a simple workaround. 2: Waiting for comment from Johannes. 3: There's a simple workaround. Valgrind may shed some light...
We know the problem. No valgrind necessary. http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-September/004981.htm...
4: We may ship with dillo-hardcoded maxtabs. Right? 5: Doesn't happen with XFCE... Will test icewm and fvwm.
BTW, I noticed the nice new screnshots. Good! From a purely aesthetic point of view, why are WM decorations left out?
WM decorations: Unfortunate, yeah. I still use xwd. I don't know what people use nowadays. Probably something heavyweight.
dwm (www.suckless.org) wc -l dwm.c 1742 dwm.c :-) Cheers, Johannes
On Thu, Oct 02, 2008 at 02:01:35PM -0400, Jorge Arellano Cid wrote:
OK, so we have:
Dillo won't let me login to Wikipedia! Of course this may be a *good* thing. :-) After making the MSG a little more verbose (patch attached) it reports that it is rejecting the HttpOnly attribute (log attached). I *think* this attribute is a security feature to avoid hacks that trick your browser into relaying cookie info from an http connection to an https connection. What should dillo do here? No matter what dillo should do, I think this diagnostics patch is good because it makes the MSG far more useful. Regards, Jeremy Henty
Jeremy Henty wrote:
Dillo won't let me login to Wikipedia! Of course this may be a *good* thing. :-) After making the MSG a little more verbose (patch attached) it reports that it is rejecting the HttpOnly attribute (log attached). I *think* this attribute is a security feature to avoid hacks that trick your browser into relaying cookie info from an http connection to an https connection. What should dillo do here?
The HttpOnly flag indicates that the cookie should only be passed via HTTP requests and not accessible by client-side scripts. The idea is to make cross-site scripting attacks harder by preventing an injected script from accessing a site's authentication tokens or other data stored in cookies. So long as Dillo doesn't have client-side scripting, the attribute can just be ignored. More info: http://msdn.microsoft.com/en-us/library/ms533046.aspx http://www.owasp.org/index.php/HTTPOnly The second link includes a table of current support in various browsers. -- Kelson Vibber Hyperborea.org - SpeedForce.org - AlternativeBrowserAlliance.com
On Thu, Oct 02, 2008 at 03:20:02PM -0700, Kelson Vibber wrote:
[snip: excellent summary of the purpose of the HttpOnly cookie attr]
So long as Dillo doesn't have client-side scripting, the attribute can just be ignored.
OK, patch attached. (NB: the patch context depends on my previous MSG-enhancing patch, but I think it will apply with a little fuzz even without it.) And now I must away to correct every Wikipedia update since I last logged in. I may be some time. :-) Regards, Jeremy Henty
On Thu, Oct 02, 2008 at 11:51:31PM +0100, Jeremy Henty wrote:
On Thu, Oct 02, 2008 at 03:20:02PM -0700, Kelson Vibber wrote:
[snip: excellent summary of the purpose of the HttpOnly cookie attr]
So long as Dillo doesn't have client-side scripting, the attribute can just be ignored.
OK, patch attached. (NB: the patch context depends on my previous MSG-enhancing patch, but I think it will apply with a little fuzz even without it.)
Committed as: - MSG("Cookie contains illegal attribute!\n"); + MSG("Cookie contains unknown attribute: '%s'\n", attr); -- Cheers Jorge.-
Kelson wrote:
So long as Dillo doesn't have client-side scripting, the attribute can just be ignored.
I was looking through the RFCs to see what the rule was regarding unknown attributes, and I was able to find in rfc2965, for Set-Cookie2: "The user agent MUST ignore attribute-value pairs whose attribute it does not recognize", and in rfc2109, "An 'old' client that receives a 'new' cookie will ignore attributes it does not understand..." So it does sound like dillo can ignore unknown attributes rather than regarding them as errors. PS The cookie RFCs do not seem very clearly written in general.
participants (5)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
kelson＠pobox.com -
onepoint＠starurchin.org