Re: LYNX-DEV the printing function and submit/image/reset buttons

[Laura Eaves]

> Date: Wed, 9 Apr 1997 18:28:02 -0500 (CDT)
> From: Klaus Weide <address@hidden>
> On Tue, 8 Apr 1997, Laura Eaves wrote:
>...
> > > Have you checked whether your code handles e.g. submit fields, possibly
> > > with a long value lable, adequately when within a PRE section... ?
> > 
> > I'm not sure what the code for HTML_PRE is trying to do...
> > It seems it indiscriminantly puts out 20 '_'s and subtracts this amount
> > from chars without checking the value of chars.  If chars is still > 0,
> > the subsequent code then puts out the "rest" of the '_'s in the field.
> > 
> > How should this apply to submit/reset button values?  Should I force them
> > to be a minimum of 20 chars?  Does that mean I should append '_'s if the
> > value if chars < 20?
> >
> > I guess I just chose to ignore HTML_PRE until I had more info...
> > What do you think?
>
> I haven't really tried to understand all that form related stuff;
> I was just mentioning some things that I thought of when I looked
> at your diffs (since you asked for comments :) ).
>
> But what I think is that you should probably test it, and see how it
> behaves in different situations.  Say an INPUT field within PRE which
> has text (given by VALUE attribute?) which is longert than 20
> characters...

For text input fields (which I didn't touch) the behavior should be the same
as before.  In that case, the value is ignored anyway and only the size is
used, since the value may be longer than the (visible) size.
(Actually I thought this code for PRE blocks looked wrong, since it puts out
20 '_'s even when teh size is smaller. WHen the size is > 20, it puts out
size '_'s.)

For submit/reset buttons, my chanage just puts out the value instead of
the '_'s.  If the value has length < 20, it doesn't add additional '_'s
to make it 20.  (Should it?)  If the value has length > 20, it just puts
out the whole value (instead of '_'s) -- same length.
Note: Looking thru HText_beginInput(), the size is set to length of value
for submit and reset buttons (not other input fields).  If value isn't
set, HText_beginInput() gives them defaults of Submit/Reset/[IMAGE]-Submit.
But the size of submit/reset is always length(value).

So, to me the only question is, "what shoould be done if the length of vlaue
is < 20 in a PRE blocks?"  Is the code right for input fiels in general?
If so, should I pad the value of submit/reset buttons with '_'s to make them
20 chars wide?  I'll have to test this.
There is no problem for value of length > 20.

> > > >             }
> > > > !           /*--LE*/
> > > > !           if ( !is_submit_or_reset ) {
> > > > !               for (; chars > 0; chars--)
> > > > !                   HTML_put_character(me, '_');
> > > > !           } else { int i;
> > > > !                 for ( i = 0;  i < chars;  ++i )
> > >                                   ^^^^^^^^^^
> > > > !                   HTML_put_character(me, I.value[i]);
> > > > !           }
> > > >             HText_setIgnoreExcess(me->text, FALSE);
> > > >         }
> > > >         break;
> > >
> > > You should probably test for end of string (a '\0' char) there,
> > > or explain why that is not necessary.
> > 
> > chars is returned from HText_beginInput and is the length
> > of the value.  I.value for submit buttons
> > is also processed in HText_beginInput and presumably is legal...
> > In any case, chars should be no longer than strlen(I.value).  So I don't 
> > think
> > there's a null in the first 'chars' chars of I.value.
>
> HText_beginInput() looks complicated enough that I wouldn't trust it to
> always do what I think it would do...  But maybe you understand it better,
> and/or have looked at it longer, or are just more brave :)
>
> Anyway I noticed that in all other places in HTML.c where the return value
> of HText_beginInput() is used, it is just used as a counter for generating
> sequences of '_' chars, not as a string length which is relied on.

As I mentioned, for submit/reset buttons, size (returned from
HText_beginInput()) is == length  of value.
Perhaps I should have put that in a comment...

> There is also the basic question: if it is as simple as your change seems
> to be, why hasn't it been done before?  Makes me think that there *may*
> be a good reason for it.  Maybe Fote can clarify.

Maybe other things were more pressing.
That's always the way it is with lynx.
When I reported this bug the first time I got the following response:

> From: "Hiram Lester, Jr." <address@hidden>
> Date: Wed, 26 Mar 1997 17:30:17 -0600 (CST)
>...
> Yes, this is just the way lynx works with buttons.  My understanding is
> that it makes two passes on forms.  For the first pass, it leaves ___ as a
> placeholder for the VALUE attribute to be filled in on the second pass.
> My understanding is that in order to get it to do it in a more sensible
> manner, the form handling code would basically have to be written from the
> ground up.

This description was helpful, but I take issue with the code not being
sensible the way it is...
Although this code is long and special-casy, and it took
a while to find what I was looking for, I actually think it's a reasonable
way to implement it.
As for submit and reset buggons,
they are different from other input fields in that their value doens't change.
So all that seemed to be needed was to write the value
instead of '_'s on the original buffer.
Is there a problem with this?
Other comments welcome...
(Unlike the parsing hack I sent for the form problem, this change
is much more local and I think safe.)

Thanks for your input.
--le
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;