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])
(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.
> 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.
For reference, here is the corresponding upstream thread: http://thread.gmane.org/gmane.comp.web.lynx.devel/6999
I implemented a fix for this last week, which will be in dev.9
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
yes - actually the changes for this bug-report were done between the "d" and "e" patches. Focusing on that would probably help with backporting
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.
Created attachment 501289 [details] backport of the changes introduced in lynx2.8.8dev.8d
built as lynx-2.8.7-7.fc16
David, are you able to verify that the backported patch solves the problem you were facing?
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?
(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.
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
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
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
(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.
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
Changed Fedora "Version(s)" field from 13 to 14 to keep "Bug Zapper" from automatically closing this bug when F13 goes EOL.
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).
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.
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.
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.