185701 - Event mis ordering for form submission and onChange in file upload control

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Rob Jones]

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

An onChange event for a file upload control is not getting comleated before
a form is submitted.

I attach a testcase

IF you type in the box and then click elsewhere onChange gets called.
If you use the browse button it does not get called immediately.
It waits until you focus on another control.
Regardless of input mechanims if the control you next focus on is the submit
button the submit happens before the onChange of the file control.
Notice the url that appears after the submit.
The form should have been reset before submission as the onChange should fire
before submit. 

Reproducible: Always

Steps to Reproduce:
1. enter data into file upload box
2. click submit
You will see the filename appear in the url even though it should have been
removed before the submit happens.

Comment 1

[Rob Jones]

Attachment: testcase

Comment 2

[Rob Jones]

Attachment: testcase

Comment 3

[Tobias Herp]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130:
onchange doesn't fire at all

Comment 4

[Thimo Jansen]

Same on 1.3 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
Gecko/20030312), onchange doesn't get fired when you use the "Browse" button,
but does when you type in a filename.

Comment 5

[Thimo Jansen]

Same on 1.3 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
Gecko/20030312), onchange doesn't get fired when you use the "Browse" button,
but does when you type in a filename.

Comment 6

[Matt Patterson]

Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3)
Gecko/20030312; Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3)
Gecko/20030312; 

onchange isn't firing if you use the 'browse' file picker widget. I've prepared
a simpler testcase, and will attach it.

Comment 7

[Matt Patterson]

Attachment: testcase

simplified testcase

Comment 8

[Karen Chun]

When clicking on Submit from the last field this order of events results:
1. OnSubmit is handled first
2. action is handled
3. lastfield OnChange is handled

Order should be:
1. lastfield Onchange first
2. abort both Submit action and onSubmit if false
3. THEN onSubmit (if not aborted)
4. abort action if onsubmit is false
5. action (if not aborted)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Is this Windows-only?  On Linux I don't even see the form submit when the "not
allowed" alert comes up.

Oh, and comment 6 and comment 7 are totally unrelated to this bug.

Comment 10

[Aaron Lawrence]

Works for me, Moz 1.8a 2004071417. Get a popup when tabbing off the control, and
also after using the browse button

Comment 11

[Boris Zbarsky [:bzbarsky]]

Reopening; this can't be "fixed" since there was no patch.

Aaron, what OS are you testing on?

Comment 12

[Aaron Lawrence]

Windows 2000.
Just because there wasn't a SPECIFC patch for this bug doesn't mean it isn't
fixed by one of many other thousands of changes.
Are you saying this still happens for you?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Aaron, in this bug database "FIXED" means fixed by a specific known patch.  If
it just generally works now and no one knows what fixed it, the right status is
"WORKSFORME".

Marking so.

Comment 14

[Aaron Lawrence]

OK. *sigh*. 
I wish you had TESTED it yourself before reopening, cause I just wasted half an
hour retesting the original testcase.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I did test.  On Linux.  And it worked for me.  That's why I asked what OS you
tested on.

Had you said the OS to start with, I would have reopened and reclosed with the
right resolution without asking you any followup questions.