On my homepage I have a form with a search textbox. If you click on the input and start typing when the page in still loading, something steals the focus so you have to click back in the input textbox.
Is there a way to prevent this from happening? Do I need to find what is stealing the focus?
Sounds like one of your scripts is setting something to focus on load.
Put this at the bottom of your HTML right before </body>. Your console will show you the HTML of the item that is gaining focus.
<script>
$(window).load(function() { // NB not document ready
console.log($(':focus')[0]);
// alert($(':focus')[0]); // if you don't know what console is
});
</script>
Hopefully there will be an ID in the element that you can search your script for, or enough clues to let you find what's being told to focus on load. Then you can remove/alter that line.
Addendum
It turns out this is the culprit
$('#f input#livesearch').clearableTextField();
That clearable function is only ever going to be required if the user uses that field, so let's make it contextual, i.e. only when it's given focus, make that function available. This should stop the naughty plugin stealing focus.
$('#f input#livesearch').on('focus', function(){
$(this).clearableTextField();
});
It's generally best to write contextually - you'll find pages with dozens of binds and "live" events being set up on onload, but they are rarely used. If it's something that doesn't need to happen until the user does something or until you can tell a user is about to do something, write it that way.
Related
Problem:
By default in instantsearch.js, the reset button in the search field is hidden until you start typing. However the submit button doesn't hide, causing them to overlap, this seems default behavior(?)
Here is a demo that demonstrates the issue:
https://codesandbox.io/s/quizzical-leakey-7shzr
Expected Outcome:
I want the search submit button to replace (toggle) with the reset button on typing.
Things I've tried:
I have looked through the documentation and can't find any solution to this. There is a showReset and showSubmit parameters as seen here: https://www.algolia.com/doc/api-reference/widgets/search-box/js/ but these just disable them completely.
Changing the template for them in the widget, only stylizes them, rather than adjust their function.
I do have a heavy handed solution I've written in jquery below but my question is: Is there a way to configure this behavior in instantsearch.js?
$( ".ais-SearchBox-input" ).on("keyup", function() {
if($('.ais-SearchBox-input').val().length > 0){
$('.ais-SearchBox-submit').addClass('none');
}else{
$('.ais-SearchBox-submit').removeClass('none');
}
});
$(document).on('click', '.ais-SearchBox-reset', function() {
$('.ais-SearchBox-submit').removeClass('none');
});
The submit button is initially designed to be on the left hand side of the searchbox, and the reset one on the right hand side, as you can see in the InstantSearch.js SearchBox Storybook. In your demo, there's custom CSS that aligns them both on the right, which is why they're overlapping. But they're two orthogonal concepts, so they weren't designed to replace one another out of the box.
Your solution is fine, although I understand that having imperative logic like this on top of InstantSearch.js might feel icky. Another approach is to directly hook into the rendering logic of the widget by using the connectSearchBox connector. You'll be able to fully control what is rendered, and you'll have access to query which you'll be able to leverage to decide whether to show one button or the other.
My advice is to start from the full example and adapt it for your use case.
I was reading the documentation of the .on event handler of jQuery and I started playing around with it.
I have a simple <select> element with the multiple attribute set to true.
However, I want the user to be able to select multiple items without having to press the ctrl or shift key(s)
According to the .on documentation, if you specify a selector it will automatically add those event handlers to any new items added inside that container that match the selector specified.
So in my case, I could for example decide to replace the <option> elements available in the listbox, but I still want to have the same functionality for those options without having to rebind those events etc.
One might think that the following snippet should do the trick (atleast, I did):
$('#dropdownlist').on('mousedown', 'option', function(e){
e.preventDefault();
$(this).prop('selected', $(this).prop('selected') ? false : true);
return false;
});
So when a users clicks on an option in that listbox, the default action will be cancelled and depending wether the item is already selected or not, it will invert that selection.
I have created a small fiddle demonstrating this behaviour: fiddle
In that fiddle, the first dropdownlist is behaving as expected, but the functionality is lost when replacing the items. This only works in FF & Chrome.
The second dropdownlist is how I thought it should've been (event handling wise), but that doesn't seem to work besides in Chrome -.-
The functionality is kept when replacing items, because the console will still log '2' when clicking on an item after replacing them.
Can someone explain me why this is happening? Am I doing something wrong?
Please point me in the right direction!
Thanks!
~ Dirk
IE doesn't respect the mousedown event on the option tag itself. You've got to use the OnChange event of the select tag, which is not what you (nor I) want. I was trying to do the exact same thing as you and was stopped at every attempt. I finally gave up and made it a list of checkboxes because I can get the same behavior out of mine that you are trying to do here.
You can see this question for some options, but I never did get it to work the way you are describing.
Let me start off by saying that the code in question is part of a UserScript and, as such, normal DOM rules and Javascript methods do not work.
Here is the situation:
I have written a UserScript that interacts with an online chat site. I have a number of button that are generated within the user script. Some of these buttons are located inside of a form, while many of them are not.
Elements added through GreaseMonkey live in two worlds -- they live on the page DOM and they live in the slightly elevated world of UserScripts, which mean that these lines:
event.preventDefault = true;
event.stopPropagation = true;
prevent the rest of the UserScript actions from running, but it does not stop the button from causing a form submit.
As a work around, I am building span elements instead of a button. This works, but it really breaks the visual layout of the chat room.
Does anyone know a way to prevent elements added by UserScripts to prevent form submissions? Failing that, I'll dream that someone knows how to make a span look like a native button.
Edit: I have a solution which seems to be working -- but I haven't fully tested it under every UserScript environment:
// Yes, yes, poorly named but it was a SPAN
// userWindow is an alias for unsafeWindow.
// (Used to run under a userScript environment for IE and I had to emulate a lot)
var span = document.createElement("input");
span.value = text;
span.type = "button";
span.className = "cpbutton";
// Add it to the body just long enough to set up a page-level, DOM0 event handler
var body = userWindow.document.getElementsByTagName("body")[0];
var tname = "IAmTheVeryModelOfAModernMajorGeneral";
span.id = tname;
body.appendChild(span);
userWindow.document.getElementById(tname).onclick = function() {return false;};
body.removeChild(span);
span.id = "";
See the W3C spec for <button>.
By default, a <button> element acts as a submit button inside a form. This means that event.preventDefault() (the correct usage, BTW), on the click handler, may not be enough to stop the form submit.
In that case you could intercept the form's submit event too BUT, the smart thing to do is to use the type attribute to tell the browser not to treat the button as a submit button.
EG:
<button type="button">Your button markup</button>
when you say
to prevent elements added by UserScripts to prevent form submissions
i'm not sure if you want to allow or prevent submiting the form...
anyway, here is a link and a div disguised as a button: http://jsfiddle.net/RASG/PvhUb/
and if you post some of your code, i can help you with your script.
I have a page with some generated HTML that survives the form's reset button. It is a problem because that HTML is inconsistent with the values in the cached default form.
In principle I guess it could be solved easily if I could force a hard reload from the server when the user presses the reset. However I see that the Chrome browser does not support the onReset event (in fact it is deprecated in HTML5).
But perhaps I could work around the missing onReload event. Can I re-define what happens when the reset button is pressed? In my case the apply and reset buttons are located in general HTML templates which I cannot change. Can I attach a function to the button from JavaScript?
You can replace the "reset" button , by a regular button.
And use the "onClick" event, to trigger a page reload.
EDIT
oops I missed the template part,
You can add a function to a button from Javascript.
First you need to "get" the button, with something like document.getElementbyId('resetButton');
If the button doesn't have a ID, you still can to retrieve it by doing javascript dom traversal
then you can add a function like :
var resetButton = document.getElementbyId('resetButton');
resetButton.onclick= reloadPage;
function reloadPage(){
window.location.reload();
}
I have some HTML that looks like this:
<a onclick="FB.Connect.logout(function() { window.location = '/'; });">
link text
</a>
logout brings up a modal that tells the user he's logging out of Facebook and has "close" button on the bottom right. Unfortunately, the browser proceeds to '/' per the callback function. How can I stop that from happening so that the user has enough time to read what's in the dialog?
Also, the close button seems kind of useless since it gets blown away once the callback gets called, so I feel like I'm missing something there...
PS: This seems like a long shot, but I'd like the user to be able to stop the log out process if having to log out of fb changes his mind. Is there a way to do that?
Have you tried the pound sign? # This tells the browser to redirect to an in page anchor..and doesn't generally redirect anywhere. This might work for you!
If you're performing an action rather than going to a location, I'd recommend using a <button> element.
With Prototype:
<button id="button-logout" value="Logout" />
function finishLogout(isLoggedOut){
if (isLoggedOut) {
location.href = "/goodbye";
}
}
function beginLogout(){
//preparation if necessary.
FB.Connect.logout(finishLogout);
}
$('button-logout').observe('click', beginLogout);
It's always better to have your events in the javascript rather than inside your tag's onclick. And, although I did make two seperate functions, it's easier to revise and reuse them later, and you can always minify them if you're looking to optimize.