I'm trying to make a simple page with two jQuery Dialogs with the functionality of changing their titlebar colour when each gets or losts focus. In other words, focused window has a different titlebar colour which makes it easier to differ which has focus.
I have this code:
$(function () {
$(".window").dialog({
focus: function (event, ui) {
$(this).parents(".ui-dialog:first").find(".ui-dialog-titlebar").addClass("ui-state-error");
}
});
but I don't know how to detect in the focus event whether it it gets or losts focus.
Try this
http://jsfiddle.net/JqQA6/
I needed the same and this solution works.
Try focusin() and focusout()
The dialog focus event is only called on gaining focus. Stock jQuery UI dialog boxes have no concept of losing focus.
A simple solution is to simply remove your ui-state-error class from every dialog in the focus handler and then add it to the one that's just received focus.
I've actually written a full-featured jQuery UI plugin which adds a .blur event to dialog boxes, and handles re-ordering stacked boxes whenever the topmost box is closed. I'll check if I'm allowed to publish it.
Related
I'm working on a note-taking app that uses CKEditor's inline mode to expose dynamically created editable divs. (I'm using CKEditor version 4.5.8.)
When using the inline editor, you can click your mouse away from the div to leave editing mode, which results in the following behavior changes:
The blue highlight around the div disappears
The blinking cursor disappears
Keypresses are no longer "typed" into the div (ie. the editor is now inactive).
But I can't figure out how to escape editor focus (ie. reproduce the above changes) without requiring the user to physically click the mouse. Here's what I've tried so far:
Called Jquery .blur() on the inline-editable element: This visually removes focus and CKEDITOR.currentInstance becomes null; but keypresses still cause characters to be added to the div, which re-activates focus.
Called Jquery .removeClass('cke_focus') on the inline-editable element - no visible effect.
Called Jquery .click() or .focus() on other elements on the page - no visible effect.
Called CKEDITOR.currentInstance.focusManager.blur() - no visible effect.
Called CKEDITOR.currentInstance.container.fire('blur') - no visible effect.
Called CKEDITOR.currentInstance.element.fire('blur') - no visible effect.
Called CKEDITOR.currentInstance.destroy() - it looks like the editor automatically re-initializes after destruction due to the contenteditable="true" attribute, or something like that. At any rate the div retains focus and continues to trap keypresses.
All I want is to recreate what happens when you click away from an inline editing div: the focus indicators disappear, and keypresses no longer add text to the div. Any ideas how I can accomplish this? Thanks in advance!
The trick was to combine the blur with removing all selection ranges that you currently have:
CKEDITOR.instances.editor1.on( 'contentDom', function() {
CKEDITOR.instances.editor1.document.on('keydown', function(event) {
if (event.data.getKey() == 27) {
$(CKEDITOR.currentInstance.element.$).blur();
window.getSelection().removeAllRanges();
}
});
});
And a working example:
https://jsfiddle.net/bwuhp14s/
I am using tinymce wysiwyg html editor and polymer. The editor is shown in a paper-dialog popup. When an item in a tinymce dropdown menu is clicked, the dialog closes and it will not reopen. No errors appear in console. How can I catch the click events to stop it from affecting the polymer dialog?
I tried adding a stopPropogation in the tinymce setup field but that doesn't seem to help.
tinymce.init({
selector: '#' + this.textareaId,
setup: function (ed) {
ed.on('click', function(e) {
console.log("clicked");
e.preventDefault();
e.stopPropagation();
});
}
});
},
Just came across the same problem. It looks like paper-dialog thinks that when you select certain items from TinyMCE drop-down menu, the click happens outside of paper-dialog, so it decides it needs to close.
The quick workaround here would be to set no-cancel-on-outside-click property for dialog (or make it modal). More involved solution would require capturing all click events on TinyMCE element, which I haven't attempted.
This is pretty tricky, so I'll try to explain it well.
I have a web app where I want to allow my users to change background color of some divs. To do so I'd like to use a color picker interface, and I want to use contextmenu event on target divs to open it, as they already have another behaviour attached to click event.
So the idea is to have an input type color hidden in the screen, attach its click event to contextmenu event on target divs and change background color of target divs on input type color change event.
The funny thing is that when I try to chain events, color picker doesn't open if its click event is called from within contextmenu event handler, but it does if called from within click event.
Using jQuery for code simplicity and clearness:
//this works perfectly, color picker opens
$("#myTargetDiv").on("click", function() {
$("#inputTypeColor").trigger("click");
});
//this fails miserably
$("#myTargetDiv").on("contextmenu", function() {
$("#inputTypeColor").trigger("click");
return false;
});
The most weird fact is that, if I use a third element to pass the event, say, for example that I call to an intermediate input type text which passes the call from myTargetDiv to inputTypeControl, the click event in the intermediate element fires (even when called from within contextmenu event handler) while the event in the input type color doesn't fire.
But if you click directly on the intermediate input type text the color picker opens!
//If you right click on myTargetDiv "firing!" appears on console, but color picker doesn't opens
$("#myTargetDiv").on("contextmenu", function() {
$("#intermediateElement").trigger("click");
return false;
});
//If you click on intermediateElement, however, the color picker opens!!!
$("#intermediateElement")on("click", function() {
console.log("firing!");
$("#inputTypeColor").trigger("click");
});
I've reproduced this behaviour in Firefox and Chrome, and I'm not very sure if it's an expected feature, a bug in browsers input type color implementation or a problem with event handling from jQuery (I haven't tried launching the events myself yet).
https://jsfiddle.net/bardobrave/0z6ev4rd/1 If you click on "FIRE!" the color picker opens, but if you right click on it the color picker doesn't opens despite if you click on input type text it does.
Anyone can give some insight on the matter?
So to execute your own contextual menu, you may want to bind to the following:
$("#firestarter").on("contextmenu", function(e) {
// Execute your menu with Color Picker Option
return false;
});
This could be something simple like a List wrapped in a div, or more complex like JQuery UI Menu.
<div id="menu">
<ul>
<li class="menuItem" id="menuOption-1" data-action="color" data-rel="#myColor">Select Color</li>
<li class="menuItem" id="menuOption-2" data-action="reset">Reset to Default</li>
</ul>
</div>
Now the user has something to click on, which can be carried over:
$("#menu li.menuItem").on("click", function(){
switch($(this).data("action")){
case "color":
$("#menu").hide();
var target = $(this).data("rel");
$(target).trigger("click");
break;
case "reset":
$("#menu").hide();
// Do something else
break;
default:
$("#menu").hide();
}
});
I have not found all the details on the HTML5 input type='color'. This is a good start: https://www.w3.org/TR/html5/forms.html#color-state-%28type=color%29 I suspect that since the Color Picker dialog is generated by the browser itself as well as a Contextual Menu, I am guessing it's a security or control feature that is preventing it being triggered by a Right-Click type of event.
Ok, I've found a way to fix the functionality.
To trigger color picker opening through a div context menu event.
As this event cannot call the input type color click event (for reason unknown), a feasible solution is to add a hidden div which pops on mouse position when context menu event is called on target div.
This hidden div poses as a context menu and can include a message: "click to open color picker" or something like that.
Then, you attach color input click event to this hidden div click event.
Coming from another click event, the color picker opens correctly, you've forced your user to make one click more than desired (one right click to open the fake context menu and another one to open de color picker), but functionality works in the end and it's quite consistent with the effect seeked.
The real question still applies:
Why input type color click event fires when called from within any other click event handler but fails if called from within context menu event handler?
Some DOM events require user interaction to be fired programmatically,, i.e. you can trigger a click programmatically only in the process of handling some other click or keyup etc.
I have a site menu which sits underneath an overlying and is revealed by clicking on a button on the overlying , which slides it aside.
What I want to do is, while the site menu is open, prevent the overlying (everything but the menu button, ideally) from being interacted with.
I can do this by hiding and showing a container that sits over top of all the overlying content, but I was wondering if there's a way to just set some sort of property with CSS (best option) or javascript to disable click / touch events on the overlying . Any ideas?
You could use a JQuery modal overlay to prohibit the user from using anything else but whatever is in the modal div.
http://jqueryui.com/demos/dialog/#modal
When the menu is open, add this attribute to whatever controls you would like to disable
onclick="return false;"
Then remove the attribute when the menu is closed. This will prevent the default action from occuring.
You can do this without adding an attribute by using this code:
document.getElementById("myElement").onclick = function() { return false; }
CSS is about the look, not the behavior. So you can't enable or disable elements by applying CSS to them.
Your solution with an overlay is quite capable, i would do it this way too. Note that your overlay can be transparent or semi-transparent.
It is possible to be solved by overriding the click event with Javascript, but why bother creating a complicated solution (you'll have to redefine the onclick event on every element and then somehow set it back to normal) if you've already got a short clean solution?
As mbsurfer has already suggested, a quick way of disabling everything except your menu is to use the jQuery UI's .dialog with the modal option:
$(function() {
$( "#menu" ).dialog({
modal: true
});
});
More info in the docs: http://api.jqueryui.com/dialog/
I am using jquery and both blur and focusout functions require an extra click after the select box is closed to fire. Is there another way to detect when the select box is immediately closed?
As #samsquanch and #bfavaretto point out in comments here, there seems to be no way to reliably detect, across the current browser generation, when a select list is closed. Which is mildly mind-boggling, but there you are.
I think you're looking for .change(). This will just after you choose any option.
$('select').on('change', function() {
// code
});
And if you want to trigger a change event on page load just try:
$('select').on('change', function() {
// code
}).change(); // trigger initial change