Driving us mad... Anyone seen the floating cursor bug when scrolling after input focus?

Using the TransitionScrollStrategy in a Cordova (3.5.0-0.2.4) app built from enyo-cordova.

When scrolling with an input having focus the cursor(and any ios autosuggest) gets stranded and floats above the scrolling element. This leaves the app in a very unusable state.

Poking around the code, adding break points to the scroller it appears that it wants to hide the keyboard before scrolling (which is the fix most often suggested) but there appears to be a race condition preventing that from happening before the fubar state is entered. I've been unable to find the code bluring the activeElement on scroll (thus hiding the keyboard) nor have I been able to find a suitable hook bind to.

Anyone seen/fixed this? Problem appears with Enyo 2.4 and 2.2. Can be easily reproduced by creating a new cordova project with enyo-cordova and replacing the bootplate MainView.js with the code below and then emulating iOS. (tap the Hello World button enough times to insert inputs allowing scroll)

	name: "myapp.MainView",
	kind: "FittableRows",
	fit: true,
		{kind: "onyx.Toolbar", content: "Hello World"},
		{kind: "enyo.Scroller", fit: true, strategyKind: 'enyo.TransitionScrollStrategy', components: [
			{name: "main", classes: "nice-padding", allowHtml: true}
		{kind: "onyx.Toolbar", components: [
			{kind: "onyx.Button", content: "Tap me", ontap: "helloWorldTap"}
	helloWorldTap: function(inSender, inEvent) {
		this.$.main.createComponent({components: [{kind: 'enyo.Input'}]}).render();
Anyone have a clue what is going on? Any scoller gurus out there?


  • I've been digging around in scrollers a lot, but I don't think I've seen anything explicitly blurring inputs. Inputs react to dragstart events to disallow being dragged, in order to allow text selection, but that doesn't remove focus.

    I haven't yet made any cordova apps, so I'm doing some guess-work here, but if the focus state is the problem I'd try explicitly removing focus on scroll-start and re-focus on scrollstop if still needed.

    You could extend the scroller to waterfall scroll events down to it's children to give your inputs some events to react to:

    name: "ui.Scroller",
    kind: "enyo.Scroller",
    published: {
    waterfallScrollStart: false,
    waterfallScroll: false,
    waterfallScrollStop: false
    scrollStart: function(inSender, inEvent) {
    if (this.get("waterfallScrollStart")) {
    this.waterfallDown("scrollStart", inEvent, inSender);
    //* Adds notifications to child elements
    scroll: function(inSender, inEvent) {
    if (this.get("waterfallScroll")) {
    this.waterfallDown("scroll", inEvent, inSender);
    //* Adds notifications to child elements.
    scrollStop: function(inSender, inEvent) {
    if (this.get("waterfallScrollStop")) {
    this.waterfallDown("scrollStop", inEvent, inSender);
  • Hi Ruben, thanks for the reply.

    We tried blurring via the scroll events but what ever we are chasing happens before the scroll events trigger and document.activeElement is null by the time we can get to our code.

    My example above is a bit off to our application. We are injecting HTML into an enyo panel so the elements are not enyo controls, although in our testing the bug happens regardless if the elements are generated by enyo or inserted into the dom via setContent().

    I recorded a screencast of the behavior so all can see without setting up cordova. Check it out: Enyo Floating Scroller Screencast

    Any other ideas? Anyone else run into this?
  • edited July 2014
    Here is a short cast of the keyboard minimizing (the input being blurred) when I add a breakpoint in Scroller.js scroll handler. It does not minimize if the breakpoint does not exist and other break points don't minimize the keyboard. We haven't been able to trace what does that blur on the activeElement.... Ideas?

    Keyboard Minimizing on scroll with breakpoint
  • Before scrollstart, there is also a dragstart event, perhaps you can insert a hook there?

    Or, even earlier, the scroller has a specific handler for the 'down' event, which prepares some bounds needed to scroll by drag interaction.

    Another issue I can think of is, IOS tends to block javascript during native scrolling. Perhaps that's why your code doesn't execute correctly?

    Furthermore, do any other scroll strategies cause this issue?
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!