Ticket #2531137 (accepted task)

Reporter


Sylvain Prat
Opened: 09/22/11
Last modified: 09/24/12
Status: accepted
Type: task

Owner


Derek Gathright
Target Release: BACKLOG
Priority: P3 (normal)
Summary: Document appropriate strategy for contentBox size changes
Description:

Inside a scrollview, I have some items that expand/collapse via a javascript css class toggle. However, when my items expand, the scrollview scroll limits do not change, so the bottom of the scrolled
content cannot be reached anymore.

As a workaround, since the event triggering the content box's size change is a click event, I registered a click handler on the content box that call the scrollview's syncUI() method. However, I think
it's the scrollview's responsibility to handle this and I guess the scrollview should monitor the size of the contentBox and update the scroll dimensions accordingly. That's what I expected at least,
that's the reason why I filed this bug.

Type: task Observed in Version: 3.4.0
Component: ScrollView Severity: S3 (normal)
Assigned To: Derek Gathright Target Release: BACKLOG
Location: Example Priority: P3 (normal)
Tags: scrollview, scroll limits, dynamic content, size Relates To:
Browsers: N/A
URL:
Test Information:

Change History

Satyen Desai

YUI Developer

Posted: 09/22/11
  • priority changed to P3 (normal)
  • resolution changed to wontfix
  • status changed from new to closed

Scrollview used to do this, but there's no clean/performant way to monitor changes in the contentBox size across all browsers [ you could add content/remove content/change CSS/hide/show something ]. It used to do it by listening for DOMSubtreeModified on browsers which supported it, but this event fires way to often, and fires when dimensions may not change, and leads to difference in behavior across browsers.

Hence invoking syncUI() is the designed way to go, when you do something which changes the size of the scrollView's content.

Sylvain Prat

Posted: 09/23/11
  • resolution changed from wontfix
  • status changed from closed to reopened

Sylvain Prat

Posted: 09/23/11

I agree with the design decision, that's justifiable.

However, since I spent much time 1. figuring out why the scrollview didn't behave as I expected 2. looking for a workaround, I think it deserves a mention in the component documentation (the one at http://yuilibrary.com/yui/docs/scrollview/) or even in the examples, maybe with different workarounds:
- monitoring the size changes by polling the box dimensions with a timer
- using DomSubtreeModified
- with a click handler
...

Finally, I think it's not very different from the "disable link behavior" examples.

Satyen Desai

YUI Developer

Posted: 09/23/11
  • location changed to Example
  • milestone changed to 3.5.0

Yeah, I agree. I think it needs an example (along the lines of the yui3/src/scrollview/tests/manual/svtestbed.html test file)

Satyen Desai

YUI Developer

Posted: 03/26/12

Derek Gathright

YUI Developer

Posted: 03/27/12
  • milestone changed from 3.5.0 to 3.6.0
  • status changed from assigned to accepted

Derek Gathright

YUI Developer

Posted: 07/21/12
  • estimated changed from 0 to .25
  • milestone changed from 3.6.0 to 3.7.0
  • remaining changed from 0 to .25
  • summary changed from Scrollview's scroll limits do not update when the content box's size changes to Document appropriate strategy for contentBox size changes
  • type changed from defect to task

Jenny Donnelly

YUI Developer

Posted: 08/1/12
  • milestone changed from 3.7.0 to 3.6.x

Moving 3.7.0 bugs to 3.6.x for triage.

Derek Gathright

YUI Developer

Posted: 08/7/12
  • sprint changed to Backlog

Jenny Donnelly

YUI Developer

Posted: 09/19/12
  • milestone changed from 3.6.x to 3.CURRENT.NEXT

Moving from 3.6.x to 3.CURRENT.NEXT

Derek Gathright

YUI Developer

Posted: 09/24/12
  • milestone changed from 3.CURRENT.NEXT to BACKLOG