In my HTML page I am displaying alert box many times.
After few execution of alert boxes, Browser will ask
"Prevent this page from creating additional dialogs"
How can I avoid this?
Thanks.
Don't use alert for regular user notifications. Instead, use jqueryUI's or your own dialog implementation, or console.log in debugging code.
Bear in mind that modal dialog boxes tend to be user-unfriendly and should only be used in exceptional circumstances (for example, failure of AJAX communication). If you're using modal dialogs in the regular flow of an application (for example if form validation fails), consider an alternative, less intrusive notification, such as adding a red border/background to the form fields in question.
You can't. That is basically a security feature added in the browser to prevent sites from having an infinite loop making alert boxes and annoying the user.
You can't prevent this: the browser is noticing that the page keeps alerting, and assumes (often, correctly) that there is an infinite loop on the page. Preventing further alerts keeps the page usable (eg you can hit the back button).
If you are using the alerts as a way of communicating important information in the normal course of operation, you might want to consider filling an element on the page with the same info. For (a very non-fancy) example, instead of
alert(x + ' just happened!');
just add a <div id="alert"></div> to the page and do
document.getElementById('alert').innerHTML(x + ' just happened!');
Related
Is it possible to have a radio button in an alert box?
The requirement is, not to use any modal box, that why we just think if it's possible with alert box or confirm box. then we can good to go.
Any help will appreciate.
Sample Screenshot is below.
i don't guess. i know that this is in fact impossible.
the reason is simple:
alert(), prompt() aswell as confirm() were part of html + js since js exists.
they never got deprecated though they break the asyncronous flow of javascript.
this is essentially why they only allow you to play around with strings.
they were never intended to be feature rich.
they were actually invented out of the blue because the inventor (Brendan Eich) thought they'd come in handy. (wich at that time was more than enough for everyone)
they are by design blocking operations and should be avoided as much as possible.
to get around them simply create a so called modal dialog (thats basically a <div> with position: fixed above the pages content.
benefit:
you can easily make it appear as you want and you would not break any network connections or behavior of your application.
PS:
don't use w3schools as reference for learning or anything else.
they are a low quality database. you should look stuff up on mdn or other sites but should seriously avoid w3schools since it's not feature complete on any topic.
keep in mind this is an opinion.
It is impossible to use radio inside of alert window.
Message parameter in window.alert(message); has a string type and you cannot put Object or HTML there (will be transfomed to string).
Do not overuse window.prompt() Method , as it prevents the user from accessing the other parts of the page until the box is closed.
Window prompt Usage Note
I have a javascript alert asking the user to insert a password. When user presses button, I will do an AJAX call to check the password. This could generate another alert with the response (if it was accepted or not), but I wonder if it is possible to have the AJAX response change the text of my first alert? Is it even possible to override the alert button's default not to close itself when clicking "okay"?
I think generally you should try and minimize the use of alerts in your web application. They are very obtrusive and annoying. Generally people just update the DOM to display user information. An alert is for something more unique and important than somebody just mistyping their password.
EDIT:
As other people are pointing out, you should use modal dialogs instead to have behavior as you specify.
I'm quite sure you can't do that since the way the alert is constructed and displayed is different in each browser (just look at mobile browsers). I think you'll safeguard your sanity longer if instead you use modal dialogs.
Being a blocking function, alert() is an abomination in itself, and owing to that would thwart the very thing you are trying to do.
Simple question (probably), but I'm buggered if I can find an answer...
I have a back-end CGI application and a number of dynamically-created webpages (plain ol' HTML+JS+CSS), each with a single form. In every form, in addition to a number of other submit buttons, there is a closeApplication button, which, when clicked, causes the page to be submitted and the CGI application to perform some cleanup processing.
Sometimes however, once thy've done their work, users being what they are (idiots), they don't bother to press the closeApplication button, and simply close the browser window.
I've been trying to figure out how to automatically 'fire' the closeApplication button if the user does this, by using the onUnload handler, but I can't seem to find out how to determine whether the user is closing the browser window/tab or simply submitting the page.
Is there a way within the onUnload handler to find this out?
p.s. I'm just using basic JS - no JQuery or other framework, but I doubt that matters...
Unfortunately, you're out of luck.
This question covers very similar ground: how to identify onbeforeunload was caused by clicking close button
What you could possibly do is store a variable when anything valid is clicked on your page that would navigate away, then check that in your onunload handler - if it's false (or whatever), then assume that they've closed the window and submit. I think this would probably be flaky though.
I'd like to add an onbeforeunload javascript, asking the user to bookmark the page (there's a small button in the header for that purpose).
The problem is, no matter if they'd like to bookmark it, it's pointless and annoying after running once.
So, what's a generic solution to stop a javascript from running more than once?
Thanks,
Emilia.
EDIT:
Yes, I guess an onload event would be more appropriate?
I don't really want to add "big red buttons"...
Any basic example how a IP validation + script would look like?
I would say it's already a bad idea to use a pop up when the user wants to exit the page even if it is only once, it's annoying and obtrusive. I suggest you place a big button on site itself if you want to call the visitor to an action, bookmarking in this case.
If you still want to though, you should use IP validation and not cookies, cookies are temporal, they can be removed by the user, and visitors will not like to be presented the same suggestion over and over.
I have made few changes on this huge JSF page, which is full of Javascript as well. I dont know which change make the problem happen.
The problem is: after some Javascript is executed, all the text fields in the page become readonly. The problem is not occurring in IE7 nor in Firefox. I have debugged all the javascript, there is no errors thrown! And there is nothing telling the fields to become readonly, since its working correctly in IE7.
Not sure what the problem is, could be CSS related? or Javascript? And why is it happening on IE6 only?
Note: "Don't support IE6 is not an option"
While IE may be buggy make trouble in some situations, I'm quite sure this is not an IE bug.
How do you tell the fields are read only? Do you get any optical confirmation or is it just that you can't click them any more? In that case, I'll bet you a beer that is's some invisible DIV or other layout element that, due to some CSS setting, squeezes itself above the input fields.
Try the IE developer toolbar to find out whether it's a layout problem.
If they are really disabled as in <input disabled> you need to show some JavaScript or (better) a link.
Still not sure what happened with that build, but what i was sure about is all the Ajax modifications i did was responsible for the problem.
The scenario was like:
Fill textfield1 (hit getValues1 , then hit a validate Ajax)
Fill textfield2 (hit getValues2 , then hit validate on both values together)
Fill textfield3 (hit getValues3 , then hit validate on all three values)
And a forth time again the same scenario. The page was built by a new to JSF guy, and it was very huge. I took long time refactoring it. But now its much better, each text field still have a getValues Ajax, but instead of validating them after getting all the values, i filter the allowed values on the server by sending the chosen criteria
The scenario now:
Fill textfield1 (hit getValues1 Ajax)
Fill textfield2 (hit getValues2 Ajax with value of 1, and get only allowed values)
... etc
The problem seems to be an Ajax racing conditions and at some moment IE6 was hanging or stuck in a deadlock, im not sure.
Lesson learned, "Refactoring once may take a week, but without every single issue will take longer"
um... don't support IE6??? ;)
Suggest disabling your CSS and seeing if the problem goes away. I'm not aware of any CSS tags that can disable a field, though.
Other than that, debugging is your only option. Remove all your .js and add it back in line-by-line until something breaks.
It will probably be hard for us to help you without seeing some code.
See if the HTML for the page has the 'disabled' attribute set on those INPUT elements. If so, then javascript is being used to enable the elements after the page has loaded. This is a not-uncommon technique to keep users from prematurely trying to interact with a page before all scripts have loaded.
If that's what is happening, then what you've probably done is break the way the script recognizes which elements need to be enabled. Since this is only happening on IE6, it sounds like the script might be doing some esoteric DOM navigation, which broke as a result of changes to the markup or CSS.
Unfortunately this is something you'll have to debug by reverting back to previous versions until you identify the change you made that broke the page.
Based on the other answers here, and some of your comments to them, it seems there is a JavaScript function in your page that sets elements to be enabled or disabled.
In order to help, we would have to see your code. Here is something you can do yourself, though, that would solve your problem:
Find that function (or ANY function) that sets elements in your page to disabled or enabled.
Depending on your development environment, there are different ways to do this, but somehow add a breakpoint there at the function.
Load the page.
Whenever that function is called, code execution will stop at that function. Whenever it stops, make sure that it was supposed to be called (and watch the call stack).
Eventually, you'll hit that breakpoint at a point where you weren't supposed to. Look at the call stack to see what caused it (which function resulted in a call to this function).