On my webpage, I have a "register now" button in the header. On click this button will scroll the user to the bottom of the page and will, ideally, focus on a form field input and open the soft keyboard on mobile devices.
I am currently executing a .focus and .click state to the element after the smooth scroll function ends. While these two statuses are being applied, they are not opening the keyboard as desired.
componentDidMount = () => {
Events.scrollEvent.register('end', function(to, element) {
if(element.id === 'request-demo'){
var inputFocus = document.getElementById('name');
inputFocus.focus(console.log("focused"));
inputFocus.click(console.log("clicked"));
}
Events.scrollEvent.remove('end');
});
}
This function will open the keyboard on Android devices, but not IOS.
I am avoiding jQuery for this project, so vanilla solutions would be preferred
IOS will not allow developers to simulate user inputs within react-scroll's scrollEvent. By removing the focus and click states from within the end of scroll event, we were able to resolve this issue
Our current interpretation is that IOS blocks developers from simulating user inputs within on event functions, however any further insight would still be greatly appreciated
I tried the solution based of lots of examples and the event works only if something else is clicked first eg. a link has been first right clicked on the same page. Then if I click the browser close button it prompts a warning before closing as expected.
Otherwise if I first go to the page or refresh it and click close button it doesn't work and page closes. The code inside onbeforeunload function hits each time but in the last case clearly has no effect.
$("button, a").bind("click", function () {
window.onbeforeunload = null;
});
window.onbeforeunload = function (e) {
e = e || window.event;
// For IE and Firefox prior to version 4
if (e) {
e.returnValue = 'Sure?';
}
// For Safari
return 'Sure?'; // the code hits each time - normally it does have no effect but if right-clicked a link on the page first it does work?
};
It looks as a very strange behaviour. Anyone has idea why this works only when another event has happened on the page first?
Tried in Firefox & Chrome.
It's a feature. According to MDN:
To combat unwanted pop-ups, some browsers don't display prompts created in beforeunload event handlers unless the page has been interacted with; some don't display them at all.
What is the use case where you need the onbeforeunload popup to be shown even with no user interaction? Usually these are for preventing data loss on unsubmitted forms, for instance. If the user wants to leave the page and there isn't any reason to show the popup, you shouldn't attempt to do so.
I'm writing code in JavaScript, targeting Chrome.
Now, consider what happens when:
I press Space/Backspace on a webpage vs
I press Space/Backspace on a textbox
BY using (goog.events.listen js/document.body ...) I can listen for Space/Baskspace events and react on them. However, the browse still processes them i.e. when I press Space the browser still scrolls down and when I press Basckspace, the browser goes to the previous webpage.
I would like to prevent this "default behavior" -- i.e. I want to process the Space/Backspace events, and I want the browser to ignore them.
Thanks!
Return false from the event handler to cancel the event.
document.body.onkeydown = function killSpace(e) {
if (e.keyCode === 32) {
return false;
}
};
Please don't kill keyboard shortcuts globally like this. It hurts usability. Only prevent default behaviour when some custom widget on the page has focus, and this element can lose focus using a keyboard shortcut like tab.
Actually, there was (is still) a bug in jQuery: http://bugs.jqueryui.com/ticket/4511.
The reason for this behavior (from the bug description comments): "The dialog itself binds keydown event to itself for closing the dialog on ESC; in addition, the dialog overlay binds a keydown event to the document, without filtering to close only the active dialog."
I cannot come up with an idea of an acceptable workaround. Is there anyone who has had to deal with it yet?
Very simple - upon creating a modal dialog, run this:
$([document, window]).unbind('.dialog-overlay');
If you create more then one modal dialog, hitting ESC will close the top one only.
Then once you focus on the bottom dialog, hit ESC and it will close it as well.
Hope this helped!
P.S. jQuery UI developers should add an option when you want all dialogs close at once upon hitting ESC key or only the focused ones.
Easiest thing is I have added event.stopPropagation(); in close function before return self; in jquery.ui.dialog.js file. And I am done with problem of closing dialog boxes one by one on escape keydown. Let me know if anyone find any better solution.
EDITED:
this need to add because while clicking on close button event object is undefined.
if(typeof event != 'undefined'){
event.stopPropagation(); }
The root of the problem is that jQuery UI keydown event propagates through all dialogs. A fix in the original jQueryUI Dialog code would be to add event.stopPropagation() when topmost dialog was successfully closed and check event.isPropagationStopped() at the beginning of the same keydown event.
As a workaround I did, thanks for Jazzer, the following.
Set dialog option closeOnEscape to false
When dialog gets created, append:
//newDialog is dialog's content, e.g. var newDialog = $('my dialog content>');
newDialog.keydown(function(event) {
if (mydialogs.hasOpenDialogs() &&
event.keyCode &&
event.keyCode === $.ui.keyCode.ESCAPE) {
$(newDialog).dialog("close");
event.preventDefault();
event.stopPropagation();
}
});
when document is loaded do:
$(function(){
//allow for ESC to close only top dialog
$(document).bind('keydown', function(event) {
if (event.isPropagationStopped()) return true;
if (mydialogs.hasOpenDialogs() &&
event.keyCode &&
event.keyCode === $.ui.keyCode.ESCAPE) {
mydialogs.closeTopDialog();
event.preventDefault();
event.stopPropagation();
}
});
});
Event in (2) happens when user hits ESC while typing text in input box inside of the dialog.
Event in (3) happens when user hits ESC somewhere else.
mydialogs here is a wrapper around stack (array) of modal dialogs, where every new dialog adds itself via .push() and in .close() removes itself with .pop().
I have a div that acts like a drop-down. So it pops-up when you click a button and it allows you to scroll through this big list. So the div has a vertical scroll bar. The div is supposed to disappear if you click outside of the div, i.e. on blur.
The problem is that when the user clicks on the div's scrollbar, IE wrongly fires the onblur event, whereas Firefox doesn't. I guess Firefox still treats the scrollbar as part of the div, which I think is correct. I just want IE to behave the same way.
I've had a similar problem with a scrollbar in an autocomplete dropdown. Since the dropdown should be hidden when the form element it is attached to loses focus, maintaining focus on the correct element became an issue. When the scrollbar was clicked, only Firefox (10.0) kept focus on the input element. IE (8.0), Opera (11.61), Chrome (17.0) and Safari (5.1) all removed focus from the input, resulting in the dropdown being hidden, and since it was hidden, click events would not fire on the dropdown.
Fortunately, the shift of focus can be easily prevented in most of the problem browsers. This is done by canceling the default browser action:
dropdown.onmousedown = function(event) {
// Do stuff
return false;
}
Adding a return value to the event handler sorted out the problem on all browsers except IE. Doing this cancels the default browser action, in this case the focus shift. Also, using mousedown instead of click meant that the event handler would be executed before the blur event fired on the input element.
This left IE as the only remaining problem (no surprise there). It turns out that there is no way to cancel the focus shift on IE. Fortunately, IE is the only browser that fires a focus event on the dropdown, meaning focus on the input element can be restored with an IE-exclusive event handler:
dropdown.onfocus = function() {
input.focus();
}
This solution for IE is not perfect, but while the focus shift is not cancelable, this is the best you can do. What happens is that the blur event fires on the input, hiding the dropdown, after which focus fires on the now hidden dropdown, which restores focus on the input and triggers showing the dropdown. In my code it also triggers repopulating the dropdown, resulting in a short delay and loss of the selection, but if the user wants to scroll the selection is probably useless anyway, so I deemed this acceptable.
I hope this is helpful, even though my example is slightly different than in the question. From what I gathered, the question was about IE firing a blur event on the dropdown itself, rather than the button that opened it, which makes no sense to me... Like my use of a focus event handler indicates, clicking on a scrollbar should move focus to the element the scrollbar is part of on IE.
Late answer, but I had the same issue and the current answers didn't work for me.
The hover state of the popup element works as expected, so in your blur event you can check to see if your popup element is hovered, and only remove/hide it if it isn't:
$('#element-with-focus').blur(function()
{
if ($('#popup:hover').length === 0)
{
$('#popup').hide()
}
}
You'll need to shift focus back to the original element that has the blur event bound to it. This doesn't interfere with the scrolling:
$('#popup').focus(function(e)
{
$('#element-with-focus').focus();
});
This does not work with IE7 or lower - so just drop support for it...
Example: http://jsfiddle.net/y7AuF/
I'm having a similar problem with IE firing the blur event when you click on a scrollbar. Apparently it only happens n IE7 and below, and IE8 in quirksmode.
Here's something I found via Google
https://prototype.lighthouseapp.com/projects/8887/tickets/248-results-popup-from-ajaxautocompleter-disappear-when-user-clicks-on-scrollbars-in-ie6ie7
Basically you only do the blur if you know the person clicked somewhere on the document other than the currently focused div. It's possible to inversely detect the scrollbar click because document.onclick doesn't fire when you click on the scrollbar.
This is an old question but since it still applies to IE11 here is what I did.
I listen to the mousedown event on the menu and set a flag on this event. When I catch the blur event, if the mousedown flag is on, I set the focus back. Since Edge, FF and Chrome won't fire the blur event but will fire the mouseup event (which IE won't), I reset the mousedown flag on the mouseup for them (on the blur for IE).
mousedown: function (e) {
this.mouseddown = true;
this.$menu.one("mouseup", function(e){
// IE won't fire this, but FF and Chrome will so we reset our flag for them here
this.mouseddown = false;
}.bind(this));
}
blur: function (e) {
if (!this.mouseddown && this.shown) {
this.hide();
this.focused = false;
} else if (this.mouseddown) {
// This is for IE that blurs the input when user clicks on scroll.
// We set the focus back on the input and prevent the lookup to occur again
this.skipShowHintOnFocus = true; // Flag used to avoid repopulating the menu
this.$element.focus();
this.mouseddown = false;
}
},
That way the menu stays visible and user doesn't loose anything.
Use focusout, and focusin (IE specific events)
$(document).bind('focusout', function(){
preventHiding = false;
//trigger blur event
this.$element.trigger('blur');
});
$(document).bind('focusin', function(){
preventHiding = true;
});
$(document).bind('blur', function(){
// Did anyone want us to prevent hiding?
if (this.preventHiding) {
this.preventHiding = false;
return;
}
this.hide();
});
I had the same probleme. Resolved by putting the menu in a wrapping (bigger) div. With the blur applied to the wrapper, it worked!
Perhaps try adding the tabindex attribute set to -1 to the div node.
I don't think this is an IE issue.
It's more a case of how to design your interaction and where to handle which event.
If you have a unique css-class-accessor for the related target, canceling a blur event can be done by checking the classList of the event.relatedTarget for the element you want to allow or disallow to initiate the blur event. See my onBlurHandler from a custom autocomplete dropdown in an ES2015 project of mine (you might need to work around contains() for older JS support):
onBlurHandler(event: FocusEvent) {
if (event.relatedTarget
&& (event.relatedTarget as HTMLElement).classList.contains('folding-select-result-list')) {
// Disallow any blur event from `.folding-select-result-list`
event.preventDefault();
} else if (!event.relatedTarget
|| event.relatedTarget
&& !(event.relatedTarget as HTMLElement).classList.contains('select-item')) {
// If blur event is from outside (not `.select-item`), clear the suggest list
// onClickHandler of `.select-item` will clear suggestList as configured with this.clearAfterSelect
this.clearOptions(this.clearAfterBlur);
}
}
.folding-select-result-list is my suggestions-dropdown having 'empty spots' and 'possibly a scrollbar', where I don't need this blur event.
.select-item has it's own onClickHandler that fires the XHR-request of the selection, and closes the dropdown when another property of the component this.clearAfterSelect is true.