Resolves views rendering in partly scrolled state

Resolves views rendering in partly scrolled state

This branch resolves two bugs wherein a view rendered scrolled partway down.
This appears to be an issue with browser behavior rather than JS, as
investigation showed no problem when debuggers were used to check state as the
views render.

To get around that, this branch simply grabs the top-most visible element of
the two views and ensures they're scrolled into view.

https://code.launchpad.net/~jcsackett/juju-gui/scroll-to-top-on-change/+merge/161894

(do not edit description out of merge proposal)

[j.c.sackett, 2013-05-01 17:42:30]

Please take a look.

[j.c.sackett, 2013-05-01 17:43:32]

https://codereview.appspot.com/9088043/diff/1/app/subapps/browser/views/edito...
File app/subapps/browser/views/editorial.js (right):

https://codereview.appspot.com/9088043/diff/1/app/subapps/browser/views/edito...
app/subapps/browser/views/editorial.js:99: this._apiFailure(data, request,
'Failed to load editorial content.');
This was just a driveby.

[rharding, 2013-05-01 17:50:06]

LGTM sans the one request to fix renderTo vs work around it assuming that was
the issue.

https://codereview.appspot.com/9088043/diff/1/app/subapps/browser/views/charm.js
File app/subapps/browser/views/charm.js (right):

https://codereview.appspot.com/9088043/diff/1/app/subapps/browser/views/charm...
app/subapps/browser/views/charm.js:465: var viewData = Y.one('.bws-view-data');
I'm assuming this is changed because the valueFn was grabbing before the node
was there? Can we change renderTo to work with the getter then and prevent hard
coding the Y.one here? The renderTo was updated to keep all the views in common
and for testing. This happens to work because you're using the default value
anyway.

[j.c.sackett, 2013-05-01 18:49:23]

https://codereview.appspot.com/9088043/diff/1/app/subapps/browser/views/charm.js
File app/subapps/browser/views/charm.js (right):

https://codereview.appspot.com/9088043/diff/1/app/subapps/browser/views/charm...
app/subapps/browser/views/charm.js:465: var viewData = Y.one('.bws-view-data');
On 2013/05/01 17:50:06, rharding wrote:
> I'm assuming this is changed because the valueFn was grabbing before the node
> was there? Can we change renderTo to work with the getter then and prevent
hard
> coding the Y.one here? The renderTo was updated to keep all the views in
common
> and for testing. This happens to work because you're using the default value
> anyway. 

Actually, when I started this line was
Y.one('.bws-view-data').setHTML(tplNode); I think this is a bad merge--I'm
totally happy to use renderTo. I've made that change and everything works.

[rharding, 2013-05-01 18:49:54]

On 2013/05/01 18:49:23, j.c.sackett wrote:
>
https://codereview.appspot.com/9088043/diff/1/app/subapps/browser/views/charm.js
> File app/subapps/browser/views/charm.js (right):
> 
>
https://codereview.appspot.com/9088043/diff/1/app/subapps/browser/views/charm...
> app/subapps/browser/views/charm.js:465: var viewData =
Y.one('.bws-view-data');
> On 2013/05/01 17:50:06, rharding wrote:
> > I'm assuming this is changed because the valueFn was grabbing before the
node
> > was there? Can we change renderTo to work with the getter then and prevent
> hard
> > coding the Y.one here? The renderTo was updated to keep all the views in
> common
> > and for testing. This happens to work because you're using the default value
> > anyway. 
> 
> Actually, when I started this line was
> Y.one('.bws-view-data').setHTML(tplNode); I think this is a bad merge--I'm
> totally happy to use renderTo. I've made that change and everything works.

Ah, thanks for the follow up. Never mind then.

[j.c.sackett, 2013-05-01 18:51:33]

Please take a look.

[jeff.pihach, 2013-05-01 19:12:40]

LGTM - however maybe you could put an XXX around those scrollto's with a small
comment as to why they are there so that someone can go and investigate at a
later time

[j.c.sackett, 2013-05-01 19:25:53]

On 2013/05/01 19:12:40, jeff.pihach wrote:
> LGTM - however maybe you could put an XXX around those scrollto's with a small
> comment as to why they are there so that someone can go and investigate at a
> later time
Done.

[j.c.sackett, 2013-05-01 19:31:12]

*** Submitted:

Resolves views rendering in partly scrolled state

This branch resolves two bugs wherein a view rendered scrolled partway down.
This appears to be an issue with browser behavior rather than JS, as
investigation showed no problem when debuggers were used to check state as the
views render.

To get around that, this branch simply grabs the top-most visible element of
the two views and ensures they're scrolled into view.

R=rharding, jeff.pihach
CC=
https://codereview.appspot.com/9088043