Hidden Element Loses Event Listener Once Visible?
I have an issue where select B (dropdown) which is hidden until a specific value is selected in select A. The weird thing is my event listener on select B breaks/stops working when it becomes visible. The form maintains the state of the selects so If select A has the value which makes select B visible then if I reload the page and select B is visible on page load, everything works. I'm not sure how I get the event listener to work when hidden and then becomes visible? Is this a common issue? I tried only attaching the listener once visible but that still didn't work.
ASKER
Unfortunately, I can't show code as it is a 3rd party app and in a dev. env.
>> the weird thing is my event listener on select B breaks/stops working when it becomes visible
Well, it is initially hidden (meaning that you cannot interact with it), how do you know that is not broken from the start (since once it becomes visible it does not work)?
Are you sure you are binding the event listener(s) on the hidden element AFTER the page has loaded? Do you have any javascript runtime errors (not necessarily related to the hidden field)? If you do, fix those errors first.
Also, "inspect" the element in the DOM and make sure that it does not have the "disabled" attribute.
Well, it is initially hidden (meaning that you cannot interact with it), how do you know that is not broken from the start (since once it becomes visible it does not work)?
Are you sure you are binding the event listener(s) on the hidden element AFTER the page has loaded? Do you have any javascript runtime errors (not necessarily related to the hidden field)? If you do, fix those errors first.
Also, "inspect" the element in the DOM and make sure that it does not have the "disabled" attribute.
ASKER
Only thing I Noticed was that I see this in the console "Handling validation rules for reRender event" . I noticed that if I so a settimeout and reattach the listener each time but that isn't optimal at all and only works sometimes!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
HI Hielo.
I don't control the selects as it is a 3rd party web app. <SELECT> A triggers the creation/appearance of different fields in the form, depending upon the choice made. None of the <SELECT> elements created change their options available, they only are displayed/created.
Thanks,
MJ
I don't control the selects as it is a 3rd party web app. <SELECT> A triggers the creation/appearance of different fields in the form, depending upon the choice made. None of the <SELECT> elements created change their options available, they only are displayed/created.
Thanks,
MJ
>> <SELECT> A triggers the creation/appearance of different fields in the form...
creation and appearance are to completely different things/actions. They are not "interchangeable". I mention this because you use a "/" to separate these words as if though they are interchangeable.
"appearance" simply implies that an existing object/node is hidden/shown on-demand, but it is never destroyed.
"creation" implies that a new (in this case) <select> list is created every time. If in fact the <select name="list_B"> is being re-created every time, then that would explain why you would need to re-attach an event listener after selecting from list_A.
>> I noticed that if I do a setTimeout and reattach the listener each time...
This is the reason I suspect that the <select name="list_B"> is re-created every time the selection from list_A changes.
>> I don't control the selects as it is a 3rd party web app...
If you have absolutely no control over the app, then what are you hoping to accomplish here? (Just curious)
If by "3rd party web app" you meant that you have a library or widget embedded on YOUR web app, then you should be able to override the event listener on list_A so that it calls your event listener callback and then YOU take control of list_B.
creation and appearance are to completely different things/actions. They are not "interchangeable". I mention this because you use a "/" to separate these words as if though they are interchangeable.
"appearance" simply implies that an existing object/node is hidden/shown on-demand, but it is never destroyed.
"creation" implies that a new (in this case) <select> list is created every time. If in fact the <select name="list_B"> is being re-created every time, then that would explain why you would need to re-attach an event listener after selecting from list_A.
>> I noticed that if I do a setTimeout and reattach the listener each time...
This is the reason I suspect that the <select name="list_B"> is re-created every time the selection from list_A changes.
>> I don't control the selects as it is a 3rd party web app...
If you have absolutely no control over the app, then what are you hoping to accomplish here? (Just curious)
If by "3rd party web app" you meant that you have a library or widget embedded on YOUR web app, then you should be able to override the event listener on list_A so that it calls your event listener callback and then YOU take control of list_B.
ASKER
Sorry for the confusion some. Some of the elements are just hidden and then made visible while others are dynamically created. For this particular problem, the element is just hidden and made visible. As far as a 3rd party web app, I have no say or control over any of the code. I can only inject my code via a Tag Management System.
Thanks~
Thanks~
https://jsfiddle.net/z_acharki/aeb3m0or/