- Dillo-dev - lists.mailman3.com

empty html elements

by Johannes.Hofmann＠gmx.de

Hi, while working on css I came across the following: <a class="d" name="INCR32"/> (found at [1]) dillo currently doesn't recognize that the element is empty. The relevant code is at html.cc:3530: /* Test for </x>, ReqTagClose, <x /> and <x/> */ if (*start == '/' || /* </x> */ html->ReqTagClose || /* request */ (tag[tagsize - 2] == '/' && /* XML: */ (isspace(tag[tagsize - 3]) || /* <x /> */ (size_t)tagsize == strlen(Tags[ni].name) + 3))) { /* <x/> */ We could simply drop the requirement for the blank before '/' which would lead to /* Test for </x>, ReqTagClose, <x /> and <x/> */ if (*start == '/' || /* </x> */ html->ReqTagClose || /* request */ (tag[tagsize - 2] == '/')) { /* XML */ or allow a '"' instead of the blank or keep things as they are, if XML requires a blank before the '/'. >From http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags I'd say the blank is optional. What do you think? Cheers, Johannes [1] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port…

Dec. 1, 2008

Re: patch: middle-click submits in new window/tab

by corvid＠lavabit.com

Jorge wrote: > On Fri, Nov 28, 2008 at 10:08:21PM +0000, corvid wrote: > > > Now if I go to: > > > > > > http://www.dillo.org/bugtrack/Dremove.html > > > > > > and fill the entries with the keyboard, then TAB to the submit > > > button and press ENTER, nothing happens. > > > > > > Doing the same, with the unpatched version, works OK here... > > > > Here's one with the widgetCallback stuff changed in fltkui.cc > > > > Middle click submits in new tab was committed! > > With this minor changes: > > * A compiler warning fix > * An event_key() test instead of event_button() because the > latter may return garbage. It may be safer. events.h show both of them returning e_keysym -- although, given the changes you made in fltkui.cc, it does naturally make sense to use event_key. > BTW, now it submits with Enter but not with Space. Yes, I'd noticed that the buttons were written to make Space submit, which surprised me a bit. Also, I saw that you can hold down Enter and have the key repeat submitsubmitsubmitsubmit.... Perhaps it would be good to change complex button's handle() from KEY to KEYUP (and try to talk the FLTKers into a similar change for Button).

Nov. 30, 2008

Re: patch: middle-click submits in new window/tab

by jcid＠dillo.org

On Fri, Nov 28, 2008 at 10:08:21PM +0000, corvid wrote: > > Now if I go to: > > > > http://www.dillo.org/bugtrack/Dremove.html > > > > and fill the entries with the keyboard, then TAB to the submit > > button and press ENTER, nothing happens. > > > > Doing the same, with the unpatched version, works OK here... > > Here's one with the widgetCallback stuff changed in fltkui.cc > Middle click submits in new tab was committed! With this minor changes: * A compiler warning fix * An event_key() test instead of event_button() because the latter may return garbage. It may be safer. BTW, now it submits with Enter but not with Space. -- Cheers Jorge.-

Nov. 30, 2008

Basic Authentication: what's happening here?

by onepoint＠starurchin.org

On Fri, Nov 28, 2008 at 06:51:48AM +0000, corvid wrote: > Jeremy wrote: > > ... if I show the dialog from inside Cache_process_queue() just > > before it iterates over the clients then something *still* runs > > asynchronously while the dialog is up, ... What now? > > I don't know CCC either. > I wonder whether the original patch gave that warning with 0.8.x. The original patch was slightly different in that the dialog was part of the bw structure. Rather than port that approach I decided to go the way suggested by the earlier discussion between Jorge and Christian. Anyway, here's a version that seems to work. It defers both the dialog and the reload to a timeout. Unfortunately we no longer have a reference to the browser window so it calls a new function a_Nav_reload_url() that reloads all browsers displaying the URL. It removes CA_Reload and bw->reload_level since they're now unnecessary. It's actually quite straightforward, the only clunkiness is using the timeout and a_Nav_reload_url(), but that seems to be necessary. Now I just have do the actual authentication. Regards, Jeremy Henty

Nov. 28, 2008

Basic Authentication: what's happening here?

by corvid＠lavabit.com

Jeremy wrote: > On Fri, Nov 28, 2008 at 01:30:05AM +0000, corvid wrote: > > Jeremy wrote: > > > Is there any way to stop this happening, or do I have to postpone > > > showing the dialog until Cache_process_queue() runs? > > > > Postponing it sounds right to me. > > Unfortunately, if I show the dialog from inside Cache_process_queue() > just before it iterates over the clients then something *still* runs > asynchronously while the dialog is up, which gets me a warning from > the CCC about a call on a finished chain, followed by a segfault when > I confirm the dialog and reload the browser window. If I delay the > reload even further by doing it from inside a timeout then I still get > the warning, but not the segfault. (Amended patch attached.) I don't > understand the CCC well enough to know what I should be doing here. > What now? I don't know CCC either. I wonder whether the original patch gave that warning with 0.8.x. > When I was doing this from a DPI it all happened asynchronously and I > ended up writing a a_Nav_reload_url() that reloaded all the browsers > for a gicen URL. I thought that was pretty hacky but maybe it's the > only way to make this work?

Nov. 28, 2008

Basic Authentication: what's happening here?

by onepoint＠starurchin.org

On Fri, Nov 28, 2008 at 01:30:05AM +0000, corvid wrote: > Jeremy wrote: > > Is there any way to stop this happening, or do I have to postpone > > showing the dialog until Cache_process_queue() runs? > > Postponing it sounds right to me. Unfortunately, if I show the dialog from inside Cache_process_queue() just before it iterates over the clients then something *still* runs asynchronously while the dialog is up, which gets me a warning from the CCC about a call on a finished chain, followed by a segfault when I confirm the dialog and reload the browser window. If I delay the reload even further by doing it from inside a timeout then I still get the warning, but not the segfault. (Amended patch attached.) I don't understand the CCC well enough to know what I should be doing here. What now? When I was doing this from a DPI it all happened asynchronously and I ended up writing a a_Nav_reload_url() that reloaded all the browsers for a gicen URL. I thought that was pretty hacky but maybe it's the only way to make this work? Regards, Jeremy Henty

Nov. 28, 2008

Basic Authentication: what's happening here?

by corvid＠lavabit.com

Jeremy wrote: > OK, after reviewing the links people sent in (thanks!) and the > discussion at [1] I decided not to create a DPI. > > I've hit a strange problem with getting the page to reload after the > user confirms the user/password dialog. I show the dialog in > Cache_parse_header() by calling fltk::Window::exec() and set a new > CA_Reload flag (which is just like CA_Redirect, but simpler) if the > user confirms. Cache_process_queue() then handles the CA_Reload. > *But* Cache_process_queue() runs before the window is closed, and > therefore before the flag is set. It looks as though the rest of the > data comes in asynchronously while the dialog is still showing. If I > change a_Auth_do_auth() to return immediately instead of showing a > dialog then Cache_process_queue() runs after the flag is set, as I > would expect. > > Is there any way to stop this happening, or do I have to postpone > showing the dialog until Cache_process_queue() runs? Postponing it sounds right to me.

Nov. 28, 2008

Basic Authentication: what's happening here?

by onepoint＠starurchin.org

OK, after reviewing the links people sent in (thanks!) and the discussion at [1] I decided not to create a DPI. I've hit a strange problem with getting the page to reload after the user confirms the user/password dialog. I show the dialog in Cache_parse_header() by calling fltk::Window::exec() and set a new CA_Reload flag (which is just like CA_Redirect, but simpler) if the user confirms. Cache_process_queue() then handles the CA_Reload. *But* Cache_process_queue() runs before the window is closed, and therefore before the flag is set. It looks as though the rest of the data comes in asynchronously while the dialog is still showing. If I change a_Auth_do_auth() to return immediately instead of showing a dialog then Cache_process_queue() runs after the flag is set, as I would expect. Is there any way to stop this happening, or do I have to postpone showing the dialog until Cache_process_queue() runs? Patch attached if you wish to experiment (it doesn't do authentication but it demonstrates the problem with the dialog). Regards, Jeremy Henty [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005023.html

Nov. 28, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

On Wed, Nov 26, 2008 at 06:39:56AM +0900, furaisanjin wrote: > This page (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz.html) > contains the original BASIC auth path Thanks, that's very useful. Jeremy Henty

Nov. 27, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by furaisanjin＠gmail.com

Hi, This page (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz.html) contains the original BASIC auth path (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz-auth.diff.gz) i18n patch contains lots of small patches there and it's not easy to pick up one of them. Regards, furaisanjin

Nov. 25, 2008