Closed Bug 166211 Opened 22 years ago Closed 18 years ago

Form Manager overwrite READONLY / DISABLED field

Categories

(Toolkit :: Form Manager, defect, P4)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: wkfx2003-bugzilla, Assigned: mwu)

References

Details

Attachments

(5 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020901
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020901

I have some READONLY and/or DISABLED field but the form manager were able to
change those fields

Reproducible: Always

Steps to Reproduce:
1. Create a form with text box (writtable) value set to "before"
2. Fill in and submit the form once, let Form Manager fill it
3. Now, change the "value" of the text box by changing the HTML code to "after"
and change it to READONLY
4. Reload the form and the form manager should ask to choose a set of value "before"
5. Choose "before"
Actual Results:  
The read only field is changed

Expected Results:  
The read only field is not changed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Reporter, could you please attach the html for the page before and after the
change.  I'd like to see how you are disabling and/or write-protecting the field.
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → mozilla1.3beta
Attached file BEFORE
Attached file After
This seems serious.

reassigning to new module owner.
Assignee: morse → dveditz
Status: ASSIGNED → NEW
Target Milestone: mozilla1.3beta → ---
*** Bug 180924 has been marked as a duplicate of this bug. ***
*** Bug 188036 has been marked as a duplicate of this bug. ***
Severity: normal → major
Keywords: mozilla1.3
This happens to me too: the "readonly" was set by DHTML, and double clicking on
the field causes the form manager value to appear inside the readonly box
*** Bug 262834 has been marked as a duplicate of this bug. ***
This can also be achieved in the same document, having Javascript that modifies
a readonly form before submission. Although weird, not sure if this is really a
big problem.

See attached document.

Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913
Firefox/0.10.1
Assignee: dveditz → nobody
Asking for this bug to be a blocker for the next major release.

Note that Canal+ (big European TV and WebTV broadcasting company) contacted Mozilla Europe about it recently because they have an increasing number of their online subscribers complaining about it (which also shows that they have an increasing number of firefox subscribers :))
Flags: blocking1.8.1?
Pretty gross and not too invasive to fix, blocker+ for 1.8.1.
Flags: blocking1.8.1? → blocking1.8.1+
Assignee: nobody → michael.wu
We've been unable to reproduce this bug on all three platforms on branch. My local trunk build on linux doesn't see this bug either. Closing as WORKSFORME. If someone can come up with a more specific platform/branch, or better testcase, they can reopen this.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
I think I created this bug report when using Mozilla Suite in 2002.
I cannot reproduce this bug today using Firefox 1.5.0.4 on WindowsXP SP2
(And I don't have extension that is related to FORM)
Attached file New before testcase
First send the form, and then click on the "Remember" button in the Firefox dialog when asking about saving the password.
Attached file New after testcase
Then Firefox displays the readonly and password inputs modified with value: 'before', but not the hidden input. On the submit form, the queryString sends 'test.html?a=after&b=before&c=before', which I think it's erroneus and inconsistent
What build/platform? I still cannot reproduce this on linux trunk or branch using your testcase.
I'm reproducint the bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
The input readonly treatment should be the same as input hidden, because both of them should not be modified by the user, I've checked the performance in another browser (Opera) and it is mostly as I thought.

This bug has been reported by users in Canal+ Spain web, who used Firefox with the Password Manager function activated, as Pascal pointed out in comment #10 in which we precisely have a form with those 3 types of <input/> and users do not understand why they can't log in when the value they see (readonly) and the value they enter (password)seem correct, but the hidden they can't modify and we    don't want to modify, is different (it is not modified by the password manager).
bug not entirely fiwed according to comment #17, reopening (we probably need an updated testcase)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Confirming here too:

I am still able to reproduce this bug, with the last testcases sent [1][2], using both Windows (Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4) and Linux (Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.0.3) Gecko/20060425 SUSE/1.5.0.3-7 Firefox/1.5.0.3).

[1] https://bugzilla.mozilla.org/attachment.cgi?id=226418
[2] https://bugzilla.mozilla.org/attachment.cgi?id=226420
Closing bug again as WORKSFORME (sorry for the bugspam and the confusion, we all were trying with Firefox 1.5) because Fernando García has been able to check that it is fixed in Bon Echo [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2) Gecko/20060512 BonEcho/2.0a2]. It seems that the input fields in this case are not changed if they are filled.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → WORKSFORME
Flags: blocking1.8.1+
Product: Core → Toolkit
QA Contact: tpreston → form.manager
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: