[RF-13177] rich:extendedDataTable scrolling broken on OS-X Created: 09/Sep/13  Updated: 17/Feb/15  Resolved: 19/Jan/15

Status: Closed
Project: RichFaces
Component/s: base functionality, component-tables
Affects Version/s: 4.3.3, 4.5.1
Fix Version/s: 4.5.3

Type: Bug Priority: Major
Reporter: Immo Benjes Assignee: Michal Petrov
Resolution: Done Votes: 1
Labels: osx
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS-X 10.8.3, Chrome 29.0.1547.62 or Safari or Firefox


Steps to Reproduce:

In OS-X Settings->General (under Personal): set Show scroll bars: 'When scrolling'

Now visit any page with a rich:extendedDataTable (e.g. the showcase). Scrolling is not possible.

Forum Reference: https://community.jboss.org/thread/231502

 Description   

In OS-X scrolling can be done by using two fingers on the touchpad. However this does not work for horizontal scrolling on the rich:extendedDataTable.

You can scroll vertically but not horizontally.
The horizontal scrolling with two fingers only works when the mouse is over the actual scrollbar!
I had a look at the actual html code and it looks like the header, table content and scroller are generated as independent tables. The div that contains the table content (class rf-edt-cnt) has overflow:hidden; set. If you change that to overflow: auto you get the two finger scrolling over the content of the table, however the header and original scrollbar isn't scrolling. Would it be possible to hide the original scroller and synchronize the header (and footer?) when scrolling the content?

In OS-X you have the option to only show the scrollbar when you scroll. This is quite nice as it gives you a bit more space. However in this case you cannot scroll with the extendedDataTable at all! The scrollbar of the extendedDataTable is hidden in this case and the height/width of the div containing the scrollbar is 0, so you can't navigate over it to enable the scrolling. That basically gives you no way of scrolling!

See https://community.jboss.org/thread/231502



 Comments   
Comment by Immo Benjes [ 15/Oct/13 ]

I just wanted to confirm that the scrolling of the extended data table is broken on iOS devices. As tablets now outsell computers this is a big problem!

Another point is that OS-x 10.8 by default doesn't show the scroll bar, so if your users use Apple devices you basically can't use the extendedDataTable!

Comment by Brian Leathem [ 15/Oct/13 ]

QE, please verify this issue on an iOS mobile device and/or a OS/X desktop device.

Comment by Matej Novotny [ 17/Oct/13 ]

Hello,
I managed to reproduce this problem using a OS X 10.8.4 on MacBook Pro. As an example of extended data table I used Showcase application ("Basic Usage" tab).
I followed your instructions and set the "Show scrollbar" option to "When scrolling", but the problem persists even with always visible scrollbar (for touchpad gestures).

User is not able to move the horizontal scrollbar with a two-fingers gesture unless a cursor is hovering over the scrollbar. Using click-and-drag with mouse/touchpad works as long as the scrollbar option is not set to "When scrolling".

Comment by Matej Novotny [ 21/Mar/14 ]

Brian Leathem do we have any updates on this issue? Is there something else I can do?

Comment by Immo Benjes [ 11/Dec/14 ]

I was hoping to see a fix for this in 4.5 but apparently not. Any idea on when a fix can be expected? You are aware that this not only impacts OS-X but iOS as well (and there is no workaround for iOS)

Comment by Matej Novotny [ 17/Dec/14 ]

Verified with 4.5.2-SNAPSHOT Showcase. This is still an issue.
Michal Petrov are we going to address this issue? It's been opened for quite a time now.

Comment by Brian Leathem [ 17/Dec/14 ]

Matej Novotny we have a number of issues that have been open for quite some time. We also have a number of issues that have been resolved throughout the history of RF releases. We take into account many factors when prioritizing an issue, including the severity the issue itself and whether there are any workarounds, but also the impact the issue is having on the community.

For instance this issue has a single vote and a single (non RF-dev) watcher) and a single commenter.

Of course, this is OSS, and if a community member what's to accelerate an issue to the front of the queue they may do so by providing a Pull Request. Otherwise we will continue to triage this issue as we do the rest.

Comment by Immo Benjes [ 17/Dec/14 ]

Sorry Brian but I don't think you quite get the problem here. Your table DOES NOT WORK on ANY iPhone, iPad or Mac out there. And I would be surprised if it works on any touch device!

If you don't think that is a biggy then I don't know. I guess it is time to abandon ship and move on to Primefaces.

Comment by Brian Leathem [ 17/Dec/14 ]

Thank you Immo Benjes, I do understand there is a bug here. I am merely pointing out how we are prioritizing it along with other reported issues.

While your membership in the RichFaces community is valued, you are of course free to choose whichever JSF component set you prefer in developing your applications.

Comment by John Squire [ 18/Dec/14 ]

Hi Brian,

appreciate you prioritise your issues. we are also a software vendor, we also prioritise issues so we clearly understand this principle. however, sometimes vendors need to be more flexible and this is one of those cases.

its clearly a bug in your product and there is no workaround. so presume the only grounds on which you are not giving this a higher priority, is the impact on community.

I do not agree on your approach of using votes and comments to judge the impact of an issue.

the reality is that your view of community is limited to developers using this product. are developers the only users of your products? what about the end users of applications that incorporate your products? they are not technical and will not register on JBossDeveloper to vote on issues such as this, therefore you do not have an accurate view or assessment of the real impact on the wider community.

even though some users are registered, not every user will comment or vote on an existing issue, thats normal human behaviour.

on this basis, you should look at the perceived impact on the wider community rather than who commented and voted on an issue to determine priorities.

have you tried using your product on any of the platforms Immo mentioned above? do you understand the impact to the wider community?

I am sure that by now you have fixed other bugs with less of an impact but they have had a couple of votes more than this issue.

surely we are not talking about a months worth of work here? you have to fix this at some point so why continue delaying it? what do we need to do to get this fixed? start a facebook campaign?

Comment by Brian Leathem [ 18/Dec/14 ]

appreciate you prioritise your issues. we are also a software vendor, we also prioritise issues so we clearly understand this principle. however, sometimes vendors need to be more flexible and this is one of those cases.

A gentle reminded that I never said we wouldn't resolve this issue. I was merely sharing the process by which we triage issue that includes, but is not limited to, consideration of votes and comments on an issue.

its clearly a bug in your product and there is no workaround. so presume the only grounds on which you are not giving this a higher priority, is the impact on community.
I do not agree on your approach of using votes and comments to judge the impact of an issue.
the reality is that your view of community is limited to developers using this product. are developers the only users of your products? what about the end users of applications that incorporate your products? they are not technical and will not register on JBossDeveloper to vote on issues such as this, therefore you do not have an accurate view or assessment of the real impact on the wider community.

even though some users are registered, not every user will comment or vote on an existing issue, thats normal human behaviour.

on this basis, you should look at the perceived impact on the wider community rather than who commented and voted on an issue to determine priorities.

It has been our observation that if an issue is widespread and affects a large number of users, then generally that is reflected by the diversity of comments and votes. Developers tend to report errors from their respective user communities.

have you tried using your product on any of the platforms Immo mentioned above? do you understand the impact to the wider community?

As per this comment thread, our QE team has indeed verified this issue.

I am sure that by now you have fixed other bugs with less of an impact but they have had a couple of votes more than this issue.
surely we are not talking about a months worth of work here? you have to fix this at some point so why continue delaying it? what do we need to do to get this fixed? start a facebook campaign?

If a member of the RichFaces community is unhappy with the progress they are seeing in an issue, they are welcome to debug it themselves and provide a patch via a Github pull request - such is the benefit of OSS. If OTOH you want to operate within a well-defined SLA, there is a product from Red Hat called WFK that includes support for RichFaces.

We will address this issue as our priorities allow. I hope I've explained our process clearly, as time spent continuing such discussions takes away from time we can dedicate to resolving such issues.

Comment by John Squire [ 19/Dec/14 ]

thanks Brian,

regarding "time spent continuing such discussions takes away from time we can dedicate to resolving such issues" - if this issue was fixed then this discussion would not be taking place.

as you can see above, Immo has troubleshooted and provided some good information so we have done something about it rather than sitting back and doing nothing.

we cant wait inevitably for a solution so unfortunately we are being forced to look at alternatives and on that basis we have no choice but to replace the RF tables with the Prime Faces tables.

considering that we are the only ones affected by this issue and that we will no longer be using RF tables, you might want to close this issue.

Comment by Michal Petrov [ 19/Jan/15 ]

Enabled scrolling with the jquery.mousewheel plugin but I am not sure if that fully supports OS-X.

Comment by Pavol Pitonak [ 17/Feb/15 ]

Verified with RichFaces 4.5.3 and Mac OS X 10.10.2.

Generated at Fri Dec 14 08:55:49 EST 2018 using Jira 7.12.1#712002-sha1:609a50578ba6bc73dbf8b05dddd7c04a04b6807c.