How "wheelHandler" is working

[MiguelAngel82]

Hi all!

Sorry, but I have another question about how the plugin works. I have a div as "ui-scroll-viewport", with a custom height, and inside it a table, something like that:

<div ui-scroll-viewport style="height:300px">
        <table>
            <thead>
            [...]
            </thead>
            <tbody ui-scroll="document in datasource" adapter="adapter">
            <tr>
            [...]
            </tr>
            </tbody>
       </table>
</div>

The data is retieved via endpoint call, with a size of 10 in each call. Everything works as expected in Firefox, but in Chrome, when the data fetched is less than 20, and viewport div height is more than 300px, wheel mouse is not working. I've gone deep in the JS and the problem is in the wheelHandler function, that when the wheel mouse is not working, buffer.bof is set to true, but in the other case, is set to false. Nevertheless, and although I've tried to investigate it, I don't know how buffer.bof is set to true.

Thanks in advance!
Regards,
Miguel.

[dhilt]

@MiguelAngel82 Your template looks unpredictable from the point of the veiwport logic due to thead section placed between ui-scroll-viewport and ui-scroll containers. This thead may conflict with internal ui-scroll top padding element and its height may affect viewport.scrollTop calculations which may cause bof issue. I see, the doc is not clear enough in this part... Is it possible to set tbody as ui-scroll-viewport and tr as ui-scroll? Also, you may try to apply ui-scroll-th and ui-scroll-td directives, that were designed for table based viewports.

[MiguelAngel82]

Hi @dhilt,

Thank you very much for your quick response! Sorry, I haven't checked the documentation for ui-scroll-th and ui-scroll-td, it could be a good solution. But, in this case, I have a little problem. The reason why ui-scroll is used in tbody is becasue I need differents "tr's", but repeating they at same time. I mean:

<tbody ui-scroll="document in tableDatasource" adapter="adapter">
  <tr>
    <td>
    [...]
    </td>
    <tr ng-if="ctrl.isCollapsed(document)" class="edition-row">
       <td>
       [...] 
       </td>
    </tr>
</tbody>

So the second "tr" is shown when the first "tr" is clicked and is shown as a detail of the row. With a "ng-repeat" solution I've found that it could be done with "ng-repeat-start" and "ng-repeat-end", but I don't know if is possible to do with the solution you suggested.

Thanks!

[dhilt]

@MiguelAngel82 You can apply a single-tr approach in your template:

<tbody ui-scroll-viewport>
    <tr ui-scroll="document in tableDatasource" adapter="adapter" >
       <td>
           ... data 1
         <div ng-if="!ctrl.isCollapsed(document)" class="edition">
            ... edit data 1
         </div>
       </td>
       <td> 
          ... data 2
         <div ng-if="!ctrl.isCollapsed(document)" class="edition">
            ... edit data 2
         </div>
       </td>
       ...
    </tr>
</tbody>

This would require to re-skin the view, but it seems possible because of similar structure of 2 trs from your current approach. Also, I believe, ui-scroll-th and ui-scroll-td may help you to solve the issue without re-designing the template; you'll be able to set up tbody as a repeatable ui-scroll element and keep ui-scroll-viewport on the top-level table container.

[MiguelAngel82]

Hi again @dhilt.

And thanks again for your response and effort ;)

I've tried the solution without re-designing, using ui-scroll-th and ui-scroll-td and using ui.scroll.grid dependency, something similar to:

<div ui-scroll-viewport style="height:300px">
    <table >
        <thead>
        <tr>
            <th ui-scroll-th>
            [...]
            </th>
        </tr>
        </thead>
        <tbody ui-scroll="document in datasource" adapter="adapter">
        <tr>
            <td ui-scroll-td>
            [...]
            </td>
        </tr>
    </table>
</div>

But I have the same problem as the original issue. When I try to make a wheel mouse scroll at first time it doesn't work. I've checked that is the same, is in the wheelHandler function, buffer.bof is set to true.

Am I missing something? Is there something wrong in my implemented solution?

Thanks!

[dhilt]

@MiguelAngel82 I believe, the wheel handler is not about the issue; we can try to make sure of this if you would try to scroll by clicking on the scroll bar. May I ask you to build a minimal repro? You can take this Plunker as a start point (but use the latest versions of AngularJs and ui-scroll). Then I will dig into problem.

[MiguelAngel82]

Hi again @dhilt.

I've created a couple of plunkers and they work perfectly. The reason why I created two versions is because in my project, apart of using ui-scroll, Bootstrap 3 is used. The table has "table" class, and when this class is removed, in my project, ui-scroll works perfectly, but when is added, the problem appears :/

So here is the two working plunkers:

• Without Bootstrap: https://plnkr.co/edit/Pmzglm
• With Bootstrap 3: https://plnkr.co/edit/likHyK

So I'm confused, probably there are more things involved in my project that are affecting ui-scroll...

Thanks anyway ;)

[MiguelAngel82]

Hi @dhilt.

I've been investigating why adding "table" class to the table is affecting buffer.bof but I haven't found the reason yet. It's very strange.

Just out of curiosity, what is the aim of buffer.bof? I'm trying to understand the plugin and how this style is affecting in this case.

Thank you!

[dhilt]

@MiguelAngel82 Well... Here the ui-scroll gets a bunch of items that is less than expected buffer size, that means that this is the last pack on current direction (scrolling up). And here is the condition for fetching more items. Since bof (begin-of-file) has been reached, ui-scroll would not request new items on given direction. Scrolling down and clipping items from the top of the viewport will reset bof again (here). The same logic is implemented for eof flag (end-of-file).

Wheel handler does nothing but prevents scroll events bubbling when you are scrolling over the ui-scroll viewport. It is due to Hill30/NGScroller#39.

[MiguelAngel82]

Hi again @dhilt.

Sorry if I bother you a lot :( I've been digging a little bit more and what I've found (probably is a hint for you or it says nothing), is that when "table" class is added, ridActual reaches the value of 1, and when the "table" class is not added it reaches the value of 2.

So when "table" class is added, the function doAdjust is called from visibilityWatcher when ridActual it's 1 and when is not present "table" class, doAdjust is called from visibilityWatcher when ridActual it's 2.

Is this a hint for you? Do you think is worth that I continue investigating on it?

BTW, thank you very much for your explanation, they aer being very useful to understand the plugin ;)

Thanks!

[dhilt]

@MiguelAngel82 It looks like your styles make the viewport fall into race condition with rows visibility, because visibilityWatcher is being triggered only in case of zero-heighted row suddenly obtains a positive height value. The simplest use case is described here, but there maybe a lot of other applications, some of them may have side effects. Specifically this calculations could be broken due to styles and you may try to check it. The main rule is test the DOM specific logic if you see that different styles give you different behavior.

[MiguelAngel82]

Hi @dhilt,

Sorry, but when you say "The main rule is test the DOM specific logic if you see that different styles give you different behavior.", what is exactly are you referring to? I mean, are you referring to debug ht "ui-scroll.js" library and all fuctions that are called? I'm debugging it, putting breakpoints in all functions involved, but probably there is another easier way to do it.

Thanks.

[dhilt]

@MiguelAngel82 As I noticed, you have a situation when applying some css class to the viewport breaks ui-scroll behaviour. If we want to understand what exactly affects scroller, we may

• minimize repro and find specific css-rule(s) that is responsible for the issue;
• compare broken and unbroken logic with and without that rule(s).

The second step is about debugging ui-scroll library. Since I have no repro I suggested you to do it. And DOM specific methods should be entry points during debug. If debugging is not an option for you, you may post a repro and then I will try to do it.