Develop Reference

JavaScript onclick event works only as double-click

I'm writing because I need to solve this problem. Until recently, the code was working just fine and I've been using it for quite a long time, but yesterday, when I was testing the page, everything changed.
The idea is click on an image with an anchor tag that is going to redirect the user to another page and in doing so, a confirm dialog box should pop up to ask the person whether they want that. I haven't changed anything in the code, so I'm not getting what's happening. Here's the code:
// **JavaScript**
function confPopUp() {
for (var i = 0; i < 6; i++) {
document.getElementsByClassName("redPic")[i].onclick = redConf;
}
}
function redConf() {
var conf = confirm(
"You're about to be redirected to our social media page. Do you accept?"
);
if (conf) {
return true;
} else {
return false;
}
}
window.onclick = confPopUp;
<!-- **HTML** //THERE ARE 5 MORE ELEMENTS WITH THE CLASS NAME "redPic". -->
<img class="redPic" src="images/instagramLogo.png" alt="Instagram Logo">
The problem is that I'm testing it, right now, and it's not working properly, a the day before yesterday it was working fine, only one click and now, it's working as double-click.
I'd appreciate your help, thanks.

When the page first loads, you're setting a single event handler:
window.onclick=confPopUp;
Later, when there's a click anywhere in the window, that runs your confPopUp function, which hooks up the click handlers on the .redPic elements.
Later, if you click a .redPic element, your redConf function runs.
If you want the .redPic elements to have their handlers hooked up on page load, call confPopUp instead of making it a click handler. Change:
window.onclick=confPopUp;
to
confPopUp();
Be sure this code is running after the .redPic elements exist. There are several ways to do that, pick the one that suits your target browsers and preference:
Put the code in a script tag at the end of the document, just before the closing </body> tag. This works with all browsers, no matter how old.
In even vaguely-modern browsers, call confPopUp from a DOMContentLoaded event handler:
document.addEventListener("DOMContentLoaded", confPopUp);
In modern browsers, add a defer attribute to your script tag.
In modern browsers, add type="module" to your script tag to make your script a module. That defers it just like defer does, and puts it in strict mode (which is a good idea), and put the code in it in module scope rather than global scope (which is really crowded).
So why did it seem to work yesterday? Presumably, because you were clicking the window without realizing it, triggering that initial event handler that hooked up the .redPic elements. Today it just happened that you didn't click the window before trying to click a .redPic element, so you discovered this problem. The problem's been there all along.

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.

TinyMCE issues with resizable content in IE8

Update: After posting on the TinyMCE forum (something I should have done before offering the bounty) the primary issue may be solved, but I'm still very much open to anything regarding the other issues of how to disable the resizable behavior (number 2 and 3 at the end of the post).
I am having trouble saving content with TinyMCE in IE8 (not other versions). In IE, certain elements in the editor have handles in each corner and draggable "borders", and when you focus in to start editing, a striped border may appear:
Problem:
If I submit the form while the thick border is still visible (state 3 in the image), the form will not save the content. I have to click into another area of the editor to make all the borders disappear, and then submit the form.
I'm Using the TinyMCE 3.4.6 jQuery package, I don't get this behavior in other browsers.
Update:
I've narrowed down the cause of the issue quite a bit and found a few things:
The problem occurs with or without the jQuery build, and does not depend on which tinymce plugins are in use.
The thicker "border" only seems to appear when there is a (min-)height/width applied to the element, either declared inline or from external CSS.
Using IETester, I was getting errors that claim 'length' is null or not an object when focus from the active element is lost; i.e. when you click anywhere outside the TinyMCE editor.
I did not see this error in a true IE8 install (something I currently can not access), however: this makes sense somewhat, considering the problem and workaround stated above. I had to hit submit twice and dismiss the warnings to get the form to post in IETester.
These borders and handles will actually extend outside of the editor/iframe:
I created a live bare-bones demo, here is the content of it:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js"></script>
<script type="text/javascript" src="tiny_mce/jquery.tinymce.js"></script>
<script type="text/javascript">
$(function() {
$('textarea.tinymce').tinymce({
script_url : 'tiny_mce/tiny_mce.js',
content_css : 'test.css'
});
});
</script>
<form action="" method="post">
<textarea class="tinymce" name="content"><p>Testing</p></textarea>
<button type="submit">Submit</button>
</form>
/* Content of test.css */
p {
min-height: 24px; /* this line makes the handles appear */
background-color: #f00;
color: #fff;
}
How to reproduce:
Open the demo in IE8
Click on the existing paragraph, a small 1px border should appear, and you should be unable to edit the text.
Click on the element again, now the thick border appears and text can be edited.
Type a few characters, then click the submit button. The update will not be sent with the $_POST data. If you were to click another area inside the editor, removing the thick border, the data would be sent normally.
Questions/Issues:
Important: How can I get the form to post the edited text without requiring a workaround from the user?
Update: This seems to be resolved in a recent commit from the TinyMCE lead developer. I still have been unable to test on a real IE8 install, but this worked and silenced the errors in IETester.
Less important: Is there any way to prevent or remove the handles and draggable edges completely? I'm guessing this is a concern with IE's implementation of contentEditable and not so much TinyMCE, and may not even be the cause of the problem.
Extra: How can I prevent these handles from extending outside the editor?

Question 2 is due to the IE implementation of contentEditable, This is a ticket at their connect site requesting to fix it https://connect.microsoft.com/IE/feedback/details/576043/paragraphs-with-haslayout-behave-like-a-block-inside-contenteditable (login required)
I don't know of any solution for Question 3, except to wait for a new IE. In the latest IE10 under windows8 they claim that it's fixed https://connect.microsoft.com/IE/feedback/details/576040/resizing-handles-in-contenteditable-elements-are-placed-over-any-other-element (login required), but their solution is to hide the resizing handles always. Well, there's a solution and it's to avoid using any style while you're editing that forces the internal hasLayout flag for IE

alright this is a weird IE8 bug. I've found a workaround but still the tinymce team should fix this.
I've found out that before submitting the form you could set the content of the textarea to the content of the textarea... Sounds weird but calling the .html() triggers a tinymce event that returns the correct html.
$("button").click(function() {
$("textarea").html($("textarea").html());
});

There is apparently no way you can fix the second issue.
Here is an articles that explains it quite well: You can't remove those unless you remove the property that made them appear.
http://www.satzansatz.de/cssd/onhavinglayout.html
(search for the word "remove")
You can still improve a bit by using this on the container (the element with contenteditable):
function fixIE( editableContainer ) {
editableContainer.onmousedown = function ( e ) {
e = e || event;
( e.target || e.srcElement ).focus( );
};
editableContainer.onresizestart = function ( e ) {
e = e || event;
if ( e.stopPropagation ) {
e.stopPropagation( );
}
e.cancelBubble = true;
if ( e.preventDefault ) {
e.preventDefault( );
}
e.returnValue = false;
return false;
};
}
(Your element doesn't have to be a div)
The onmousedown will allow you to click only once to get to the state where you can write.
The onresizestart will prevent resizing.

if you give it hasLayout, it should work. try zoom:1;

Javascript, controlling an onbeforeunload tag

I'm trying to set up a onbeforeunload tag to stop a user from leaving specific pages if and only if they have unsaved content, and only on specific pages (we're using a single master page). I quickly discovered that having a return ##anything## in the onbeforeunload tag would always trigger a javascript confirm, and puts ##anything## inside the pop-up. Obviously, this is now expected behavior, but it does take away my idea of using my own confirm box that could be controlled with an if statement.
I tried this, and it didn't work:
<body class="yui-skin-sam" onbeforeunload="document.onFormClose();">
<script>
document.onFormClose = function () {
if (document.getElementById('DirtyFlag').value == "true") {
document.getElementById('DirtyFlag').value == "false";
return 'You will lose all changes made since your last save';
}
}
</script>
where DirtyFlag is a hidden field that turns true if any unsaved changes exist. I'd hoped that putting the return inside the function would do the trick, but no such luck.
So my question is, is there a way to use the onbeforeunload tag with a return built in that will bypass it pending the value of that field?
Alternatively, (though this would be less ideal) I suppose I could add or remove the onbeforeunload tag dynamically, in all the places I set or reset the getElementById tag. Unfortunately, I don't know how to do that either.
Oh, and I'm restricted completely from using jQuery or any other javascript library.

Not sure if this is as designed, but if you return null from the event handler, you might get the results you want:
window.onbeforeunload = function() {
var el = document.getElementById("dirtyFlag");
if (el.value === "true") {
return 'You will lose all changes made since your last save';
}
else {
return null;
}
};
The following works in FF: http://jsfiddle.net/andrewwhitaker/chZJ8/. Try changing the hidden inputs value to "true" and you should start getting the confirmation dialog. However, I cannot get it to work in Chrome and I'm unable to test in IE. It would be great if someone could confirm this works in either of those browsers.
Edit: Adding another example that's easier to use and works in Chrome (the iFrame in JSFiddle was causing issues). Check out the example here: http://andrewawhitaker.com/examples/onbeforeunload_test.html. Type 'true' in the input to see a confirmation. If 'true' is not the value of the input, no dialog is displayed. Works in FF and Chrome, still can't vouch for IE.
Update 2: A more reliable way of doing this is probably to add and remove the event listener when you set the value for dirtyFlag programmatically, just remove or add the event handler appropriately:
var isDirty = function() { ... };
if (/* form is dirty*/) {
window.onbeforeunload = isDirty;
}
else {
window.onbeforeunload = null;
}

You can't change the default behavior of onbeforeunload.
https://developer.mozilla.org/en/DOM/window.onbeforeunload
http://msdn.microsoft.com/en-us/library/ms536907(VS.85).aspx

How to bring focus to a window in jquery?

I am trying to bring focus to window using jquery. The window is popup initiated through a button click on the parent page. I have some ajax calls going on in the child window, so data is being updated. My issue is that if the user clicks on the parent window and hides the child behind it, i would like to bring that child window back to the forefront if there is a data update.
inside $(document).ready I wire up these events:
$(window).blur(function(){
WindowHasFocus =false;
}).focus(function(){
WindowHasFocus =true;
});
Then, if data is updated, I call this function:
function FocusInput(){
if(!WindowHasFocus){
$(window).focus();
}
}
This works as expected in IE8, but in FireFox(and all other browsers) the Blur event nevers seem to fire if I click the parent window. Any suggestions/ideas on how achieve this?
update:
Total facepalm moment:
In FireFox:
* Tools
* Options…
* Content tab
* Advanced button next to “Enable JavaScript”
* check the box named "Raise or Lower Windows"

Total facepalm moment: In FireFox:
Tools
Options…
Content tab
Advanced button next to “Enable JavaScript”
check the box named "Raise or Lower Windows"
This is turned off by default and must be enabled. And also, i assumed that since it didnt work in Chrome, that Safari would be the same, but you know what they say about "assuming" (it works in Safari, but not Chrome).

If there is not a strong reason for having two separate windows then it would be better use "modal boxes", there are plenty of examples out there and jquery plugins to achieve that. An example of such a plugin:
http://www.84bytes.com/2008/06/02/jquery-modal-dialog-boxes/

You're absolutely correct. In FF, it seems as though it does fire the event, but at that same time, it seems like it doesn't register the element as being focused. Therefore the blur event can never be fired. Not sure I'm even explaining that correctly... The following code says it all.
In this example, the box is hidden by default, but is displayed via the focus event listener. In IE 8, if you click the main window, it still fires blur, but in FF it doesn't:
<html>
<head>
</head>
<body>
<div id="hiddenWin" style="width: 100px; height: 100px; background-color: Black; display: none;"></div>
<script type="text/javascript" src="http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js"></script>
<script type="text/javascript">
var something = 12;
something += 4;
$(document).ready(function()
{
$("#hiddenWin").focus(function()
{
$(this).show();
}
).blur(function()
{
$(this).hide();
}
)
$("#hiddenWin").focus();
}
);
</script>
</body>
</html>
For your need, would it be feasible to setup an overlay background? Something that is a fixed position # top:0 and left:0 which takes up the whole screen and has a z-index that is less than your popup. That way, when they click the overlay, it will steal focus and then you can hide everything...? IDK, just a suggestion. I'll keep messing around and see if I can figure it out. Good question. +1

It seems like you shouldn't care to know when your window got blurred. When your data updates, your window is either not in focus, in which case you want to focus it, or it is already in focus, and focusing it again doesn't hurt you any.

Yeah the modal thing is probably the way to go but sometimes you just need to do it the way you want to do it.
I would use plain old JavaScript. Name the window and the bring it into focus.
function showImageWindow(imageURL)
{
var imageWindow = window.open(imageURL,"My_Window","width=1000px,height=1000px,menubar=0,titlebar=0,toolbar=0,location=0,scrollbars=0,status=0");
imageWindow.focus();
}