The following seems to work without flicker unless user has scrolled all the way to then and bounced back. Pushed to remote branch origin/scrollview. Test page is at src/scrollview/tests/manual/scrollview-chrome-transform.html.

Wondering if there is something about scrolling all the way to the end that results in a different state than a basic incremental scroll.

So you mean it doesn't fix the problem for that scenario? or you see flicker for that scenario? (I'll take a look, but just thought I'd ask in the meantime)

Seems to work fine for me. See attached .mov

a) Scroll all the way to the right edge
b) Let it scroll a little further, to get the bounce
c) Once finished bouncing, click "Add Image"
d) The new calculations seem fine.

Is it the scrollbar jumping which you're talking about? I think that's expected when you add a new image - you've got more content on the end now. It moves for the non-bounce case also.

In terms of the fix, I'd still like to see if we can avoid scrollTo API, since it goes though:

if (xSet) {
this.set(SCROLL_X, x, { src: UI });
}

if (ySet) {
this.set(SCROLL_Y, y, { src: UI });
}

Since it's a browser level hack, I was thinking of just applying the transform directly to the dom:

if (NATIVE_TRANSITION) {
var [origX, origY] = getTransformMatrixToStoreCurrentTransformValues; // I think Matt has support for getting the Matrix from which you can get the X/Y translation amount.
setStyle(transform, translate(0,0);
calc Dimensions ...
setStyle(transform, translate(origX,origY)];
}

I think I added a _transform method for the h/w acceleration switching, which will get you the actual "transform" string, given an X,Y

This was the approx implementation (untested) I was thinking of:

https://gist.github.com/1103272

Ok, pushed fix to origin/scrollview. It works great. Pls take a look.

NOTE: FF 3.6. was exhibited same bug and yet NATIVE_TRANSITIONS was returning false so the fix was not being executed. I had to include an else block that just calls cb.setStyle(LEFT/TOP) to get it to work in FF 3.6.

I'd like to merge this into master with your approval.

Cool. Feel free to check into master if it tests out OK on Webkit, FF [ we already discussed the general idea behind the fix ]. Now that I think about the FF 3.6 fix - maybe all the non native browsers have always had this problem [ it's just that ScrollView is used less in these browsers, so it's never been reported ]. That is, I can see how moving the contentBox over [ using top/left ] would have the same general scrollWidth impact as the translate so the else block makes sense for this entire set of non-native transform browsers.

So this didn't need to be -ve?

cb.setStyle('transform', this._transform(origX, origY));

That is, not:

cb.setStyle('transform', this._transform(-origX, -origY));

??

FYI, I pushed one more commit that makes IE6 happy. Code has now been tested on IE6, Chrome, Safari, FF3.6, FF4 and FF5. Will test on IE 7-9 tmrw.

Oh, and correct -- did not need to make the values negative.

[fix #2530530] Scrollview transform bug.
View Commit: d5daadf7c87a641483741ee68c26b343acb5717c

[fix #2530530] Refactor -> add _moveTo method.
View Commit: 609b3fdb3368975ebd66bf9ef6a074e3ca726524

Reopening. Still broken on Chrome 12.0.742.122/MacOS 10.6

Fallback to using larger of bb.scrollWidth/Height or cb.scrollWidth/Heightnto account for FF (which clips cb.scrollWidth due to bb overflow:hidden) andnChrome (which clips bb.scrollWidth, when translated).nnFixes #2530530nnTested examples and manual scrollview-chrome-transform.html onnFF5, Chrome 12 (Win and MacOS), IE8 and Mobile Safari on the IPad.
View Commit: 9220b67634d9c9872485e6a84bd8de8dd3d7507b

Reopening. I don't think it's fixed robustly enough. It's not fixing the issue in Safari 5.1, in certain use cases.

commit aa1e03f2af02ffea69e75323bf4fff95cbf736c5
Author: Satyen Desai sdesai@yahoo-inc.com
Date: Thu Sep 8 22:16:41 2011 -0700

Fixed issue with translate impacting scroll dimension calculations on Chrome 9+,
and now also Safari 5 - For real this time. Fixes #2530530.

translateZ applied for hw accel, was preventing the 3.4.0 fix from working,
and incorrect fallback for dimensions (added as a quick patch) was masking the
incorrect scrollWidth calculations.

One more shot at making scrollWidth/Height calculations more robust in
the presence of translation + h/w acceleration in Webkit environments, by
moving offsetHeight/Width retrieval into the non h/w accelerated region.

Found that even if we disable h/w accel on the ScrolView on which we're
trying to calculate scrollWidth/Height (aa1e03f2), if it's downstream in
terms of document flow from another part of the page which is h/w accelerated
calculations are still thrown off. Moving offsetHeight/Width retrieval into
the non-h/w accelerated section of code seems to fix this (not sure how, but
I have some theories).

There is a h/w acceleration bug for Webkit in here somewhere.

See #2530530 and aa1e03f2

Also added a combined manual scrollview test bed, to replace the older
manual tests.
View Commit: ea9d934cb7e379c8bb93c95c66219c403f6eeb30

Fixed issue with translate impacting scroll dimension calculations on Chrome 9+,
and now also Safari 5 - For real this time. Fixes #2530530.

translateZ applied for hw accel, was preventing the 3.4.0 fix from working,
and incorrect fallback for dimensions (added as a quick patch) was masking the
incorrect scrollWidth calculations.
View Commit: aa1e03f2af02ffea69e75323bf4fff95cbf736c5

One more shot at making scrollWidth/Height calculations more robust in
the presence of translation + h/w acceleration in Webkit environments, by
moving offsetHeight/Width retrieval into the non h/w accelerated region.

Found that even if we disable h/w accel on the ScrolView on which we're
trying to calculate scrollWidth/Height (aa1e03f2), if it's downstream in
terms of document flow from another part of the page which is h/w accelerated
calculations are still thrown off. Moving offsetHeight/Width retrieval into
the non-h/w accelerated section of code seems to fix this (not sure how, but
I have some theories).

There is a h/w acceleration bug for Webkit in here somewhere.

See #2530530 and aa1e03f2

Also added a combined manual scrollview test bed, to replace the older
manual tests.
View Commit: ea9d934cb7e379c8bb93c95c66219c403f6eeb30

Reopening this, and reassigning it to Derek (new SV owner).

The flipping to 2d to work around the issue has it's own downsides [ flicker is evident, when you have a lot of content ].

Maybe we just go back to adding the transform amount to the scrollWidth. May still need to filter out the browsers which support transforms but have different behavior [ Safari 4 ].

Just some thoughts:

Since all the browsers seem to be normalizing on adding the translation amount to scrollWidth, seems like we might as well just settle on that solution, to avoid the moving back/forth to/from 0,0 to get the right dimensions.

We can test support if we really want to, while loading sv:

var o = Y.Node.create("<div></div>"),
i = Y.Node.create(<div></div>");

o.setStyles({
width : "100px",
height : "10px",
overflow : "hidden"
});

i.setStyles({
"width" : "200px",
"height" : "10px",
"transform": "translateX(-10px)" // don't know if setStyle normalizes offhand
}

body.append(o);

var ACCOUNT_FOR_TRANSLATE = (o.get("scrollWidth") === 190);

i.remove(true);
o.remove(true);

And then in _getScrollDims(), get the translate amount from the computed style matrix, and add the translate amount to the scrollWidth.

Caridy, I've put an implementation of the above approach here, which should fix your flicker due to the 2d/3d switch.

http://yuiblog.com/sandbox/yui/v340/scrollview/svtestbed.html

It patches 3.4.1. Look at the code between START DIMS FIX and END DIMS FIX.

Derek, I'll also push a version of it in scrollview-base to a github branch and post it here, for consideration for 3.5.0.

Here's the change to scrollview-base. Needs testing across the A-Grade before committing to 3.5.0.

https://github.com/sdesai/yui3/commit/9d4439779a64d343ac907b86b0285bb54363a932

Modified it a little to handle X and Y separately - turns out Y doesn't need fixing! Browsers need to make up their minds.

https://github.com/sdesai/yui3/commit/b75138257e5e3ab102da9d67ed22b2a42e75a58a

Moving 3.7.0 bugs to 3.6.x for triage.

Moving from 3.6.x to 3.CURRENT.NEXT