I am having a div which contains an input element and span element as children. The input and span are siblings(having common parent div). So i am having a blur event on div and i am having tabindex 0 on span element. So when my focus is on input element and when i tab the focus shifts to span but the blur event is fired.
Is this event firing expected when tabbing between sliblings?
React Code:
<div className="box-v2"
tabIndex={-1}
onBlur={this._onBlur}>
<input ref="inputBox"
className="input-box"
spellCheck={false}
value={this.state.text}
onChange={this._onChange} />
<span className="icon"
tabIndex={0}/>
</div>
In the world of React JS, we can assume that it indeed is expected. If it makes sense, is another story.
Reason:
Native focus and native blur events don't bubble. Corresponding React event handlers onFocus and onBlur do bubble - dun dun dun.
(Source: https://github.com/facebook/react/issues/6410#issuecomment-207064994)
I created a WebpackBin where you can test and compare the behaviour:
https://www.webpackbin.com/bins/-KoJBHpK9s_OA76FnLkv
Open your browser's dev console, webpackbin cannot show the console.log of the iframe, I wanted to show both examples "side by side".
As you can see, the React behaviour is the one you described. You focus the input field and if you tab to the sibling span, it will fire the onBlur event.
But in the native code, this is not what happens. If you focus the input there and then tab, nothing happens (except moving the focus to the sibling span, of course.
If you focus the div and then leave the focus again, then it will fire the onBlur event too.
Related
When I fire a focus event from a top level input field in Vue 3:
<input #focus="$emit('focus')">
...the event is fired once when the input field is focused (as I would expect).
However, when you put this same input field into a child component and focus it:
<InputField #focus="$emit('focus')" />
...the event is fired twice.
See https://stackblitz.com/edit/vue-wjhche?devToolsHeight=33&file=src/components/HelloWorld.vue
Can you please help me to understand why this is happening? Thanks!
So, you shouldn't put a focus event in the child component, and also in the input field too, as the child component already will bind its focus event to the input so the focus event will be called twice, as the input is the root element.
Just removing the focus event from the input will solve the issue.
https://stackblitz.com/edit/vue-676vsb?file=src/components/InputField.vue
I have a row of <a> elements which have onclick handlers:
<a onclick="selectCoin('MER');">
<div id="MER">
...
</div>
</a>
The interior of the <div> child gets overwritten continuously to update some text inside the buttons. The updating is done by querying the #MER selector, and assigning to innerHTML. I noticed that the onclick handlers don’t always run if the <div> element is being updated in the background. Oftentimes, I have to click it two or three times before the onclick hander actually gets invoked. If I make the <div> elements static, the onclick handlers run consistently and reliably.
Why does updating the <div> child cause the onclick handler to stop working consistently? How do I fix this issue, while still updating the contents of the button?
To generate a click event, an element must receive a mousedown followed by a mouseup.
If the element goes away after the mousedown and is replaced with a new one, the click event is not sent.
You could do your own mousedown/mouseup detection on the <a> element, but if nothing inside the element is really clickable, you can disable mouse events on the child elements, so that they all occur on the <a> element
on your "MER" div:
style="pointer-events:none;"
Working fiddle:
https://jsfiddle.net/8h17rcpz/
click events are only generated if a mousedown and mouseup pair of events are fired consecutively on the same element, which is not going to happen if it gets swapped between down and up events.
The simplest solution would be to replace onclick in HTML source with onmouseup. What side effects or undesirable behavior that might produce is not possible to assess from the information provided.
Please advice how to keep focus on textarea element after clicking specific button. For my mobile app I use Quasar vue based framework.
Tried to apply preventDefault
<q-btn #click.prevent="handleClick" label="click me" />
and stopPropagation
<q-btn #click.stop="handleClick" label="click me" />
But in any case textarea losses the focus after button click.
Codepen: https://codepen.io/olegef/pen/NWNvxJM
UPD:
workaround with forced focus causes side effects on mobile like blinking embedded keyboard. That is why I'm looking for option with permanent focus.
UPD2:
it works just fine if I use simple div as a button and mousedown event instead of click
As Mr. Polywhirl mentioned in the comments, that's because after click, the button has the focus. One way to return the focus to the input is like this:
Add ref attribute to your input:
ref="myInput"
So your input becomes:
<q-input
ref="myInput"
v-model="text"
filled
type="textarea"
>
</q-input>
Then in the handleClick method add this line:
this.$refs.myInput.focus();
The question author left the update "it works just fine if I use simple div as a button and mousedown event instead of click". In fact, the desired effect can be achieved using a button element. Here the mousedown event is prevented, to stop focus being lost from the text area, while the click handler is invoked as normal:
<q-btn #mousedown.prevent #click="handleClick" label="click me"></q-btn>
This can be seen in this forked codepen. (The second button has the above fix.)
I have inner input field and a wrapper div element.
I have added contenteditable attribute to the div element in order to be able to set focus on it.
I would like to catch the onblur event of the div.
Now, If I'm in focus on the input field and click with the mouse on different place in the screen
the blur event of the input field is called of course but not the blur event on the div.
Of course this makes sense - this is how the browser works.
But anyway,
I was wondering if and how it is possible to achieve that.
<div id="wrapperDiv" contenteditable class="wrapperDivClass">
<input id="innerId">
</div>
For blur event to fire on an element, the element needs to receive focus first. But elements do not receive focus by default.
You can add tabindex="0" or contentEditable to your div so it will receive focus.
See it in action: http://jsfiddle.net/t25rm/
Answered here:
Div - onblur function
Issue solved when I changed the blur event to focusout
From MDN web docs:
The focusout event is fired when an element is about to lose focus. The main difference between this event and blur is that the latter doesn't bubble.
This is exactly what I needed.
I have a text type input field and a checkbox.
If I change the text and then click outside the input box (or press enter or tab) the change event is thrown. But if I enter some text and then click directly on the checkbox using the mouse, only the checkbox change event seems to be thrown.
I have the following code:
<input type="text" name="text" class="update">
<input type="checkbox" name="check" class="update">
and this jQuery:
$('.update').change(function(){
console.log($(this));
});
Is this a known problem, and how can I make sure all change events are fired/thrown/caught in this setup?
To fire user changes, use the input event:
$('input').on('input',function(){...})
To fire code changes, use the DOMSubtreeModified event:
$('input').bind('DOMSubtreeModified',function(){...})
If you want to fire both user and code changes:
$('input').bind('input DOMSubtreeModified',function(){...})
The DOMSubtreeModified event is marked as deprecated and sometimes quite CPU time consuming, but it may be also very efficient when used carefully...
I'm not sure if I get it. But for me when I try to type in textfield and then click checkbox by mouse both events are fired. But you have to keep in mind that event 'change' for text input means that this input has to loose focus, as long as field is focused no change event ever will be triggered. This somehow might be your case. Checkboxes/radioboxes work different way tho. No need to loose focus.
Cheers.
P.S.
My test case:
http://dl.dropbox.com/u/196245/index16.html
The change event fires for both because you're listening to the update class.
The change event will not fire unless the input focus switched to other controls