Bug 679266 - Lynx doesn't include readonly text fields on form submission
Summary: Lynx doesn't include readonly text fields on form submission
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lynx
Version: 14
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-22 04:48 UTC by David Paschal
Modified: 2011-06-09 00:04 UTC (History)
2 users (show)

Fixed In Version: lynx-2.8.7-4.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-04 03:03:40 UTC


Attachments (Terms of Use)
create a local git repository containing -dev snapshots of lynx (1.19 KB, text/plain)
2011-05-27 09:27 UTC, Kamil Dudka
no flags Details
backport of the changes introduced in lynx2.8.8dev.8d (17.77 KB, patch)
2011-05-27 11:53 UTC, Kamil Dudka
no flags Details | Diff

Description David Paschal 2011-02-22 04:48:53 UTC
Description of problem:

See below for a detailed problem description (and patch to solve it) sent upstream to the "lynx-dev" mailing list.


Version-Release number of selected component (if applicable):

Found with lynx-2.8.7-3.fc13.i686, also presumably exists with the versions of Lynx provided with F14, Rawhide, etc.  I would encourage you to apply this patch to the versions of Lynx provided with F13, F14, F15(work in progress), and Rawhide, until such a time that an official fix is present in the upstream version.


How reproducible:

Always, when using a website that is affected by this issue, because it uses "readonly" text fields to store additional input that should be provided along with a submitted form.  Unfortunately, I don't have a URL for a public website that I can give to demonstrate this issue.  However, I can assure you that the patch below fixes the issue by reverting to Lynx's previous behavior, which itself wasn't 100% correct, since the "readonly" field wasn't treated as unmodifiable as it ideally should be, but was much less problematic than the current behavior.


Steps to Reproduce:
1. Use Lynx to access a website which expects "readonly" text fields to be included when submitting form data.
2. Submit a form.

  
Actual results:

Website complains of missing data which was present in the pre-form-submittal page.


Expected results:

With other web browsers (such as Firefox) and older versions of Lynx, as well as with my patched version of Lynx, website properly handles form submission because the "readonly" data it expects to receive is present in the submitted form.


Additional info:

Here is the e-mail I sent to the "lynx-dev" mailing list just now, which will hopefully show up eventually in the mailing-list archive for this month at "http://lists.gnu.org/archive/html/lynx-dev/2011-02/threads.html":


Hi.  Somewhere between Lynx versions 2.8.6 and 2.8.7 a change was made to assume that "readonly" text-entry fields on a webpage should get the "disabled" attribute applied in Lynx's internal representation of the page.  I suspect the intention behind this change was to ensure that the field was actually unmodifiable on the page, which it accomplishes successfully.  However, an unfortunate side effect of this change is that upon form-submission of a page, any "readonly" (and therefore disabled) text fields are omitted from the submitted data, causing problems with websites that expect the previous read-only data to be provided with the submitted form.  Other web browsers (Firefox, IE, Safari, Chrome, etc.) presumably pass the "readonly" data with the submitted form the way Lynx used to before this change was made, because otherwise such websites wouldn't work properly with those other browsers either.

After some digging, I located the two lines of code that were added between these two versions of Lynx that caused this problem to start happening.  Disabling these two lines (with "#if 0" in the patch below) causes the problem to go away, with the much lesser side effect that "readonly" text fields are now writeable as before, which in my mind is a much better problem to have than an error page on a website that expects "readonly" fields to be resubmitted along with a form.  I have been successfully using my own compiled copy of Lynx with this change for the past three months as a substitute for the precompiled version provided with Fedora 13, with no other adverse effects noted.  I would like to request that you apply this patch to the Lynx source tree for future releases.  Longer-term, perhaps somebody who is knowledgeable about the design of Lynx (since I'm not) could find a different way to implement the "readonly" functionality that is separate from the "disabled" functionality.

Since I'm not all that familiar with HTML and especially not with form submission, please pardon any incorrect terminology I may have used in this message.  :-)

Thanks,
David


--- lynx2-8-7.original/src/HTML.c       2009-06-23 16:53:58.000000000 -0700
+++ lynx2-8-7/src/HTML.c        2010-11-20 15:13:28.641109509 -0800
@@ -4780,22 +4780,24 @@
                * "[IMAGE]-Submit".  - FM
                */
               StrAllocCopy(I_value, "Submit");
               I.value = I_value;
           } else if (ImageSrc) {
               /* [IMAGE]-Submit with verbose images and not clickable images.
                * Use ImageSrc if no other alt or value is supplied. --LE
                */
               I.value = ImageSrc;
           }
+#if 0
           if (present && present[HTML_INPUT_READONLY])
               I.disabled = YES;
+#endif
           if (present && present[HTML_INPUT_CHECKED])
               I.checked = YES;
           if (present && present[HTML_INPUT_SIZE] &&
               non_empty(value[HTML_INPUT_SIZE]))
               I.size = atoi(value[HTML_INPUT_SIZE]);
           LimitValue(I.size, MAX_LINE);
           if (present && present[HTML_INPUT_MAXLENGTH] &&
               non_empty(value[HTML_INPUT_MAXLENGTH]))
               I.maxlength = value[HTML_INPUT_MAXLENGTH];
           if (present && present[HTML_INPUT_DISABLED])

Comment 1 Kamil Dudka 2011-02-22 08:39:25 UTC
(In reply to comment #0)
> See below for a detailed problem description (and patch to solve it) sent
> upstream to the "lynx-dev" mailing list.

Thank you for reporting the bug.

> Always, when using a website that is affected by this issue, because it uses
> "readonly" text fields to store additional input that should be provided along
> with a submitted form.  Unfortunately, I don't have a URL for a public website
> that I can give to demonstrate this issue.  However, I can assure you that the

It should be quite easy to create a new one.

> patch below fixes the issue by reverting to Lynx's previous behavior, which
> itself wasn't 100% correct, since the "readonly" field wasn't treated as
> unmodifiable as it ideally should be, but was much less problematic than the
> current behavior.

So the patch solves the problem you are facing, but re-introduces an already fixed bug?

> Hi.  Somewhere between Lynx versions 2.8.6 and 2.8.7 a change was made to
> assume that "readonly" text-entry fields on a webpage should get the "disabled"
> attribute applied in Lynx's internal representation of the page.  I suspect the
> intention behind this change was to ensure that the field was actually
> unmodifiable on the page, which it accomplishes successfully.  However, an
> unfortunate side effect of this change is that upon form-submission of a page,
> any "readonly" (and therefore disabled) text fields are omitted from the
> submitted data, causing problems with websites that expect the previous
> read-only data to be provided with the submitted form.

We need to fix the submission then, not the readonly status.

> --- lynx2-8-7.original/src/HTML.c       2009-06-23 16:53:58.000000000 -0700
> +++ lynx2-8-7/src/HTML.c        2010-11-20 15:13:28.641109509 -0800
> @@ -4780,22 +4780,24 @@
>                 * "[IMAGE]-Submit".  - FM
>                 */
>                StrAllocCopy(I_value, "Submit");
>                I.value = I_value;
>            } else if (ImageSrc) {
>                /* [IMAGE]-Submit with verbose images and not clickable images.
>                 * Use ImageSrc if no other alt or value is supplied. --LE
>                 */
>                I.value = ImageSrc;
>            }
> +#if 0
>            if (present && present[HTML_INPUT_READONLY])
>                I.disabled = YES;
> +#endif
>            if (present && present[HTML_INPUT_CHECKED])
>                I.checked = YES;
>            if (present && present[HTML_INPUT_SIZE] &&
>                non_empty(value[HTML_INPUT_SIZE]))
>                I.size = atoi(value[HTML_INPUT_SIZE]);
>            LimitValue(I.size, MAX_LINE);
>            if (present && present[HTML_INPUT_MAXLENGTH] &&
>                non_empty(value[HTML_INPUT_MAXLENGTH]))
>                I.maxlength = value[HTML_INPUT_MAXLENGTH];
>            if (present && present[HTML_INPUT_DISABLED])

Please let me write a better patch such that the already fixed bug stays fixed.  It may take some time until I get to this bug as I am solving some more urgent issues at the moment.  Chances are that you or upstream will have the proper solution sooner.

Comment 2 David Paschal 2011-02-22 09:36:28 UTC
> So the patch solves the problem you are facing, but
> re-introduces an already fixed bug?

Yes, but as I noted earlier, I think the problem my patch solves is much worse than the bug it re-introduces.  I can continue using my patched version in the meantime.

Comment 3 Kamil Dudka 2011-02-22 13:26:50 UTC
For reference, here is the corresponding upstream thread:

http://thread.gmane.org/gmane.comp.web.lynx.devel/6999

Comment 4 Thomas E. Dickey 2011-05-25 22:51:19 UTC
I implemented a fix for this last week, which will be in dev.9

Comment 5 Kamil Dudka 2011-05-26 10:18:05 UTC
Thomas, thank you for taking care of the issue.  I will backport the fix for stable Fedora.  This should be the upstream patch if I am not mistaken:

ftp://invisible-island.net/temp/lynx2.8.8dev.8f.patch.gz

Comment 6 Thomas E. Dickey 2011-05-26 20:56:22 UTC
yes - actually the changes for this bug-report were done between
the "d" and "e" patches.  Focusing on that would probably help
with backporting

Comment 7 Kamil Dudka 2011-05-27 09:27:37 UTC
Created attachment 501271 [details]
create a local git repository containing -dev snapshots of lynx

Not fully related to this bug, but I have written a simple shell script that serializes the -dev snapshots of lynx into a local git repository.  I hope this will make the future backports more fun.

Comment 8 Kamil Dudka 2011-05-27 11:53:28 UTC
Created attachment 501289 [details]
backport of the changes introduced in lynx2.8.8dev.8d

Comment 9 Kamil Dudka 2011-05-27 12:00:46 UTC
built as lynx-2.8.7-7.fc16

Comment 10 Kamil Dudka 2011-05-27 12:02:23 UTC
David, are you able to verify that the backported patch solves the problem you were facing?

Comment 11 David Paschal 2011-05-30 04:27:13 UTC
Since I wasn't able to directly install "lynx-2.8.7-7.fc16" on F13, I ran "rpmbuild --rebuild lynx-2.8.7-7.fc16.src.rpm" and installed the resulting "lynx-2.8.7-7.fc13.i686.rpm".  I accessed the website in question and verified that (1) read-only form fields are still properly treated as read-only, and (2) the website now properly receives the read-only text fields with the form submission.  Thanks for taking care of this.  Will you be pushing this fix into F15 at least?

Comment 12 Kamil Dudka 2011-05-30 06:54:12 UTC
(In reply to comment #11)
> Since I wasn't able to directly install "lynx-2.8.7-7.fc16" on F13, I ran
> "rpmbuild --rebuild lynx-2.8.7-7.fc16.src.rpm" and installed the resulting
> "lynx-2.8.7-7.fc13.i686.rpm".  I accessed the website in question and verified
> that (1) read-only form fields are still properly treated as read-only, and (2)
> the website now properly receives the read-only text fields with the form
> submission.

Thank you for the testing.

> Will you be pushing this fix into F15 at least?

No problem to release updates for F13+.  The only problem was that I had not had enough time to create my own testing page.  For you the testing is much easier since you already have an existing one.

Comment 13 Fedora Update System 2011-05-30 06:56:46 UTC
lynx-2.8.7-6.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/lynx-2.8.7-6.fc14

Comment 14 Fedora Update System 2011-05-30 06:56:54 UTC
lynx-2.8.7-4.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/lynx-2.8.7-4.fc13

Comment 15 Fedora Update System 2011-05-30 06:57:01 UTC
lynx-2.8.7-7.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/lynx-2.8.7-7.fc15

Comment 16 Thomas E. Dickey 2011-05-30 09:34:26 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Since I wasn't able to directly install "lynx-2.8.7-7.fc16" on F13, I ran
> > "rpmbuild --rebuild lynx-2.8.7-7.fc16.src.rpm" and installed the resulting
> > "lynx-2.8.7-7.fc13.i686.rpm".  I accessed the website in question and verified
> > that (1) read-only form fields are still properly treated as read-only, and (2)
> > the website now properly receives the read-only text fields with the form
> > submission.
> 
> Thank you for the testing.
> 
> > Will you be pushing this fix into F15 at least?
> 
> No problem to release updates for F13+.  The only problem was that I had not
> had enough time to create my own testing page.  For you the testing is much
> easier since you already have an existing one.

Sounds good.  I had only ad hoc testpages, and part of the time spent here was tidying things up to make a better testpage (several forms).  Essentially my change separated the two uses and didn't go far beyond the existing logic, so I was mainly checking that the changes gave the expected behavior.

Comment 17 Bug Zapper 2011-05-30 11:16:17 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 18 David Paschal 2011-05-30 18:12:18 UTC
Changed Fedora "Version(s)" field from 13 to 14 to keep "Bug Zapper" from automatically closing this bug when F13 goes EOL.

Comment 19 Fedora Update System 2011-05-30 22:29:16 UTC
Package lynx-2.8.7-7.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lynx-2.8.7-7.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/lynx-2.8.7-7.fc15
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2011-06-04 03:03:34 UTC
lynx-2.8.7-7.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2011-06-09 00:03:57 UTC
lynx-2.8.7-6.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2011-06-09 00:04:54 UTC
lynx-2.8.7-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.