I have a <div contenteditable class="content"> </div> in my template whose inner HTML is tied to Mongo. When I (dynamically) add a new .content, I'd like to be able to focus it so that the next thing a user types is entered in the contenteditable div.
However, the .focus() event doesn't play nicely with Meteor's rerendering; even SO's hacks don't work: The JS executes without error, but the focus event doesn't seem to trigger anything (or, it does but it's immediately overwritten by Meteor's rendering).
My question is: How can I force focus that div? A plan I considered was setting a tabindex and then artificially tabbing to that element, but I'm hoping to not have to resort to such silliness.
[EDIT] I'm aware of the {{#constant}} tag, but as far as I can tell, that stops the element from being rerendered at all, which is certainly not what I want.
Place focus code into Template.blah.rendered.
Related
I'm using the MDL tab component. After a tab is clicked and it displays the content for that tab, I'd like to set the cursor focus in a certain text input within that tab's content.
My initial approach was just to handle the click event of the tab element and then set focus accordingly. The problem I'm having is that calling .focus() on the text input element isn't working because it tries to set focus before the text element is actually visible, which no browser seems to like doing for you. If I set focus inside a setTimeout() delay it works, but that doesn't feel like a very clean way to go about it.
Is there any kind of event that can be handled for when a tab is clicked and has finished displaying it's contents? I've also looked at using mutation observers to detect when the text input element is visible but browser support for those is fairly limited still.
No there is no such option. I think you have to use setTimeout or setInterval
You can look into the source. Perhaps write your own MaterialTabs constructor and register it.
Material-Design-Lite source, MaterialTab
I think there are also some libs that can do this like jQuery. You can also see
https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver
This works only in modern browser but has a legacy implementation.
I've added this line :
window.dispatchEvent(new Event("tabSelected"));
to the material.js file, at the end of the selectTab() function. This way, the event is fired right after the tab content is shown.
I am making an editor without relying on contenteditable, in order to get a clean, controlled output. So I'm catching all keyboard and mouse events, building a model and creating a DOM view from that model.
Since I need spellcheck, I activated contenteditable in divs in my view. The user doesn't interact with it, because I'm catching all events.
The problem I have is that spellchecking only seems to be activated on user input on the contenteditable div, which in my case happens only when I right-click somewhere on the text (because I'm not catching that). I've found a question that just says we shouldn't expect spellchecking to be active at the beginning - but in my case even when the user types, spellchecking doesn't happens (because he doesn't type in the contenteditable, I'm building it).
HTML spellcheck in contenteditable div not working after span
So is there a way I can trigger an event that would make the browser think the user is interacting with the contenteditable?
Update: that's only for Chrome, in Firefox the spellchecker works even without events directly caused by the user.
Is there a tool (or something in firebug) that will tell me what events just fired and more importantly on what elements they were bound to?
I have a number of javascript "includes", some minified, some not. I am experiencing some odd behaviour that I want to turn off, but I cannot find what is causing it.
I have a form showing in a "popup" and when I try to click on one of the input boxes, the "popup" closes, so some event bind somewhere is causing this.
The problem is, I don't know what element has this spurious event bound to it. The problem also occurs if I click anywhere inside the popup (and on the background mask that is covering the rest of the page, but that's acceptable)
I am using firefox, so anything I can type in the console is also an option. The eventys in the multiple javascript files are done in various ways, some through jquery, some using inline attributes (eg. onclick="..."), some using just javascript.
I certainly don't want to go and add some line of code to every possible event in every javascript file.
I have spent over an hour trying to hunt down this dom element and have already eliminated the obvious ones like the divs containing the popup and the body tag.
DOM modifications can be tracked down using the Break On Mutate option within Firebug. It can be activated by clicking the related button ( ) within the HTML panel. Note that the Script panel has to be enabled for this to work.
There are also several other Break On ... features, which may help you finding the right position within the code for a specific event.
Furthermore Firebug 2.0 introduced an Events side panel, which displays all events bound to the element selected within the HTML panel. If libraries like jQuery are used, it will even allow you to investigate the user-defined function wrapped by the library function in case you enable the option Show Wrapped Listeners as described in the answer to a related question.
Right now, I'm developing a dojo widget that acts as a validation widget for a piece of user information. The main concept is that there is a div with a nested input and a nested div with a further nested input so basically:
<div id="top">
<input name="pass">
<div id="collapse">
<input name="passvalidate">
</div>
</div>
What is supposed to happen is that if there is nothing in pass, then passvalidate should not be accessible and collapse should be be collapsed and hidden. The way I'm making this happen right now is that I am latching onto the keydown event of the pass input field and if the key is tab and the pass field is not empty, the tabindex of passvalidate changes so that it can be tabbed to.
If the validation field becomes selected, and the user tabs again, then they are taken to the top of the page since the actual element for the passvalidate is located at the bottom of the page, far far away from where it seems to be in tabflow.
My implementation works fine. I haven't run into any errors with that which is why I'm only really posting psudocode. However, one of the other developers on the team seems apposed to altering element's tabindex if it isn't necessary. I can't really think of another way to do this without much more complicated and hard coded handlers to make sure that they can't tab into the validation field when they shouldn't.
So the bottomline question is, is altering tabflow with tabindex programatically a safe way to ensure this behavior, or could I potentially run into problems where a browser might adversely react to having its page's tabindexes altered periodically?
I have some questions about focus in general (adhering to WC3 format, screw IE). I'm having problems with unintended actions occurring on a widget i am building (using the Dojo Toolkit), and i believe a better general understanding of focus will allow me to solve my problem myself, so here goes:
First of all, which common HTML element are and AREN'T focusable? I've been trying to throw focus around and it works sometimes, and doesnt work other times...
What is the 'highest' level focusable on a page? For instance, can i focus the window? The <body> tag? Specific to dojo, can you focus an entire widget? If the template is widgeted can you focus just highest level of the template (usually a <div>)?
Can focus be 'removed'? Can i remove focus from all elements/objects on the page until the next object is focused? Can i prevent a element from being focusable (like a button)?
What are all the methods through which i can affect focus? Besides calling the focus() method on elements, can focus be set through HTML attributes or in a CSS?
Thanks in advance for what i hope to be some great answers!
Disabled controls can't receive focus according to the HTML4.01 spec
Firefocus, an extension that works over Firebug, could be a great enhancement if you're asking this sort of questions :) Install, restart and look at the Console
Related to focus is the order in which elements are given the focus, that is the order of tabbing navigation and the tabindex attribute with its values -1, 0 or positive when it exists
Any DOM element can receive focus amongst other some event handlers.
See answer 1.
Focus is passed around and not removed.
Focus can only be set by the DOM using JavaScript.
You can also use dojo.place to put things in the correct for focus.