MLS 3.1.1 "Jumping" issue when clicking an item far down on a scrollable list

Discussions around using and interfacing with the Church MLS program.
jlangf
New Member
Posts: 4
Joined: Tue Dec 01, 2009 8:15 pm
Location: Provo, UT, United States

MLS 3.1.1 "Jumping" issue when clicking an item far down on a scrollable list

Postby jlangf » Tue Dec 01, 2009 8:23 pm

In MLS 3.1.1, when clicking an item about 15 from the top or further down such as Organizations > Relief Society > Other Callings > (any "Position" at least 15 from the top) rather than displaying the dialog box to edit the selected entry, the scrollable section moves up a page or two thus making any items at least 15 or so from the top not editable.

Any ideas as to what I may be doing wrong would be very helpful.

Thank you!

User avatar
aebrown
Community Administrator
Posts: 14685
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Tue Dec 01, 2009 11:06 pm

jlangf wrote:In MLS 3.1.1, when clicking an item about 15 from the top or further down such as Organizations > Relief Society > Other Callings > (any "Position" at least 15 from the top) rather than displaying the dialog box to edit the selected entry, the scrollable section moves up a page or two thus making any items at least 15 or so from the top not editable.


I have seen somewhat similar behavior, but not quite what you are describing. I'll describe exactly what I am seeing, and you can tell me if it is actually close to what you have experienced.

  1. In just about any scrollable list within MLS, it can be that there are more items in the list than fit the window, so you have to scroll to see all the items.
  2. In this case, it is possible that an item at the top or bottom of the scroll region will be mostly visible, but may have one or more rows of pixels that are scrolled out of the window.
  3. Clicking on such an item, even if it is a blue hyperlink, will often scroll the list so that the item is completely visible.
  4. When this autoscrolling happens, the hyperlink is not activated, but now that the item is visible, it can be clicked on and the linked action will occur.
  5. I assume that this is intentional behavior to make sure that an item is fully visible and that thus you are sure you have selected the correct item before you operate on it.
  6. Nonetheless, this autoscrolling sometimes occurs when an item at the top or bottom of the window is completely visible, even including the one-pixel-wide line that separates items in some lists. That seems to be a boundary condition that doesn't work precisely right.
I can duplicate the above from many different lists, and it can happen with far fewer than 15 items in a list (although I did test with more than 15 items, and it happens exactly the same as with fewer items). But although there are similarities, there are differences. My scrolling is never more than one full row, and I can always click on the item after the scrolling occurs.

Can you duplicate what I describe above? Is your case very similar, or something quite different?

dwterry-p40
Church Employee
Church Employee
Posts: 40
Joined: Wed Apr 04, 2007 7:24 am
Location: Salt Lake City, UT

Postby dwterry-p40 » Wed Dec 02, 2009 6:29 am

This issue has been duplicated in lists that have over-sized or variable-sized rows of information (e.g. a row that has, in a single column, both phone and email may put them on top of each other creating a taller row than normal).

When this happens, MLS gets confused as to how far it should scroll to ensure that a clicked row is within the view port (in the worst cases, not even realizing that the row is already completely visible within the view port and scrolling anyway).

A fix is underway.

User avatar
aebrown
Community Administrator
Posts: 14685
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Wed Dec 02, 2009 7:20 am

dwterry wrote:This issue has been duplicated in lists that have over-sized or variable-sized rows of information (e.g. a row that has, in a single column, both phone and email may put them on top of each other creating a taller row than normal).

When this happens, MLS gets confused as to how far it should scroll to ensure that a clicked row is within the view port (in the worst cases, not even realizing that the row is already completely visible within the view port and scrolling anyway).

A fix is underway.


Are you saying that it has only been duplicated in the case of lists that have variable-height rows of information? Because I can most definitely duplicate it in other lists as well. Specifically, I did it in the Other Callings section of the Organizations > Relief Society screen. That section allows only 4 items to be visible. If there are more than 4 items, and you click on the 4th item, the list will scroll. If you continue to click on the bottom item in the view port, the list will continue to scroll, until you get to the last item in the list, when the hyperlink action will finally occur.

dwterry-p40
Church Employee
Church Employee
Posts: 40
Joined: Wed Apr 04, 2007 7:24 am
Location: Salt Lake City, UT

Postby dwterry-p40 » Wed Dec 02, 2009 9:05 am

It's okay to scroll the bottom entry into view where you can then click on it.

The problem was with these taller than normal rows, if you scrolled down a ways into the list, you'd find rows that simply could not be clicked because every time you tried, it would scroll that row somewhere else.

Say you have 100 rows. You scroll to the 30th row and want to click it. Upon doing so, MLS decides to scroll the view port (in a naive/broken attempt to bring that row into view - not realizing it was already in view). This row is never considered to be "within viewing range" and is forced to scroll no matter where it is within the view port.

Thus there are rows that simply cannot be updated with the current MLS because every attempt to do so causes the list to scroll instead of the intended behavior.

The fix makes it so that MLS now realizes that the row is already in viewable range so that it does not attempt to scroll it.

jlangf
New Member
Posts: 4
Joined: Tue Dec 01, 2009 8:15 pm
Location: Provo, UT, United States

Postby jlangf » Mon Dec 07, 2009 6:26 pm

Thank you for your responses! I will await the fix dwterry mentioned.


Return to “MLS Support, Help, and Feedback”

Who is online

Users browsing this forum: No registered users and 1 guest