49064 - [CAN'T REPRO]hidden form data corruption

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[Dawn Endico]

Asa was looking at bug 48845 and tried to mark it as a duplicate of bug 18213.
A bug in mozilla's form handling messed up the hidden field in the bug
form and changed the hidden field named 'id', from value 48845 to
4884548845.

Bugzilla then marked bug 18213 as being a duplicate of the non-existant
bug 4884548845.
<INPUT TYPE=HIDDEN NAME="id" VALUE=48845>

Comment 1

[Dawn Endico]

BTW, asa was using build 081406 on NT.

Nominating this as dogfood.  If this bug is happening with bugzilla,
then its happening to lots of other sites that use forms, including banks
and ecommerce sites. If these form submission bugs don't get cleared up sites
will be forced to defend themselves by changing their cgi's to specifically
exclude mozilla users. This will happen as soon as a $48,845 transaction shows
up as $4,884,548,845.

Mozilla has a long history of form submission bugs. This area of the code
seems pretty fragile. There's no point in releasing a product until form
submission works robustly. An important use of web browsers is as a tool
to access online data including sensitive financial data. If we can't do
that job properly, we're doomed.

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Asa, were you doing back/forward stuff at all before marking the bug duplicate? 
I would have to guess it wasn't the first time in the session you look at the
bug.  Could this be related to session history / stateful frames?

Comment 3

[Asa Dotzler [:asa]]

unfortunately I don't remember if I had been navigating back and forward.  I
usually don't do that in bugzilla because it never works very well.  My usual
behavior is that I click on a link in a bugzilla email message that loads the
bug.  If I look at other bugs before changing it I do that in another window.  I
didn't even notice this one until someone pointed it out to me hours later.  It
is interesting though that this bug doubled a field like we were seeing in bug 42178

Comment 4

[Brendan Eich [:brendan]]

Is post-data now associated as a part of the key used to match properly against
session history entries?

/be

Comment 5

[Radha on family leave (not reading bugmail)]

No, post data is not used to compare  with session History entries. Eric 
Pollmann has a bug on it. may be, this is related to 46338

Comment 6

[leger]

Putting on [dogfood+] radar.

Comment 7

[rods (gone)]

I cannot reproduce this. I need some very specific steps for reproducing it 
before I can do anything with this bug.

Comment 8

[rods (gone)]

It's been two days and nobody can suggest how to reproduce it. If yo can then 
reopen this bug.

Comment 9

[Dawn Endico]

Steps to reproduce: use mozilla to edit bugs in bugzilla.
Before long, something will corrupt a bug in our database.

Except that we don't want our database corrupted so please
do all testing here.
http://landfill.tequilarista.org/bugzilla_tip/

Mozilla screwing up form data is a rare but continuing problem that's
been plagueing bugzilla for a long time. The fact that its intermittent
doesn't mean it isn't real. 

I'll give my beloved green mozilla plush toy to whoever can make a 
reproducible test case for this.

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I agree that worksforme is an inappropriate resolution for this bug.  It is
known to be very difficult to reproduce, and there is no reason to believe that
it no longer exists.  It has existed for a while:  ekrock mentioned it in bug
46825.

This bug needs to be fixed.  It's not clear whether it's easier to do that by
figuring out reliable steps to reproduce or by looking at the code to figure out
what could cause it.

Comment 11

[rods (gone)]

I am not saying it isn't important.
I am not saying it doesn't exist.
What I am saying is, maybe someone else can find a reproducable testcase. I 
don't have the time at the moment to be spending hours trying to reproduce this 
bug. If this bug is that important, then maybe someone in qa could help us out? 
Eric, can we make that happen?

Comment 12

[ekrock's old account (dead)]

gerardo, could Netscape QA work on trying to create a reproducible test sequence 
for this bug? The bug is very dangerous (and a standards-compliance bug) because 
it causes hidden form data fields to be corrupted. The user has no way to detect 
that this has happened, and then bad data will be submitted to the server.

Comment 13

[rods (gone)]

nominating for nsbeta3 because it is a dogfood bug

Comment 14

[Kevin McCluskey (gone)]

Marking nsbeta3+

Comment 15

[Eric Pollmann]

The hidden input is implmented by nsGfxButtonControlFrame. 
nsGfxButtonControlFrame does not implement nsIStatefulFrame, so clicking back
and/or forward shouldn't have any effect on the value stored in a hidden input
itself.  This is probably not the same bug we saw weeks ago in ender lite where
a text input would be doubled by pressing forward/back.

Clicking back/forward could still be involved in this bug, as the post data
stream is stored and reposted by session history, and updating a bug is a form
POST (not a GET)  I've tried several thing and have been unsuccessful at making
a hidden input post doubled, including trying to post a bug update when not
logged in.  Has anyone seen this bug anywhere else besides bugzilla that might
be more reproducible?

Comment 16

[Jim Roskind]

Could we have an update on this dofgood bug?  From what I can see, it sounds 
like we can't reproduce it, and hence we should get it off the dogfood radar.

Comments?

Comment 17

[rods (gone)]

I have never been able to reproduce, I even tried closing it out. I think this 
bug needs to go away permanently until it can be reproduced.

Comment 18

[gerardok]

Trying to reproduce...

Comment 19

[Prashant Desale]

Here is one testcase I've created, and tried to simulate exact similar 
conditions as reporter mentioned.
Unable to reproduce. I'm using Win-95. somebody please test it on WinNT, since 
bug is on winNT.

I'm attaching testcase. It looks like bug report. Click Submit button.
CGI will print value of hidden filed named ID in testcase.

Expected Results: 
Value of Hidden filed named ID: 48845

If actual result is different than written above then bug is still there.

Testcase is coming after these comments.

Comment 20

[Prashant Desale]

Attachment: Testcase I talked about in above comments.

Comment 21

[gerardok]

Tried submitting hidden fields with post method, played with the back and 
forward buttons, and still couldn't figure out how to reproduce on Win NT.

Comment 22

[rods (gone)]

It is about time we take this off the dogfood and nsbeta3 radars, since it seem 
unreproducable.

Is the recent testcase reproducable 100% of the time on Win98, because I tried 
it on WinNT and it worked fine.

Comment 23

[Kevin McCluskey (gone)]

Marking WORKSFORME, since the problem can not be reproduced with current builds.

Comment 24

[ckritzer (gone)]

Marking VERIFIED WORKSFORME on:
- LinuxRH62 2000-09-07-08-M18 Commercial
- Win98     2000-09-07-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial

As always, if you disagree and/or have a consisitently reproducible testcase, 
reopen.