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

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
17 years ago
3 months ago

People

(Reporter: Rob.Jones, Assigned: saari)

Tracking

({testcase})

Trunk
x86
Windows 2000
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Reporter

Description

17 years ago
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.
Reporter

Comment 1

17 years ago
Posted file testcase
Reporter

Comment 2

17 years ago
Posted file testcase

Comment 3

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
Posted file testcase
simplified testcase

Updated

16 years ago
Depends on: 4033, 99350

Updated

16 years ago
Keywords: testcase

Comment 8

16 years ago
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)

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

15 years ago
Works for me, Moz 1.8a 2004071417. Get a popup when tabbing off the control, and
also after using the browse button
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Reopening; this can't be "fixed" since there was no patch.

Aaron, what OS are you testing on?
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---

Comment 12

15 years ago
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?
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.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 14

15 years ago
OK. *sigh*. 
I wish you had TESTED it yourself before reopening, cause I just wasted half an
hour retesting the original testcase.
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.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.