dojox.mobile.Opener should scroll page to keep field in view

[colinsullivan]

When selecting a field that is linked to an instance of with a dojox.mobile.Opener, it seems to me that the intention is to show the field directly above the opener once it is opened, as this is the native behavior on mobile devices.

Here is an opener test from dojox/mobile/tests/ with the input field pushed down to the bottom of the page: ​http://dojo.colin-sullivan.net/dojox/mobile/tests/test_Opener-DateSpinWheel-async-below.html

This is tricky because there is no more page to "scroll". I actually don't have any ideas on how to implement this. I am hoping you folks will.

[Sebastien Brunot]

Look like not only the page is not scrolling to keep the field in view (note that the Opener try to do that, by doing a window.scrollBy), but there is actually a bug when this is done in a ScrollableView. I've attached a test page (test_Opener-scroll.html) to reproduce this: open in on Safari iPhone, scroll the view down to the field and click it: the opener is displayed above the field, not at the bottom of the screen...

[Sebastien Brunot]

defect when using the opener in a ScrollableView?

[Sebastien Brunot]

Fix overlay display in scrollable views for branch 1.8 (IBM CCLA).

[Sebastien Brunot]

I've attached a patch that fix the display of an overlay in a scrollable view (13865-scrollableView-1.8.patch) for branch 1.8. It didn't implements the requested scroll, though.

[Sebastien Brunot]

I've attached a patch that fix the display of an overlay in a scrollable view (13865-scrollableView-trunk.patch) for trunk. It didn't implements the requested scroll, though.

[Sebastien Brunot]

Fix overlay display in scrollable views for trunk (IBM CCLA).

[Adrian Vasiliu]

sbrunot, a few remarks:

• I see the patch for trunk relies on viewRegistry.getEnclosingScrollable() while the patch for 1.8 doesn't (instead it reimplements it). Maybe there's a reason for that, could you please clarify?
• I would think you should override widget's destroy() to cleanup the reference to the scrollable parent that you introduced (to avoid memleaks).
• It is for performance reasons that you store the scrollable parent in a widget field instead of recomputing it, right? Indeed, this reposition() method is called often, but maybe it would be worth checking if it really matters in practice. If the overhead is small, we could get rid of storing this reference.
• (minor) There are some blanks instead of tabs in the patch (including in doc comments of the new private field).

[Sebastien Brunot]

Thanks for your review Adrian. As a consequence, I've updated my fix and submitted a pull request on github: ​https://github.com/dojo/dojox/pull/12

Note that this does only fix the defect described in comment ​https://bugs.dojotoolkit.org/ticket/13865#comment:2

[Adrian Vasiliu]

Thanks. I've made a few minor comments there. Now, since this fixes a related issue but not the issue described in this ticket, I doesn't seem appropriate to close this ticket once committing this fix. Instead, creating a new distinct ticket for the issue you fixed seems preferable. What do you think?

[Sebastien Brunot]

I agree that this ticket shouldn't be closed. I leave it up to you to decide to create a dedicated ticket or to commit this other fix without a corresponding ticket (or a reference to the comment on this one).

[Adrian Vasiliu]

Ok, I created #17229 for this distinct issue.

[Sebastien Brunot]

Replying to Adrian:

Ok, I created #17229 for this distinct issue.

Thanks you Adrian.

[Adrian Vasiliu]

I propose to close this ticket as wontfix, because no reasonable way to implement it (= to make a page scroll beyond its upper limit) has been found or appears realistically possible, and because the current behavior doesn't really forbid using the widget nor degrades significantly its usability. I will wait for feedback a while before doing it.