I have a form that I create within a Bootbox (itself a layer on top of Bootstrap's modal). Once it is created, I call
$('#myForm').validate()
on it.
The desirable part of the behaviour is that now as the user tabs through the forms, they can see immediate feedback that they've messed up one of the fields. Entered a non-email address before hitting "tab" or clicking elsewhere? Warning and error message. Great!
But the undesirable thing is that the blur eats other events. So, if a user instead chooses to hit "cancel" (knowing full well that the form is invalid), the click on the cancel is not heard and its handler will not fire. A second click (now that the focus is off the form altogether) and cancel fires as expected. I don't want the users to have to click twice.
I saw a technique for disabling the blur altogether, but then the desirable behaviour described above is then lost, which I do not want either. Ideally, a "well, I blurred, but I also know what the user was clicking" is what I'm after.
[EDIT TO ADD:]
It has come to my attention that this is confusing, so let me try a different approach to the question: is it possible to be working on a form (that has had .validate() called on it), then click on any other clickable item on the whole page and have its click handler successfully fire?
[EDIT AGAIN:]
Based on Sparky's demo, I wired up a warning to show below the inputs on blur. So, to see the problem in action, fire up this fiddle: https://jsfiddle.net/bd1fhpu3/
Then click into one of the input fields BEFORE clicking "just a button". Click in an upper sliver of "just a button" to make sure that the warning labels have pushed it out of the cursor's hotspot on release of the mouse button.
Anyhow, this just explains what the problem is. Solving it is probably not within the scope of the question anymore, but it seemed worth sharing in case anybody else comes across this. To solve, I will either need to override Bootbox's click event to be a mousedown event instead of a click (then you don't need to press and release), or I can "Band-Aid"(tm) the solution by avoiding relocating the button. Maybe a static-height dialog that's tall enough to accomodate the form and any possible warnings. Definitely somewhat of a "hack" like this because you just never know if you're going to do other things later that make the problem appear again. But it'd be a quick and easy temp fix.
You cannot use the built in onfocuout function since the JavaScript cannot possibly know the different between focusing out to another field and focusing out to the cancel button.
You'll have to completely disable onfocusout and write some custom event handlers.
Your code is sparse, so my answer will be very generic.
$('#myForm').validate({
// other options here
onfocusout: false; // disable default blur event
});
Then write an event handler that programmatically triggers validation on the form when they focus to an input, and will do nothing when they focus over to anything, like a cancel button.
$('#myForm input').on('focus', function() {
$('#myForm').valid(); // trigger validation on the form
});
However, this will trigger validation on the entire form. If you only want to trigger validation on the one field losing focus, then you're back to square one, because the event only knows focus was lost, not where it's going.
Just for posterity, here's an "answer" such as it is. Maybe it will help somebody SOME day; you just never know.
There is no code that is operating "incorrectly" and therefore there is not really a fix nor code sample to provide. Here's what was happening:
User is in focus in field
User presses mouse button down (but the release action hasn't happened yet)
Blur event fires, which causes form error warnings to appear below the fields. This also had the net effect of pushing the "cancel" button down the Y axis of the screen
User releases the mouse button, which would normally complete the "click" handler.
HOWEVER, in #4, since the "cancel" button is no longer under the cursor, the click event listener bound to the button does not fire.
The demo, for as long as it lives on the internet, will be in a comment below. However, providing a code sample to go with it is pointless. When the demo dies, I will remove the comment.
Possible Steps (workarounds/hacks) that I elected NOT to pursue thus far:
Modify the dialog such that the button does not move when mousedown event fires, meaning the "click" event is completed successfully
Provide custom code that substitutes the mousedown event for the click event on the button. However, this causes a loss of fairly common UI convention
Force user to press ESC to cancel, rather than clicking a button
[credit to Tieson T. via comment] One possible option, if you can use some custom styles on the error messages, is to hide them with visibility: none rather than display: none. The former would hide the text but still reserve the vertical space of the text, which the latter doesn't (hence why your modal is expanding). This would keep the button from possibly shifting during the focusout event. You would wind up with extra whitespace, but you could knock some of that off by removing the bottom margin on the form-group (assuming you're using it)
I'm sure there are other workarounds, but that's a starting point.
Related
In Chrome (85) and FF (80), clicking on a tabbable element gives it focus. Of course, one can focus by tabbing to the element too, and the focus events that come from either seem to be identical (view dump in browser console: the focus event is quite big):
document.getElementById('main').addEventListener('focus', console.log)
focus here
This becomes problematic for the following: I'm implementing a double-click behavior, where one must select an item with one click, then click again to follow it. I'd also like users to be able to use tab + enter or tab + single-click to follow through.
While I'd strongly prefer to use the default browser behavior to do most of the work, given all I'm adding is one extra click, this seems to be impossible to do without listening for keystrokes. This is because if indeed the two above events are indistinguishable, then one can't tell the difference between:
a tab followed immediately by click, and
a single click that generates both a focus and click event.
Event order can't be trusted, and unfortunately FF has focus first before click anyways.
Is there something in the focus or click events that I'm overlooking that I could use to check where that event is coming from?
I ran into an incredibly obscure-seeming bug and want to document it for posterity. Here’s what happened:
I’m displaying an HTML form to the user with many text fields and a submit button at bottom. Just above the submit button is a warning message that appears or disappears depending on whether the user has filled in all the required information. During testing (automated using Capybara, or manual in the browser) I fill in each field down the page, then click on the Submit button, but the first click doesn’t register. A second click submits the form as expected.
I found that if I disable my custom Javascript, no second click is required. After some process-of-elimination I determined that one Jquery line was responsible for the failure: $(‘#warning-message’).hide();. Comment out this line, and filling out and submitting the form works as expected. Re-enable this line, and form submission requires that extra click. What the frak?
I eventually figured out this was because, both during manual testing and when simulated by Capybara-webkit, when you click on an element like a submit button, that’s registered as a specific X/Y coordinate on the screen. You're not clicking on the DOM element, you're clicking on a coordinate. Because of the (lazy) way I set up this page, when I fill out all the required elements then click Submit, upon clicking the submit button a Jquery change event is triggered which causes $(‘#warning-message’).hide();, which in turn causes the submit button to jump up outside of the area that I had clicked on, so the submit event never gets triggered in the first place because the browser doesn't realize that I clicked on a button.
I’m still not clear what to make of this, but it’s definitely not a bug per se, so much as a misunderstanding (on my part) of how browser events are handled. I’ve worked around the issue by wrapping the warning div in a fixed-height container so unrelated Jquery change events can't cause the submit button to jump around.
Anyway I hope this helps someone.
I have a canvas app where I handle window's keyup and other events. This works fine. However, now I've created a popup div with a textarea in it, and I don't want my keyup handling to be active when the textarea is focused (or when the popup is visible).
I could set a bool isPopupVisible and check for that in my keyup handling, but it strikes me that much more elegant would be to just use the standard focus management of HTML. So I tried handling the canvas's keyup event rather than the window's, but now the problem is that the canvas never receives focus (not even if I click on it) so it doesn't receive any key events. Apparently most HTML elements can't receive focus.
What would be a good way to resolve this?
Edit: It now occurs to me that what I want is in effect a modal dialog box, which HTML doesn't natively support. To support this modality, it's normal to implement it manually with a bool as I initially planned. Standard HTML focus doesn't provide for that, even if I could get the canvas to receive focus. Because the user can switch focus back to the canvas by clicking on it even when the popup is still visible (undesirable).
So I guess I withdraw my question.
This question is related to Javascript event handling and flow control, but it is one step beyond. The question that remains unanswered is: when an event is fired and control is returned to the browser, could the browser decide to handle other events first (fired by other scripts or user action) (A), or will it always handle my event directly (B)?
The question is important, because in case (B) you can rely on the fact that nothing has been changed between firing the event and the event handler, while (A) gives no guarantees whatsoever.
My first guess is (B), how else could stopPropagation() and preventDefault() work? But giving it a second thought, it is no hard evidence.
A real-life example of this problem. I am modifying a rich text editor (hallo), and I want it to have these specs:
clicking on an editable text (#txt) will activate the editor, and clicking outside #txt will deactivate it. hallo uses blur and focus events on #txt to achieve this.
Activating the editor opens a toolbar, mousedown on the toolbar (but not on a button) will set a flag that prevents the blur event on #txt to deactivate the editor. The toolbar will return focus to #text.
mousedown on a toolbar button should also prevent deactivating the editor, but it should first wait till the click event, perform its action and then return focus to #txt. Some actions are immediate (bold or italic), while others need extra user input (selecting from a dropdown).
Some of these buttons open a dialog.
...And I want all these elements (editor, toolbar, dialog) to be modular
and easily extendable.
Now in most cases when you close a dialog you want the focus to return to #txt. But in the case where a dialog is opened and you click somewhere else on the page, the editor will close and call the toolbar, including the dialog to close as well. If in this case the dialog would return focus to the editor, it would activate the editor again.
As far as I understand now, the event handling order is at least deterministic. It is not possible that some event gets a delay while others are processed earlier. This is what is meant by 'synchronous'. The exception is of course events like loading a file.
From the perspective of a program component, say the dialog, the situation can be quite unpredictable. It can bind a handler to the open event, and then call dialog("open"), but anything can happen between the call and the handler, if only because the editor has an event handler on the same event.
So my conclusion is 1) yes it is predictable but 2) it needs a sophisticated architecture to implement this.
In general the event model is synchronous and reentrant, meaning that if an event handler causes another event - the second event will be executed synchronously and only after completion will the first event continue executing.
This seems to be what you're trying to describe, in which case (B) is guaranteed.
Relevant source: http://www.w3.org/TR/DOM-Level-3-Events/#event-flow
HTML5 gives us some new input elements to play with, such as <input type=number>. This renders (in Chrome) as a textbox with two cycle buttons inside the textbox, for incrementing and decrementing the numeric value inside the box.
For a personal hobby project, I'm using this control. However, I'm stuck with one issue:
Is there a way to detect the value being changed using a javascript event? I had expected the onChange event to fire, but no such luck. Also, onClick only triggers when the textbox content is clicked, not when the cycle buttons are clicked.
Any ideas? (apart from: hey, it's HTML5 Forms, don't expect anything to work yet!)
Edit: As mikerobi points out below, the onChange event does fire as soon as the element loses focus. Still not quite what I'm looking for, so other comments and suggestions are welcome!
Result of the bugreport: Won't Fix, because the input event is fired when those buttons are pressed. It's part of the HTML5 spec. So problem solved, thanks to mikerobi's sugestion to file the report.
The onChange event gets fired when when the box loses focus, but you probably already know that.
The HTML5 specifies that a number input should be a text box or spinner control, but the spec does not appear to have any guidelines for how a spinner should look or behave, leaving those decisions up to the browser vendors.
It appears that in the Mac Safari, the spin buttons do respond to click events, you might want to file a Chrome bug report, I suspect it was just an oversight.
$.click() works fine. If you click and hold, it doesn't until you release.