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
857 bytes, text/html
Details
New Testcase with expected results.
1.53 KB, text/html
Details
Slightly different version of same
1.03 KB, 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?


    
    

    
  
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)
        — 
      

    


  

    
    

    
  


  

        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: