[elinks-users] www.bookshare.org - wrong submit link

Jonas Fonseca fonseca at diku.dk
Sun May 1 06:25:10 PDT 2005

Christopher Moore <w1gm at arrl.net> wrote Sat, Apr 30, 2005:
> Hello,
> I'm new to elinks and would like to help with some of the bug fixes and/or
> development.  
> When I go to www.bookshare.org and then  to the login link.  When I enter
> userid and password, the submit message brings up the wrong url and the
> login fails.
> The first form on the page is for a search query and the next form is for
> the login.  Elinks is trying the url of the search form instead of the
> login form.  
> As I mentioned previously, I'd be interested in tracking this down as a way
> of getting involved in elinks devel.  i would need some ideas as to what
> functions/date structures to look at.  

The problem was with the table parsing order and the form handling
order. These form handling bugs have been lurking since javascript was
introduced and the form code was reworked. The problem is how ELinks
associates form items (or controls) with forms.

Take the following table:

	| cell #0              | cell #1 with form #0 |
	| cell #2 with form #1 | cell #3              |

The table rendering will cause cell #0 and cell #2 to be parsed before
cell #1 and cell #3.

Form items are associated with forms by using their position in the HTML
source (that is the byte offset in the source). Which means that form
items in form #1 will have bigger offsets than items in form #0. Since
the <form>-tag always comes before any form items _and_ ELinks maintains
the position where the form end (this is either set to MAX_INT or the
start position - 1 of the following form) it is possible to associate
form items by checking if their position is within the position range of
a form.

[ I hope I didn't loose you there. ;) ]

Now to the bug. In an attempt to keep things simple the first added form
was set to always start at position zero regardless of where it actually
started. This was wrong because form #1 was thereby assumed to come
before form #0 which caused all the form items which should have been
associated with form #1 to be associated with form #0 instead.

A very stupid bug, but HTML engine is hairy.

The patch fixing the bug is here:


Jonas Fonseca

More information about the elinks-users mailing list