Menu
Given this code
var body = $('body')
var div = $('<div>').appendTo(body);
div.text('this is text, yo');
var input = $('<input>').attr('type','file').appendTo(body);
var demo = function(cb,wait){
setTimeout(function(){ cb()},wait);
}
var alertMe = function(){
$('div')
.text('click on choose file!')
.fadeIn().delay(3000).fadeOut()
};
var wait = 3000;
demo(alertMe,wait);
at this fiddle. What is going on that if you open the file dialog right after the div becomes visible in Chrome and Firefox the presence of the modal does not affect the disappearance of the div, but it does in IE(11). If you wait for the div to become visible and leave the file modal open in IE the div stays visible indefinitely, and as soon as you close the div it seems that execution of JavaScript resumes.
651
The File Chooser Dialog is script-blocking in Internet Explorer, similar to other dialog windows like alert and prompt. Script-blocking dialog windows like these are becoming increasingly rare; in fact, Internet Explorer on the Xbox doesn't even support them - nor do Windows Web Applications.
I created another demo to show the effect you were featuring in your fiddle. Every 500ms a data-* attribute is updated on the <body> element, which then has it's new value reflected in the content property of the ::after pseudo-element. In IE, this process is halted while browsing for a file.
Note that this is only the case with scripts; CSS animations aren't blocked, and therefore could be leveraged to make adjustments to the layout or the display of elements in spite of script-blocking windows. In your case, you could utilize a special class that fades an element out after a short delay, or simply set a transition-delay on the opacity of any element you expect to hide.
I created another demo to show the use of utilizing CSS Animations instead.
The question of whether or not the dialog should prevent scripting is one I'll have to look into a bit further with the team - I personally am not aware if that behavior is presently spec'd or not. But one of the reasons Internet Explorer prevents scripting is so that we will have access to the file list (among other things) when you're done making your selections.
Consider the following fiddle:
var button = document.querySelector( "button" ),
browse = document.querySelector( "input" );
button.addEventListener( "click", getFiles );
function getFiles () {
browse.click();
document.body.appendChild( getFileList( browse ) );
}
function getFileList ( control ) {
var list = document.createElement( "ul" );
for ( var i = 0; i < control.files.length; i++ )
list.appendChild( document.createElement( "li" ) )
.textContent = control.files.item( i ).name;
return list;
}
In the above we intend to show you the files you selected (and will presumably proceed to upload) once the Choose Files dialog has been closed; as such, we leverage the fact that it's a synchronous script-blocking window.
In Chrome or Firefox, we will not be able to immediately run through the control.files collection and build a summary list of selected files.
I'll continue to look into this; in fact I've already walked down the hall to speak with a Program Manager in charge of DOM and Eventing to begin hashing out the difference between Internet Explorer and Chrome/Firefox in this case.
I'll file an issue internally to have our team further investigate what we ought to do with this behavior. Until then, I hope this answer helps you to some degree find harmony between the disparate implementations.
154
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
