Closed Bug 4033 Opened 22 years ago Closed 14 years ago
Blur & on Focus are not on file upload control
Target M3 per request.
This bug is on M3 milestone which has passed. Putting on Blank milestone to be reassigned to a current or future milestone.
Moving out to M7
Not going to get to the anonymous content fix for M7. I'll hit it early in M8.
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.
I hate to move this again but I still won't get this for M9.
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.
Moving off bugs that won't make M13
Putting on the PDT- radar for beta1.
Adding nsbeta2 to keywords.
Need more information. What user features is this stopping? nsbeta2- per PDT.
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.
OS: Windows 95 → All
I am the virtual joki.
Assignee: joki → heikki
Status: ASSIGNED → NEW
21 years ago
Status: NEW → ASSIGNED
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.
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
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.
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?
Heikkie, Only click & select events are working. blur & focus events are not working. Tested with 2001-06-05-126.96.36.199
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?
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?
leaving nsbeta1 nomination since it deserves it because two events are missing on this FILE object. onBlur & onFocus are not working. Adding testcase keyword.
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.
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.
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.
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.
*** Bug 149680 has been marked as a duplicate of this bug. ***
Also onChange is not triggered, see bug 204749. Maybe that one should be duped to this one.
Assignee: joki → saari
QA Contact: desale → ian
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
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?
*** 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.
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: 14 years ago
Resolution: --- → FIXED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.