How to display radio button on an alert box - javascript

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

Related

Usage of AJAX in an alert box

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.

Apply with LinkedIn Plugin - Language Support

First of all I am disappointed that the plugin itself is only in English. If the user clicks the Apply with LinkedIn button and logs into a French profile, for example, it displays correctly. Only to return to a page with the plugin displaying "Already Applied" in English.
To get around this I wrote some javascript to replace the "Apply with LinkedIn" and "Share" text with French equivalents after the buttons load. The issue I now have is with the "Already Applied" version of the button. It appears that it loads asynchronously to the actual plugin meaning that it overrides my French text in some cases, but other cases it does not.
I know that I can harness the onsuccess event when an application is submitted. However when that LinkedIn user revisits the page the "Already Applied" text does not always appear in the correct language.
Question 1: Has anyone had luck with any techniques to achieve the desired results?
Question 2: When oh when will LinkedIn finally properly support this?
Any help or direction is much appreciated.
Thanks!
UPDATE:
I can confirm that Igor F.'s solution to use the setInterval function and check every 100ms for a change was the best option and worked flawlessly in all tested browsers.
Thanks for all the help and suggestions!
The plugin seems to receive its information asynchronously from the server and act upon it, i.e. change the content of the page. Have you tried listening to DOM mutation events?
Here is an example how they work when the user causes a change in the web page:
<html>
<!-- This is just mock-up to allow user to modify the DOM -->
<body>
Text to add: <input id="in1" type="text"/>
<button onclick="addNode();">Add node</button>
<p id="toAdd"></p>
</body>
<script type="text/javascript">
function addNode() { // adds a text node to the <p> element
document
.getElementById("toAdd")
.appendChild(document
.createTextNode(document
.getElementById("in1")
.value
)
);
}
///////////////////////////////////////
// Here comes the interesting part: !!!
document
.getElementById("toAdd") // listen to modifications of the <p> element
.addEventListener(
"DOMSubtreeModified", // in this case all modifications of its subtree
function() {
alert('Modified!'); // change this to whatever fits your purpose
}
);
</script>
</html>
More about mutation events here. If you want to support IE < 9, you'll need a different approach. Maybe periodically check, e.g. every 100 ms, whether the web page contains the English button and change it into French. See setInterval(). This should be future-proof (mutation events are deprecated), but probably even more inefficient (slow).
In any case, it's a hack. Only LinkedIn can provide a clean solution, e.g. allowing for a language code parameter for the plugin.
From what I gather, this is the problem you're seeing:
The button initially loads with the text "Already Applied".
You modify the button text to change the text to French.
LinkedIn modifies the button text to change it to "Already Applied".
...and it's intermittent because sometimes 3 happens before 2.
I can't think of a "good" solution to this problem, though I would like to hear if Igor's answer works. I can think of a good hack:
The asynchronous call must be targeting the button somehow, probably through its classname*. So after you've changed the text to French, change the classname to something else. This way the asynchronous call will fail, and your text will never be overridden.
The consequence is that LinkedIn will lose all access to this button, but since it's an Already Applied button, I don't think that will matter. You also risk losing CSS attributes selected using the classname, but looking at a LinkedIn button in the wild, I think the styles are all inlined anyway (and you could always duplicate them yourself under a new classname if you had to.)
Good luck!
* It's also possible that LinkedIn is storing a JavaScript reference instead of targeting via the classname. This will be harder to track down, but the same rule applies: find whatever part of the page LinkedIn uses to identify that button, and destroy it.

Are there any additional parameters that can be passed to the Javascript native confirm / alert methods?

Are there any additional parameters besides the message accepted by the alert / confirm native JavaScript methods?
Specifically I would like to highlight the cancel button rather than the ok.
If you need to do this, the way to get what you want is to concoct your own dialogs.
I'm not sure why any site design that takes itself seriously would ever use the built-in dialogs in the absence of some evidence that web users recognize some semantic content from those things (which I seriously doubt).
Oh, and the basic way to do this is to populate a <div> with your dialog content; position it absolutely (or whatever, depending on your overall situation); and show it in front of a div that covers the whole page with partial opacity or something so that the dialog is "modal" (with respect to your own page). Various libraries provide ways to do that, some more fancy than others. The point is that since it's your own dialog, you can style anything you like.

Generally valid way to execute a javascript only once (via cookies)?

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.

Why do textfields become disabled in IE6 for no reason?

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

Categories

Resources