Develop Reference

Bootstrap v4 .modal("show") slow execution

I've noticed that bootstrap's modals take time to show as the page's content becomes more significant.
It takes less than 100ms to show when the page is empty, but takes proportionally more time as the amount of content in the page becomes more significant.
I do not understand this correlation. Can anybody explain this behavior and suggest a workaround to make the modals appearance faster independently of the page's size ?
EDIT: You can reproduce the behavior by going i.e here and execute the command
console.time("modalTime"); $("#exampleModal").modal("show"); console.timeEnd("modalTime");
in console, to see how much time it takes. Then add more content to the page by manipulating the DOM and re-execute the command.
My results: modalTime : 70 ms on the original page. modalTime : 1208 ms after making the content of the page 10x larger.

Ok, I am able to reproduce a delay if I add 50.000 lines of text to the document:
https://plnkr.co/edit/hvRAn3wg91GBCPxK2gwb?p=preview
The problem with a huge DOM like this is, that any manipulation will take long.
It might be a problem of jQuery, but I doubt.
To prove that the delay has nothing to do with the Modal, I am painting the button to red when clicking it - even this simple action takes as long as opening the modal window.
jQuery(document).ready(function() {
for (var i = 0; i < 50000; i++) {
$( "#content" ).append( "This is just some test. This is just some test. This is just some test. This is just some test. This is just some test. This is just some test. This is just some test. This is just some test. This is just some test. <br/>" );
}
$("#btnToggleMoadal").click(function(e) {
$("#exampleModal").modal("show");
$(this).css({backgroundColor:"red"});
});
});
Edit: I have also tested jQuery's onClick vs onClick out of the DOM - but there is no difference. https://plnkr.co/edit/483Sk2FGXk9lT8dLZIdo?p=info
Edit: I have to correct my answer. It's definitely the Bootstrap Modal which causes the performance issue. I think the problem is somewhere around _adjustDialog() in modal.js.
I recommend to open an issue at https://github.com/twbs/bootstrap/issues and show the Plunker example.

javascript window confirm pops up several times

i am trying to use the confirm method but for some reason the confirm window pops up several times. I googled and tried different things but unfortunately I can't get it running properly. The code is the following:
//user clicks on the delete button
$("#deletePopUpImage").click(function(){
console.log("deletePopUpimageCalled");
//get the id of the image
id = ($(this).parent().prop("id"));
//create the ajax request
data = "typ=function&functionType=deleteUserImage&id="+id;
//open the confirm box
var r = confirm("Are you sure that you want to delete this image?");
if (r == true) {
console.log("loadAjaxCAlled");
//Ajax call
loadAjax(data);
//hide the image and the loader
hideImagePopup();
} else {
//do nothing
}
});
The strange thing is that sometimes the confirm window pops up twice, sometimes three times and sometimes as expected once. That's why inserted the two console.logs.
"deletePopUpimageCalled" always appears just once. However "loadAjaxCAlled" appears several times.
In the success callback of the Ajax request I am just hiding the thumbnail div.
Do you know what's wrong with my code above?
Thanks
Stefan

Probably the code that attaches the event:
$("#deletePopUpImage").click(function(){...});
is invoked several times. Every invocation of .click(...) makes a new handler that fires when the button is clicked.
Some browsers stack up log the same entries into one (so the log doesn't extend so fast), that could be the reason you don't see "deletePopUpimageCalled" many times.
It would the best to check this by debugging it in the browser.

Ok I found the problem. In the Ajax success handler I set the div of the image, that was deleted, to display:none instead of deleting it. Thus divIds could occur twice, three times, etc. After changing the code to delete, it worked smoothly.

Can anyone explain why focus() is not working always on IE 10?

I have the following code, which works 100% ok on Chrome and Safari, but on IE 10 sometimes works and sometimes don't.
Sys.Focus = function(obj){
if(Sys.Anim.length>0){
Sys.Fp = obj;
return;
}
obj.focus();
}
.
.
.
function Animate(...){
var i,...
.
.
.
if(Finished(Sys.Anim[i])){
Sys.Anim.splice(i,1);
if(Sys.Anim.length==0){
if(Sys.Fp){
Sys.Focus(Sys.Fp)
Sys.Fp = null;
}
}
}
.
.
.
}
.
.
.
email = document.getElementById("email");
Sys.Focus(email);
email.onkeydown = function(){
debugger
.
.
.
}
In response to different user actions, some objects on screen either change color or move around, this is done by Animate(), objects to be animated are added to an Array (Sys.Anim) and removed when the animation ends. In order to keep everything smooth, if the page becomes ready for input before the animation ends (which almost always happens), the focus() call is delayed until the animation ends, that is about 1/3 of a second.
Everything works just as expected in all browsers except IE 10. At first I thought there was a logic error on my code, however I debugged it with the Developer Tools and I discovered all the steps are carried on correctly, the problem is that focus() is not actually working all the times.
Another important detail... when focus() succeeds email.onkeydown is executed every time I hit a key, however when focus() fails I obviously must click on the input control to focus it manually, but when this happens the email.onkeydown function is never called even when the content of the input control is updated with every key punch.
I tryed:
setTimeout(function(){obj.focus()},100);
which was proposed as a solution for this problem, but it doesn't solve mine.
Why this happens and how can be worked around?
UPDATE:
For testing proposes I added the following function:
email.onfocus = function(){
debugger
}
which brings the debugger only when focus() succeeds, if focus() fails the debugger won't pop up even if you focus the input control manually with a mouse click, because in this case I simply cannot focus the input control by using the Tab or Shift-Tab keys... is just as if it didn't exist!!!

Solved!!!
After lots of frustrating tests I discovered that the input control was nested inside a DIV which in some circumstances was disabled, dumb of me to disable a DIV.
...However all other browsers only actually disable the input control if it is explicitly disabled. The guys at Microsoft always trying to be "too clever" decided to take a conterintuitive approach and leave it half done.
The problem and my complaint is that the input control does not look disabled, it looks normal and the caret actually appears if you click on it, you can even type on it no matter how disabled it was supposed to be... so for the record, always remember IE 10 only half disables input controls which are inside disabled DIV giving you no visual clue of what's going on.

setTimeout unpredictable behavior in IE9

I am looking at a third-party javascript that has a global timer. The timer is used to warn the user with a modal alert box when the session is within 5 minutes of expiration, and any mouse-clicks or keystrokes will reset the timer.
The timer is set up during OnLoad. I wanted to add a second timer, but I have noticed that if the second timer expires while the modal alert box is displayed, the behavior is unpredictable. For sake of simplicity:
var myFunkyTimer1;
var myFunkyTimer2;
function myOnLoadFunction() {
// alert in 10 seconds
myFunkyTimer1 = setTimeout(function(){alert("Get Funky!")}, 10000);
// alert immediately after user clicks ok
myFunkyTimer2 = setTimeout(function(){alert("GET RANDOM!")}, 11000);
}
This works fine in IE8. However, in IE9 the first alert box displays 10 seconds after page load, but if I wait over one second to click OK, the second alert box will not display until sometime between 2-11 seconds afterward.
I can work around this issue, but I was curious if anyone had seen similar issues with setTimeout on IE9 and if Microsoft knows they are randomizing any timers that are queued up behind modal popup windows.

rules for "prevent this page from creating additional dialogs"

I try to understand Firefox's behavior regarding the added "prevent this page from creating additional dialogs" on dialog boxes.
Using jquery, if I add the following listeners :
//html
<input class="testInput" />
//javascript
$('.testInput')
.click(function(){ alert('clicked') })
.keyup(function(){ alert('keyup') })
When clicking on the input, the alert box appears normally, until the
~13th time.
When hitting a key, on the other hand, the second message box already
appears with the message "prevent this page from creating additional
dialogs". Actually, there seems to be some tiemout, and if I wait
like 2 seconds between two keystrokes, the message disappears.
From my informal tests, 2. actually applies whenever the alert box is not called from within a onclick callback (e.g : keyup callback, displaying an alert box in answer to an ajax action...)
I am using Firefox 9.0.1 under Ubuntu, as far as I know I haven't tweaked firefox's settings regarding these thresholds.
I imagine it happens with any recent version of any browser.
I am using the jQuery library, but I don't think it is relevant here.
My question is :
What are the exact rules which make this warning appear in a dialog box ?
[Edit]
Using Chromium/Ubuntu (version 17.0.963.26), the threshold seems to be only the delay between two dialog boxes.
You can test this from jsfiddle here (thx Rory McCrossan)

The exact rule(s): A timed interval between the dialog boxes popping up.
The value used to determine this is set in SUCCESSIVE_DIALOG_TIME_LIMIT
Check out line 2614 in the link below the snippet:
nsGlobalWindow::DialogOpenAttempted()
TimeDuration dialogDuration(TimeStamp::Now() - topWindow->mLastDialogQuitTime);
if (dialogDuration.ToSeconds() < Preferences::GetInt("dom.successive_dialog_time_limit",SUCCESSIVE_DIALOG_TIME_LIMIT)){topWindow->mDialogAbuseCount++;return (topWindow->GetPopupControlState() > openAllowed || topWindow->mDialogAbuseCount > MAX_DIALOG_COUNT);}topWindow->mDialogAbuseCount = 0; return false;}
Link to source

You can kick around the Firefox source if you like. Note that different browsers will have different rules.
The relevant code for Firefox is in nsGlobalWindow.cpp and nsGlobalWindow.h (the links below are to line numbers, and so will slowly rot as the source changes). It appears to be controlled by the constants MAX_DIALOG_COUNT (10) in nsGlobalWindow.h and SUCCESSIVE_DIALOG_TIME_LIMIT (3, units are seconds). nsGlobalWindow.cpp keeps a count (mDialogAbuseCount). Apparently, the dialogDuration function either increments or clears mDialogAbuseCount depending on whether the dialog has been open longer than the SUCCESSIVE_DIALOG_TIME_LIMIT. The AreDialogsBlocked function uses the mDialogAbuseCount (in part) to decide whether they're blocked.
So in short: If you're repeatedly opening pop-ups and then closing them within three seconds, after 10 or so you'll trigger something.