166211 - Form Manager overwrite READONLY / DISABLED field

Status: RESOLVED WORKSFORME

(Toolkit :: Form Manager, defect, P4)

Description

[wkfx2003-bugzilla]

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.

Comment 1

[Stephen P. Morse]

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.

Comment 2

[wkfx2003-bugzilla]

Attachment: BEFORE

Comment 3

[wkfx2003-bugzilla]

Attachment: After

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This seems serious.

reassigning to new module owner.

Comment 5

[Boris Zbarsky [:bzbarsky]]

*** Bug 180924 has been marked as a duplicate of this bug. ***

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** Bug 188036 has been marked as a duplicate of this bug. ***

Comment 7

[Davide Baroncelli]

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

Comment 8

[Erik Fabert]

*** Bug 262834 has been marked as a duplicate of this bug. ***

Comment 9

[Matt Ryall]

Attachment: Using Javascript to complete form

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

Comment 10

[Pascal Chevrel:pascalc]

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 :))

Comment 11

[Mike Shaver (:shaver emeritus)]

Pretty gross and not too invasive to fix, blocker+ for 1.8.1.

Comment 12

[Michael Wu [:mwu]]

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.

Comment 13

[wkfx2003-bugzilla]

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)

Comment 14

[Fernando García Gómez, stripTM]

Attachment: New before testcase

First send the form, and then click on the "Remember" button in the Firefox dialog when asking about saving the password.

Comment 15

[Fernando García Gómez, stripTM]

Attachment: 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

Comment 16

[Michael Wu [:mwu]]

What build/platform? I still cannot reproduce this on linux trunk or branch using your testcase.

Comment 17

[Fernando García Gómez, stripTM]

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).

Comment 18

[Pascal Chevrel:pascalc]

bug not entirely fiwed according to comment #17, reopening (we probably need an updated testcase)

Comment 19

[Andrés G. Aragoneses]

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

Comment 20

[Andrés G. Aragoneses]

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.