Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    Regular Coder
    Join Date
    Aug 2010
    Location
    Southern Oregon
    Posts
    305
    Thanks
    63
    Thanked 1 Time in 1 Post

    blur and click events?

    I have a text input field that I have a blur event handler assigned to it.
    I also have a button with a click event handler.
    So the text input field is focused when I click in the field.
    Now I click on the button.
    That causes the text field to blur.

    I want to prevent the blur handler code from running if then there is a click
    on the button.

    If I can, How would I do this? I don't understand event bubbling up
    and trickling down. But I suspect this wouldn't apply because the
    elements are separate in a sibling relationship.

    I am suspecting that I would have to determine the mouse
    coordinates when the blur occurs and dope out if it is over
    the button. But that seems a bit messy and complicated.

    Thanks for time and attention
    JK

  2. #2
    Regular Coder
    Join Date
    Aug 2010
    Location
    Southern Oregon
    Posts
    305
    Thanks
    63
    Thanked 1 Time in 1 Post

    I worked out using mouse position relative to input text field

    I managed to get the idea of using mouse coords relative to button element position
    and height/width to determine if blur code should run:

    But I discovered that e.pageX and e.pageY don't seem to be available in the blur
    event. I also tried e.screenX and e.screenY without success.

    I put a mousemove event listener on the document and save the coordinates in
    an object variable. So, now the blur code can look at this object variable and
    compare to button element dimensions and position to decide if blur code should
    run. It is messy and complicated.

    Does anyone have a simpler suggestion?

    Thanks for time and attention
    JK

  3. #3
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,008
    Thanks
    3
    Thanked 427 Times in 416 Posts
    Given that keyboard access (hitting tab) would utterly banjax your mouse based position solution... not a great idea. Just like how ctrl+enter bypasses onclick on a button which is why you trap onsubmit on the form instead.

    What you should PROBABLY be testing for is Event.target inside the event handler. It's important to know the difference between event.target and event.currentTarget.

    Event.target is the Element that triggered the event -- since clicking on or tabbing to the button is what triggers the event, that SHOULD be your button or whatever else is causing the input to lose focus.

    Event.currentTarget is the Element the event handler callback is assigned TO.

    The only problem with this is that browsers can be... unreliable in assigning Event.target properly even when it is "supported". Also if you need to polyfill for legacy IE you'd be looking at Window.srcElement, and that isn't always correct. Legacy IE doesn't even HAVE a 'currentTarget' equivalent!

    In fact yeah, I just tested it and for 'blur' it returns the input, not the button. Bugger it all.

    Generally though what you are describing for behaviors isn't something I'd be putting into a website in the first place. It's FAR too easy to start throwing JavaScript at nothing or for things you THINK are going to make it easier/simpler whilst just pissing off users! though if this is for an application not a website, forget this whole paragraph.
    Last edited by deathshadow; Apr 15th, 2018 at 03:40 AM.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  4. #4
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,008
    Thanks
    3
    Thanked 427 Times in 416 Posts
    aha, I spit out the output from a blur event and discovered this "new" property I was unaware of.

    https://developer.mozilla.org/en-US/.../relatedTarget

    doesn't work in legacy IE, but should point at the actual Element that is clicked when a blur occurs.

    Code:
    <!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
    <title>Blur Demo</title>
    </head><body>
    
    <fieldset>
    	<label for="test1">Test Input:</label>
    	<input type="text" id="test1">
    	<button>Go</button>
    </fieldset>
    
    <script>
    document.getElementById('test1').addEventListener('blur', function(e) {
    	console.log(e.relatedTarget);
    }, false);
    </script>
    
    </body></html>
    Supposedly it works all the way back to IE9. Just test if e.relatedTarget is the same as the button when you want the button ignored.

    -- edit -- and if you need to polyfill for legacy IE, window.srcElement (what's usually treated as Event.target in polyfills) DOES point at the button not the input.
    Last edited by deathshadow; Apr 15th, 2018 at 03:51 AM.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  5. #5
    Regular Coder
    Join Date
    Aug 2010
    Location
    Southern Oregon
    Posts
    305
    Thanks
    63
    Thanked 1 Time in 1 Post

    Thanks for suggestions....

    Thanks for the suggestion about event.relatedTarget. I was aware of event.target and event.currentTarget
    But it didn't seem to apply here because the blur event handler is supposed to decide if it should run or not.
    What I have seems to be reliable.

    I could add elements like check boxes to distinguish between text field input blur and button click. But I am thinking
    about sites like Google that populate select/option elements with search term suggestions under the search box
    as you type.

    Also, as I remember, tabbing to an element and hitting return requires keypress and/or keydown/up listeners and handlers.

    This interface does not use any forms. The buttons are generic buttons managed by javascript.
    All the other input elements and elements normally assumed to be in forms are managed by javascript.
    Accept for initial load, all of the interaction with server is via async requests managed by javascript.

    This is a content management system that requires authorized and technically knowledgeable users who would
    be prepared for how it works. Right now it is only used on my localhost servers as a development project.

    At present, my web site is not on line due to lack of hosting service. When I get it back on line I plan on posting
    demo versions of the projects and modules I have been developing.

    Thanks for time and attention
    JK

  6. #6
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,008
    Thanks
    3
    Thanked 427 Times in 416 Posts
    Quote Originally Posted by anotherJEK View Post
    But it didn't seem to apply here because the blur event handler is supposed to decide if it should run or not.
    Thing is, if you know WHAT was clicked on or navigated to that caused the blur, you can choose to ignore it! REGARDLESS of if it was triggered by the keyboard, mouse, puffer stick, touch, fingerbar, or some future device we've not even thought of yet.


    Code:
    document.getElementById('test1').addEventListener('blur', function(e) {
    	if (
    		e.relatedTarget &&
    		e.relatedTarget.tagName == 'BUTTON'
    	) {
    		console.log('Ignoring blur, you clicked on a button');
    	} else {
    		console.log('Taking blur action');
    	}
    }, false);
    Though tabbing to the button without clicking on it would result in an ignore... Shame the blur event fires BEFORE the click.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com


 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •