hi karen.
In order to produce the best usable results as I have never runt trace, at
what point should I run the test?
i would imagine that the most revealing messages would be logged
between the submission of the form and the subsequent loading of the
undesired page.
so, in lynx, i would do the following:
1. go to the page with forms, whose submission results in unexpected
behavior.
2. fill in the forms.
3. toggle trace mode on.
4. submit the form.
5. wait for lynx to perform the unexpected behavior.
6. toggle trace mode off.
on my installation, '<control>-t' toggles trace mode (ie, it is both
the on and off switch for trace mode). on yours, try viewing the
'current key map' page ('<shift>-k', maybe) and search for
TRACE_TOGGLE. note also that you will most likely need to move the
cursor off of any text input fields to toggle trace mode.
in a lynx session with a trace log, you can view that session's trace
log with the TRACE_LOG command (often mapped to ';'). you may find
that it is the file Lynx.trace in your home directory.
i find that if i begin new lynx session and toggle trace on, it
clobbers/overwrites any older Lynx.trace file. so when you get an
interesting trace and want to save it for posterity, i recommend
moving it someplace else or otherwise renaming it.
cheers,
wes
On Sun, 3 Mar 2013, Karen Lewellen wrote:
Hi Stef,
fine suggestion.
In order to produce the best usable results as I have never runt trace, at
what point should I run the test?
as in, should I run the trace command then go through the steps producing
the error, or runt trace while in lynx after the error happens?
Thanks again,
Karen
On Sun, 3 Mar 2013, Stefan Caunter wrote:
> Look at a trace file
>
> lynx -trace
>
> Send it if answer is not obvious from examination
>
> ---
> Stef
<snip>
_______________________________________________
Lynx-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lynx-dev