onBlur & onFocus are not on file upload control

RESOLVED FIXED in Future

Status

()

defect
P4
major
RESOLVED FIXED
21 years ago
2 months ago

People

(Reporter: desale, Unassigned)

Tracking

({testcase})

Trunk
Future
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

Reporter

Description

21 years ago
No events occur on file object.
Providing information to simulate the problem.

Product: Seamonkey.[apprunner]
Build Date: 03/17/99
Platform: PC [Windows-95]

Steps to Reproduce:
1] Please copy the code I'm providing. Save as HTML file.
2] Open this HTML file in apprunner.
3] This file will provide you one file object and one text box. Upper one is
called test object. and lower one is called result text box.
4] Try to click on test object.
5] Then try to click on result test box.
6] Again click on test text box.

Code:

<html>
<head>
<title>Test Page</title>
</head>

<SCRIPT LANGUAGE="JavaScript1.1">


function report(text)
{
var value=document.workform.result.value;
var msg= value+ " " +text;
    document.workform.result.value=msg;
}

</SCRIPT>
<body>
<FORM NAME="workform" >
<h4>This simple test will list the events which are occuring in test
object.</h4><br><br>

Test Object:<INPUT TYPE=file NAME="username" SIZE=15
onClick="report('Click()');" onfocus="report('Focus()');"
onBlur="report('Blur()');" onSelect="report('Select()');"
onChange="report('Change()');"><br><br>
Result Text Box<INPUT TYPE=text NAME="result" SIZE=80>
<input type="reset" value="Reset">
<h5>conclusion: onClick of the test object only onclick() and onfocus() events
should occur.
<br>Where as Blur() event is also occuring. onSelect is not working.</h5>

</form>
</body>
</html>


Expected Results: Should provide the list of events that are occuring.

Actual Results: does not show any events.

Description: No events are occuring.
Reporter

Updated

21 years ago
Target Milestone: M3
Reporter

Comment 1

21 years ago
Target M3 per request.
Reporter

Updated

21 years ago
Priority: P3 → P2
Reporter

Updated

20 years ago
QA Contact: 3847 → 4616

Comment 2

20 years ago
This bug is on M3 milestone which has passed.  Putting on Blank milestone to be
reassigned to a current or future milestone.

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M5

Updated

20 years ago
Target Milestone: M5 → M6

Comment 3

20 years ago
Moving out to M7

Updated

20 years ago
Target Milestone: M7 → M8

Comment 4

20 years ago
Not going to get to the anonymous content fix for M7.  I'll hit it early in M8.

Updated

20 years ago
Target Milestone: M8 → M9

Comment 5

20 years ago
This basically an anonymous content bug.  While I realy want to fix this
the other bugs on my M8 list are more critical.  M9 for now.  If I surprise
myself and do it tomorrow it may still make it but I doubt it.

Updated

20 years ago
Target Milestone: M9 → M10

Comment 6

20 years ago
I hate to move this again but I still won't get this for M9.
Priority: P2 → P4

Comment 7

20 years ago
joki agrees this is p4, not p2.

/be

Comment 8

20 years ago
Moving to M11.  Not to hold for M10 per conversation with joki during bug triage
today.
Reporter

Updated

20 years ago
Summary: No events occur on file object. → wrong events fire on file object.
Reporter

Comment 9

20 years ago
I tested ths one again. Now Events are firing but those are firing
inappropriately.
On clicking the testobject, select event is firing, which is wrong offcourse.
Changing summary.

Comment 10

20 years ago
Moving multiple bugs to m12

Comment 11

20 years ago
Moving to m13 because Joki seems to be distracted.

Updated

20 years ago
Target Milestone: M13 → M14

Comment 12

20 years ago
Moving off bugs that won't make M13
Target Milestone: M14 → M16
Moving M16.
Reporter

Updated

19 years ago
Keywords: beta1

Comment 14

19 years ago
Putting on the PDT- radar for beta1.
Whiteboard: [PDT-]
Reporter

Comment 15

19 years ago
Adding nsbeta2 to keywords.
Keywords: nsbeta2
Whiteboard: [PDT-]
Need more information.  What user features is this stopping?  nsbeta2- per PDT.
Whiteboard: [nsbeta2-]

Comment 17

19 years ago
M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 18

19 years ago
Updating Milestone to M18.
Target Milestone: M16 → M18
Tested this also on Linux, seeing this here too so updating OS.

Regarding what user features is this stopping: on Windows I guess not much. On
Linux I cannot select the text in the edit box, I can not type into the field
etc. so the only way I can change something there is to use the browse button. I
am not sure if that is due to this bug or something else. In any case that feels
kinda bad to me.

Tentatively marking nsbeta3.
Keywords: nsbeta3
OS: Windows 95 → All
I am the virtual joki.
Assignee: joki → heikki
Status: ASSIGNED → NEW
Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Bug triage with nisheeth & ekrock: nsbeta3-. Adding relnote3 keyword.

Opened a new bug for the issue with Linux, see bug 49131.
Keywords: relnote3
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3-]
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: M18 → Future
Sending most of my events bugs to joki.
Assignee: heikki → joki
Status: ASSIGNED → NEW
Reporter

Comment 26

19 years ago
Nominating for nsbeta1, since nsbeta2,3, dogfood, rtm keywords are going to be 
cleared soon and important bugs could loose attention. I think this one deserves 
nsbeta1 nomination.
Keywords: beta1, nsbeta2, nsbeta3nsbeta1

Updated

19 years ago
Depends on: 57770
Tested on Windows, this weeks build. I get click, change and select events when
I click on the top textarea. No blur or focus. When I click on the Browse button
I get focus.

Prashant, could you test this on other platforms?
Keywords: nsbeta1nsbeta1-, qawanted
Target Milestone: Future → mozilla1.0
Reporter

Comment 28

18 years ago
Heikkie, Only click & select events are working.
blur & focus events are not working. Tested with 2001-06-05-11.0.9.1

Comment 29

18 years ago
cleaning up this bug...

I just found this in the release notes for 0.9.5. What is the status of this
bug? Is there a chance that this will be in for Moz1.0? Does this break our
HTML4 compatability?

Whiteboard: [nsbeta2-][nsbeta3-]

Comment 30

18 years ago
I've found this bug to occur on any form with a file upload field in it. If the
field does not have something in it, the form is sumitted, but the browser goes
into spin cycle until the session is stopped.

All the rest of the data is sent and processed correctly.

Comment 31

18 years ago
Also, if the field does not does not point to a valid file, the browser goes 
into spin cycle until the session is stopped. Should this be a new bug?
Reporter

Comment 33

18 years ago
leaving nsbeta1 nomination since it deserves it because two events are missing 
on this FILE object. onBlur & onFocus are not working.
Adding testcase keyword.

Keywords: testcase

Comment 34

18 years ago
ADT triage team would like to know what problems users see because of this.
Whiteboard: [ADT need info]
Reporter

Comment 35

18 years ago
If some website is using some validating script which is bound to execute 
onFocus of File object, then that script will never execute. This is just an 
example but there could be lots of possibilities of using these two [OnBlur 
OnFocus] events on File object. Important is these events work on 4.x browsers, 
so there could be tons of web-pages out there using these events. Its important 
on backward compatibility issue too.
Reporter

Comment 36

18 years ago
chagning summary.
Summary: wrong events fire on file object. → onBlur & onFocus are not on file object.
Reporter

Comment 37

18 years ago
*** Bug 79846 has been marked as a duplicate of this bug. ***

Comment 38

18 years ago
ADT triage: We need data on what top sites actually use this.  Gerardo, do you
have any tools that would help us to determine the real need for this?

Comment 39

18 years ago
I don't have a reliable way to do this. Teleport pro is a webcrawler that helps 
to search for content in the web. It's helpful to check if a tag is used in a 
few sample pages. Proving whether a tag is used in the top100 sites requires to 
check hundreds of thousands pages -- i.e. 6500 URLs need to be explored if you 
follow recursively one link from the top 100 main pages; just two links would 
reach Teleport pro maximum database size of 65,000 URLs.

A file object with the onfocus/onblur event handler couldn't be found in the
first test with 6500 URLs, and for that matter, not even a simple file object 
was found --which proves it's not a valid test, as file objects are certainly 
used out there.  I'm afraid we have to make a call without this data point.

This bug is not happening in IE, so potentially there could be actual pages 
relying on this functionality.
nsbeta1- per ADT/Embed triage. No test cases, or proff that this problem occurs
in the wild.
Keywords: nsbeta1nsbeta1-

Updated

18 years ago
Target Milestone: mozilla1.0 → mozilla1.1

Comment 41

17 years ago
Why would a web site expose file upload capability to the public? 

I'm going to go out on a limb and say 99.9%, give or take .1%, of web pages that
use file upload objects are behind some kind of a login system, or on the
intranet. Any statistics generated by looking for public use as the basis of the
necessity of supporting of these events are indeed invalid. Hence making a bug
priority decision based upon these statistics is also invalid.

These events are necessary for standards compliance, and are used by web
developers (like me...). They are supported by all of the other major browsers
and it seems a bit odd that Mozilla has quite robust event support, but is
missing some of the basic ones.

My .02
I used to work at a web development company that uses Allaire, or MacroMedia
ColdFusion, (They can help you with this)

and they have file upload capability all over the place.. we wrote B2B
applications that send file templates back and forth between servers, and it
allowed users to upload templates. ie Business forms to printing vendors.. 

that is where you are going to find a ton of upload uses.. I know they are out
there, many are accessable to the public, just not on the top100 main pages.  I
know it exists, because I tested them everyday.. If you want to get in touch,
they make b2b ecommerce stuff.  Companies use these capabilities to order stuff
from other companies.
regarding comment #41, 

many of these are behind logins for employee's of company X to buy product from
company Y.. but many are not also, and available to the public.. to use to buy
stuff, and upload templates to be used by the company to print products, logos,
etc.. 

-I think I'm past my NDA after I worked there.. but they use IE, if Mozilla
doesn't have this capability, They have to ColdFusion Tags to generate this
functionality.

Major companies are involved in this stuff.. most of it happens outside of
public view.

Comment 44

17 years ago
http://validator.w3.org/file-upload.html is a page with file-upload but without
unblur.

Comment 45

17 years ago
There is also the possibility of a web hosting agency using a file object when 
it allows users to upload their own web pages. This is a safe (and cheap) 
alternative to using FTP access to allow a user to upload a site for 
submission. Since we know that there are quite a few hosting agencies with 
direct advertising for personal web pages, and that there is a high probability 
that these sites would use a file object for uploads, this bug now becomes 
something that should be fixed soon. Really, it isn't a matter of who uses IE. 
The goal is to make Mozilla as good or better than IE in the first place. ;-) I 
vote for better than.

(I suppose that's more than $0.2 - bill me)

Comment 46

17 years ago
Not sure if this is the right place for this but here we go...I'm starting
development of a file repository and was targeting to use the onBlur event to
auto-select the correct mimetype for the file being uploaded from a select list
on the.  Sure would be nice to have.

Comment 47

17 years ago
after email exchange w/ saari; minusing.

Updated

17 years ago
Summary: onBlur & onFocus are not on file object. → onBlur & onFocus are not on file upload control
Reporter

Comment 48

17 years ago
I tested this with Latest Branch with WindowsXP, MacOSX, MacOS 9.1, & Linux.
Here are the results I found.

On WindowsXP, & MacOS 9.1 onFocus occurs only if we click "Browse" button & not
if we click the file textbox. OnFocus should occur even if we click on file textbox.
OnBlur does not occur at all.

On MacOSX, & Linux both onFocus & onBlur do not occur at all.

Updated

17 years ago
Keywords: mozilla1.2

Comment 49

17 years ago
*** Bug 149680 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Keywords: mozilla1.2mozilla1.3

Comment 50

17 years ago
My opinion -
as a web developer, I frequently find uses for file-uploading.  On a company
intranet, HR might upload employee pictures.  The "attach" tool for bugzilla is
itself a file-upload.  For remote users, large files might take a long time to
upload - if there is a policy that only certain file types can be uploaded, it
would be *really nice* to have a javascript enforcement of this policy on the
client, so that the form doesn't have to spend 10 minutes uploading the .psd
file only to have the server reject the file.  With a javascript check, the
client could realize !/\.jpg$/.test(form.employee_image.value) and save the
upload time.
While this could easily be handled in the form's onsubmit, it would be nice to
have it in the employee_image's onblur.

Therefore I am adding a vote to this bug.

Updated

16 years ago
Blocks: 204749

Comment 51

16 years ago
Also onChange is not triggered, see bug 204749.
Maybe that one should be duped to this one.

Comment 52

16 years ago
.
Assignee: joki → saari
QA Contact: desale → ian

Updated

16 years ago
Blocks: 185701

Comment 53

16 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future
Everything seems to work properly in both testcases.  WFM?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031005

Updated

16 years ago
Flags: blocking1.6b+
Flags: blocking1.6b+
This is not wfm, the testcase still fails for onBlur and onFocus with windows
build 2004020909
I've not looked at blur yet, but here is the story with focus:

1)  The focus event's original target is the anonymous text input
2)  Text inputs call preventBubble() on focus events in
    nsTextEditorFocusListener::Focus

Testcase coming up showing the behavior on several types of focusable things....

So the questions:

1)  Should whatever is triggering onfocus bubble?  Per DOM Events spec, the HTML
    focus event does NOT bubble.... but DOMFocusIn does.

2)  Why are text inputs calling preventBubble?  This was added in revision 1.152
    for bug 34896 (no patches, no reviews, not useful).

3)  How do we make <input type="file"> fire the focus listener here?  I suppose
    we could unset the STOP_DISPATCH flag in the input node itself and then
    reset it?  Would that be too hacky?
Posted file Testcase (obsolete) —

Updated

15 years ago
No longer depends on: 173950

Comment 59

15 years ago
*** Bug 173950 has been marked as a duplicate of this bug. ***

Comment 60

15 years ago
Is this bug still here?  Also is a qa still wanted as in the Keywords?

-R
> Is this bug still here?

Yes, as you could tell easily by trying the testcases...

> Also is a qa still wanted as in the Keywords?

Not really, per comments.
Keywords: qawanted
jst, sicking, peterv, bryner, neil, mats, how does the following proposal sound:

1)  Don't let focus/blur events bubble at all, per DOM spec
2)  Have the file input fire a focus/blur on itself when the corresponding
    DOMFocusIn/DOMFocusOut bubbles up to it.  Which probably means we need to
   implement DOMFocusIn/DOMFocusOut.

#2 would fix this bug.  It's a little dangerous in terms of event ordering, but
I don't really see a better alternative.
#1 would make us compliant with the DOM spec and allow us to remove the editor
code that prevents bubbling of these events.  It may cause issues in XUL, but we
should just fix those, imo.

Thoughts?
Alternativly we could add code to textboxes so that they check if they're an
anonymous textbox inside a filecontrol. And then fire focus/blur events on that
parent filecontrol manually. However that seems like a worse alternative.

If your solution works it sounds like a good way.
XBL textboxes and editable menulists have a similar problem. They work around it
by inheriting the onfocus and onblur attributes onto the anonymous content.
That's not technically correct since then the target of the event will be wrong.
Which in the case of filecontrols would be extra bad since the script wouldn't
have access to the target.
(In reply to comment #65)
>That's not technically correct since then the target of the event will be wrong.
We already have a bug filed on that. My hope was for one fix for two bugs.
Assignee: saari → events
Whiteboard: [ADT need info]
This should be fixed now. focus and blur events do bubble from 
(native) anonymous content to the <input type="file"> element, but
not more than that (unless the element is inside anonymous content, in which case those events are handled in the binding parent).
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
This got fixed by bug 238987.
No longer blocks: 238987
Depends on: 238987
Component: Event Handling → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.