TabBar focus issue on Android?

Martyn Bentley

unread,

Mar 27, 2014, 12:49:48 PM3/27/14

to chocolat...@googlegroups.com

Hi,

I'm a new user of CCUI and have been really impressed with it so far. The problem I'm experiencing is when using a TabBar control with range inputs. My app is wrapped with Cordova and having deployed to both iOS and Android (4.4) have observed that I can only recreate the issue in Android.

The symptom is that after making any adjustment to my <input type="range"> control, the first subsequent click on a CCUI navigable item does not register, whether that's one of my tabs on my tab bar, or the "Back" link above them. It's as if one tap is required to detach focus from the range control, and another to register a tap on the next element.

When that subsequent click is on a TabBar tab, the tab highlights (and stays highlighted) as if it were about to navigate/select, but the navigation does not occur. Here is an example:

<!DOCTYPE html>

<html>

<head>

</head>

<body>

</nav>

Article 1

</div>

</section>

</article>

</nav>

Article 2

</section>

</article>

</body>

</html>

$(function() {

var opts = {

tabs : 2,

icons : ["a1", "a2"],

labels : ["Article1", "Article2"],

selected : 1

};

$.UITabbar(opts);

});

</script>

Any help would be greatly appreciated!

Robert Biggs

unread,

May 16, 2014, 7:04:20 PM5/16/14

to chocolat...@googlegroups.com

This issues should be fixed in the latest version of ChocolateChip-UI. The problem was that on desktop Chrome and Android browsers, the "change" event on a range input does not update as expected. They need the "input" event instead. The latest versions address this shortcoming.

Martyn Bentley

unread,

May 20, 2014, 9:34:02 AM5/20/14

to chocolat...@googlegroups.com

Thanks, I've picked up 3.5.5 and although the tab half-highlighting issue is gone, it still requires TWO taps on the TabBar for navigation to occur. If anything, the behaviour is almost worse as the first tap gives no visual feedback.

I've also observed another issue whereby the blue background which has been added to the "filled" portion of the range control is not initialised when the value of the range control is set programatically. Of course, as soon as the user drags the control, it catches up.

As a workaround, I'm having to manually fire the input event at the end of the page initialisation to make it catch up:

$("#range_ctrl").val(50); // Slider moves to half way, but blue bar remains on previous, user-selected value

$("#range_ctrl").trigger("input"); // Blue bar catches up

Robert Biggs

unread,

May 27, 2014, 11:57:00 PM5/27/14

to chocolat...@googlegroups.com

What version of Android are you on and which device?

Martyn Bentley

unread,

May 28, 2014, 4:29:56 AM5/28/14

to chocolat...@googlegroups.com

v4.4.2 on a Nexus 5

The blue slider bar issue was observed on an iPhone 5 (iOS 7.1.1)

Robert Biggs

unread,

Jun 1, 2014, 11:30:37 AM6/1/14

to chocolat...@googlegroups.com

Martyn,

Can you send a screenshot of what you're talking about?

Robert Biggs

unread,

Jun 1, 2014, 11:31:06 AM6/1/14

to chocolat...@googlegroups.com

Better yet, a snippet of code of how you're doing this?

Martyn Bentley

unread,

Jun 2, 2014, 9:12:20 AM6/2/14

to chocolat...@googlegroups.com

There is a screenshot in my quoted text above. You can recreate the symptom in desktop browsers too, though. Here's another one, from Safari:

I've had another look at the issue today and the problem seems to be with initialising the range control's value in the document.ready() event, which I presume is happening after CCUI initialisation. If I create a script block at the end of the page to set the value earlier (not wrapped in any particular event handler), CCUI behaves as I would expect.

Another alternative is to manually fire an input event on the range control after setting its value. I haven't had a chance to pick apart the CC source but I assume it is handling the change/input events. Anyway, here's a quick example to demonstrate:

<html>

<head>

$(document).ready(function()

{

var opts = {

tabs : 2,

imagePath : "/",

icons : ["music", "pictures" ],

labels : ["Music", "Pictures"],

selected : 1

};

$.UITabbar(opts);

// Pre-set range control value

$("#range_ctrl").val(75);

// Manually fire input event to update CCUI (Uncomment to correct issue)

//$("#range_ctrl").trigger("input");

});

</script>

</head>

<body>

</article>

</body>

</html>

Robert Biggs

unread,

Jun 24, 2014, 9:23:08 PM6/24/14

to chocolat...@googlegroups.com

Egads! This has been painful. So the problem is the way the Android browsers handle events. By default they bubble, Everyone else does the opposite. This means that after the input gets focus, the first interaction only blurs the input, so even if the user touches something interactive, it would take another touch to register. If you're not supporting iOS or Windows Phone 8 but only Android, you can address this issue as follows:

Open up chui.js and go down to line 515:

514: }

515: });

516: body.on($.eventEnd, function(e) {

Add the "true" keyword to line 515:

514: }

515: }, true);

516: body.on($.eventEnd, function(e) {

That should give you the interactions you seek on Android. Be aware that there may result in other unforeseen bugs affecting other widgets so make sure to test that things are interacting the way you expect. I'll probably look into setting some kind of flag in my events module to handle event bubbling for Android browsers specifically.

Martyn Bentley

unread,

Jun 27, 2014, 4:00:26 AM6/27/14

to chocolat...@googlegroups.com

Thank you Robert for investigating and your explanation is a big help. We are actually targeting iOS and Android (and eventually WM) so will have to come up with a suitable cross-platform fix, however your explanation has definitely sent me in the right direction. Development is on hold for a short while but will resume shortly and if I come up with a suitable fix I will post it back.

Reply all

Reply to author

Forward