BUG: MarkupList elements do not receive focusPercent updates in certain conditions

When using MarkupList with vertFocusAnimationStyle = “fixedFocus” and focusRow >= 3, items from i = 3 to i = focusRow do not receive focusPercent updates.

I have a MarkupList with focusRow = “3” where I change the text color of the item labels based on when the focus percent changes, however, this does not happen when I focus on the 3rd item in the list.

I assume this bug happens on all Roku devices (I only have 2 of them) and is not device-specific.

Steps to reproduce:

  1. Make a MarkupList with vertFocusAnimationStyle = “fixedFocus”

  2. Make a custom component which includes a label with any text as a child and add

<field id="focusPercent" type="float" onChange="onFocusChange" />

to the component interface tag

  1. Add this function to the component’s code:
function onFocusChange()
    print "Focus %:", m.top.focusPercent
    if m.top.focusPercent >= 0.5
        m.testLabel.color = "0x262626FF"
    else
        m.testLabel.color = "0xDDDDDDFF"
    end if
end function​
  1. Insert at least 4 of these custom components as content to the MarkupList

  2. Scroll the list and observe how the 3rd item never receives focus percent updates

  3. Change the focusRow to a higher number (add additional elements to the list if you have to). Observe how items from index 3 to focusRow never receive focus percent updates (for example, when setting focusRow to 5, 3rd to 5th items do not receive focus updates)

  4. When setting the focusRow to 2 or less, the list behaves as expected and all items receive focus percent updates.

My code if you would like to try it out yourself:

<MarkupList
    id="testMarkupList"
    itemComponentName="TestElement"
    vertFocusAnimationStyle="fixedFocus"
    focusRow="3">
    <ContentNode id="testMarkupListContent" role="content">
        <ContentNode title="0" />
        <ContentNode title="1" />
        <ContentNode title="2" />
        <ContentNode title="3" />
        <ContentNode title="4" />
        <ContentNode title="5" />
        <ContentNode title="6" />
        <ContentNode title="7" />
    </ContentNode>
</MarkupList>

TestElement.xml:

<?xml version="1.0" encoding="utf-8" ?>

<component name="TestElement" extends="Group">
    <script type="text/brightscript" uri="TestElement.brs" />

    <interface>
        <field id="itemContent" type="node" onChange="showContent" />
        <field id="focusPercent" type="float" onChange="onFocusChange" />
    </interface>

    <children>
        <Label id="testLabel"></Label>
    </children>
</component>

TestElement.brs:

sub init()
    m.testLabel = m.top.findNode("testLabel")
end sub

function showContent()
    m.testLabel.text = m.top.itemContent.title
end function

function onFocusChange()
    print "Focus %:", m.top.focusPercent
    if m.top.focusPercent >= 0.5
        m.testLabel.color = "0x262626FF"
    else
        m.testLabel.color = "0xDDDDDDFF"
    end if
end function

A very similar issue happens to me where items from i = 1 to i = focusRow are either not receiving focusPercent updates at all, or receive them in a completely buggy way (where it starts heading towards 1 gradually and then just immediately goes to 0? )

This is with using “fixedFocusWrap”

I guess it’s just another day at the office of Roku not caring. How do I explain to my client that I need a ton of time to create a custom wrappable markup list now? I was about to tell them that it’s an OS issue which will likely get fixed soon until I saw that this post is 9 months old lol.

Ah, so markup lists with “fixedFocusWrap” are affected too?

For what it’s worth, I created a bug report on the issue on the Roku partner success site in January. Surprisingly enough, I quickly got a reply that they created a ticket and sent it over to the engineer’s queue. However, it looks like the ticket is still at the bottom of said queue 7 months later, despite what I think should probably be a fairly simple fix for the issue…

Maybe it would help accelerate things if you also created a bug report for the problem you’ve found, but at this point I kinda doubt it…