Closed Bug 4033 Opened 26 years ago Closed 17 years ago

onBlur & onFocus are not on file upload control

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: desale, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(3 files, 1 obsolete file)

test case as attachment
(deleted), text/html
Details
New Testcase with expected results.
(deleted), text/html
Details
Slightly different version of same
(deleted), text/html
Details
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.
Target Milestone: M3
Target M3 per request.
Priority: P3 → P2
QA Contact: 3847 → 4616
This bug is on M3 milestone which has passed. Putting on Blank milestone to be reassigned to a current or future milestone.
Status: NEW → ASSIGNED
Target Milestone: M5
Target Milestone: M5 → M6
Moving out to M7
Target Milestone: M7 → M8
Not going to get to the anonymous content fix for M7. I'll hit it early in M8.
Target Milestone: M8 → M9
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.
Target Milestone: M9 → M10
I hate to move this again but I still won't get this for M9.
Priority: P2 → P4
joki agrees this is p4, not p2. /be
Moving to M11. Not to hold for M10 per conversation with joki during bug triage today.
Summary: No events occur on file object. → wrong events fire on file object.
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.
Moving multiple bugs to m12
Moving to m13 because Joki seems to be distracted.
Target Milestone: M13 → M14
Moving off bugs that won't make M13
Target Milestone: M14 → M16
Moving M16.
Keywords: beta1
Putting on the PDT- radar for beta1.
Whiteboard: [PDT-]
Adding nsbeta2 to keywords.
Keywords: nsbeta2
Whiteboard: [PDT-]
Need more information. What user features is this stopping? nsbeta2- per PDT.
Whiteboard: [nsbeta2-]
M16 has been out for a while now, these bugs target milestones need to be updated.
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
Keywords: relnote3
Sending most of my events bugs to joki.
Assignee: heikki → joki
Status: ASSIGNED → NEW
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, nsbeta3 → nsbeta1
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: nsbeta1 → nsbeta1-, qawanted
Target Milestone: Future → mozilla1.0
Heikkie, Only click & select events are working. blur & focus events are not working. Tested with 2001-06-05-11.0.9.1
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?
Keywords: mozilla1.0, mozilla1.0.1, nsbeta1
Whiteboard: [nsbeta2-][nsbeta3-]
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.
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?
Attached file New Testcase with expected results. (deleted) —
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
ADT triage team would like to know what problems users see because of this.
Whiteboard: [ADT need info]
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.
chagning summary.
Summary: wrong events fire on file object. → onBlur & onFocus are not on file object.
*** Bug 79846 has been marked as a duplicate of this bug. ***
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?
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: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1
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.
http://validator.w3.org/file-upload.html is a page with file-upload but without unblur.
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)
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.
after email exchange w/ saari; minusing.
Keywords: mozilla1.0.1 → mozilla1.0.1-
Summary: onBlur & onFocus are not on file object. → onBlur & onFocus are not on file upload control
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.
Keywords: mozilla1.2
*** Bug 149680 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2 → mozilla1.3
Depends on: 173950
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.
Blocks: 204749
Also onChange is not triggered, see bug 204749. Maybe that one should be duped to this one.
.
Assignee: joki → saari
QA Contact: desale → ian
Blocks: 185701
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
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?
Attached file Testcase (obsolete) (deleted) —
Attached file Slightly different version of same (deleted) —
Attachment #141278 - Attachment is obsolete: true
Blocks: 230356
Blocks: 167195
No longer depends on: 173950
*** Bug 173950 has been marked as a duplicate of this bug. ***
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
Blocks: 238987
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
Closed: 17 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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: