Tap bleed through to other inputs and scrolling ability on disabled textareas

Two problems I'm hoping someone might have insight into:

1a) There is a textarea below a select/drop-down and the choices extend over the textarea
if a selection is made from that extended area the textarea is then focuses.

1b) Same scenario but with panels. A button that toggles between panels, existing on one panel that is in the same position as a text input on another panel will focus on that text input after the button press.

2. It seems if we have textarea/inputs that are disabled, meaning no edits are possible, the scroller they are part of does not scroll if the user is moving across the inputs. They have to select an area outside them which makes it quite difficult with large textareas

Thanks for any ideas


  • I assume you're on Android. The Android webview does terrible things with text input areas, not really letting anything overlap them.
  • what I did was i modify Popup to fire a global signal whenever it appear, and fire another signal when it's dismissed.

    At the page/upmost parent level of the app to catch the signal and waterfall the signal down to all my custom form elements like my.textarea. Each my.textarea must have a handler to disable itself temporary, and reenable it when the 2nd signal fires.

    To solve the android scroll to form element (aka IOS Focus)
    my.textarea should also have a bubble that fire when it's focus. Assuming all our forms are wrapped into a scroller. Write a custom my.scroller that have a handler tat listens to the bubble from my.textarea, so that it can scroll to that element.
  • Unfortunately this is on iOS.

    We tried adding:

    return true;

    to an ontap handler for the drop-downs, but the tap still fires on the underlying textarea causing it to focus.

  • the popup fire a signal method works in ios as well as android. Since, picker, popup and even dialogs are also using the same kind enyo.popup it will fire the event it as well.

    Android IOS Focus is only for android fix.
  • I'm having the same bleed-through issue on IOS 6/7. I tap a button to open a new panel and it then taps a button on the new panel that happens to be in the same position.
  • how quickly is the panel being animated? Can you do a stack trace and see what events are triggering the two taps?
  • I'm only experiencing this in mobile Safari. After the new panel is rendered, I can actually see the new button behaving as thought it's being tapped. The MouseEvents for the the "ghost" tap and if I were to actually click the button manually look exactly the same.
  • Adding inEvent.preventDefault() to the first button seems to have solved my problem.
  • If you return true from your event handler, that should be done for you.
  • @lynnaloo, you said "new" panel, does that mean that the panel doesn't actually exist until you press the button, it then creates the panel (with a button in the same position) that is then clicked as well?
  • Adding return true; did not fix the issue on our iOS 6/7 app, but inEvent.preventDefault(); did
Sign In or Register to comment.