Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Scroll-back in sectionstack when using drag & drop

    Hi,

    I've hit some problems when dragging a canvas around between nested Layouts in a SectionStack in a scrolling Canvas (the attachments contain a demo with one such nesting structure, it would take some time to explain the complete nesting structure here, it's faster to simply look at the code...).

    The scrolling canvas jumps to the top in some cases.

    To reproduce the problems:
    - a) Once the sectionStack sections are expanded and the sectionStack was scrolled down a bit, drag one of the canvases in the second section into another column of the same section. When the canvas was dropped, the scrolled area jumps to the top.
    - b) Preparation: move a Canvas to one column in the second sectionStack, so that it is longer than the other columns. Scroll down a bit.
    Now start dragging the last Canvas away from that colum. The scrolled area immediately jumps to the top.
    - c) When you scroll back down with the mouse wheel while still dragging the canvas and then drop the canvas back into another column, the scrolled area again jumps to the top.

    Points of interest:
    - this behavior only happens in FF, IE works.
    - I've noticed in my firebug that the height attribute of the column's <div> gets changed several times when a canvas gets picked up, and after a second or so the height value stabilizes.
    - dragging and dropping in the last section stack works fine, no scroll-back happens.
    - The SmartGWT 2.5 release notes already talked about a solved scroll-back problem for forms, but didn't mention dragging...

    Be sure your post includes:
    1. the SmartGWT or SmartClient version and browser version(s) involved;
    - SmartGWT 2.5 LGPL nightly build 2011-11-10
    - Reproduced with FF 4 on Windows 7, FF 6 and 7 on Linux.

    3. for a client-side problem, the contents of the Developer Console (see FAQ for usage);
    I've attached the log output with layout/sizing/scrolling info log for b) and c).
    4. if there is a JavaScript error, the stack trace logged in the Developer Console (from Internet Explorer if possible); and
    - no stack trace available.

    5. sample code.
    see attachment.

    If I can do anything to further identify the cause, just tell me.

    Greetings,
    Klaus
    Attached Files
    Last edited by klausv; 16 Nov 2011, 12:46.

    #2
    Ok, I found a workaround for me, but I really would like it if someone from Isomorphic would make an official solution from my hack...

    I added some rescuing lines to Layout._layoutChildrenDone() around a call to this.adjustOverflow():
    Code:
     ...
    _layoutChildrenDone : function (reason) {
    ...
            //this.logWarn("calling adjustOverflow, reason: " + reason);
            // start added by klausv
            if (this.notifyAncestorsOnReflow && this.parentElement != null) {
                this.notifyAncestorsAboutToReflow();
            } 
            // end added by klausv
            this.adjustOverflow();
            // start added by klausv
            if (this.notifyAncestorsOnReflow && this.parentElement != null) {
                this.notifyAncestorsReflowComplete();
            } 
            // end added by klausv
    ...
    Now, when I set notifyAncestorsOnReflow on my SectionStack in Demo.java:
    Code:
    ...
        sectionStack.setDropTypes(DRAG_TYPE);
        setNotifyAncestorsOnReflow(sectionStack);
    ...
      private static native void setNotifyAncestorsOnReflow(SectionStack sectionStack)
      /*-{
        var sectionStackJS = sectionStack.@com.smartgwt.client.widgets.layout.SectionStack::getOrCreateJsObj()();
        sectionStackJS.notifyAncestorsOnReflow = true; 
       }-*/
      ;
    ...
    , everything works just fine (just don't create the SectionStack jsObj too early, in case anybody wants to use this hack).


    @Isomorphic: Is there any chance to incorporate the changes in Layout.js into the SmartGWT 2.5 branch (or a suitable analog fix, my changes are only on a works-for-me basis)? I hope it doesn't break any other functionality...

    I've set notifyAncestorsOnReflow unconditionally without digging deeper into its semantics. As far as I understood, it was introduced to work around some native browser kinks. Does notifyAncestorsOnReflow somehow get set automatically on a per-browser basis or must a user experiencing scroll-back problems actively set it?

    Greetings,
    Klaus

    Comment


      #3
      Just a note that we're tracking this - we will try to take a look at it and see if we can incorporate your fix or a similar fix. Thanks for posting it. Please do let us know if down the road you find some unintentional side-effects and have to revise your patch.

      Comment


        #4
        Just FYI @Isomorphic: We didn't find any side effects for this correction, we've rolled out a version of our software with the patch in place.

        Comment


          #5
          Hi,

          using 3.0p we 2-22 we are facing the same issue:

          In scrolling layout, if the user opens another section, it will focus/scroll to the
          first opened section.

          Can you provide a fix for this?

          Comment


            #6
            ^^

            You had a look on it, yet ?

            Comment


              #7
              We've taken a look and we agree that Klaus' basic fix to trigger the 'notifyAncestorsAboutToReflow' / 'notifyAncestorsReflowComplete' from layoutChildrenDone if 'notifyAncestorsOnReflow' is true is correct.

              We are making this change to both mainline and the 8.2p branch.
              This will still require the developer to explicitly set the flag 'notifyAncestorsOnReflow' on the component (sectionStack) that is exhibiting problems.
              You can therefore get things working by setting this property, and FYI, this can be achieved immediately after creating the SectionStack (before it is initiated in JavaScript) by using the JSOHelper to update the 'config' object, so you can avoid the extra method to drop down to JSNI -- something like this:
              Code:
                  final SectionStack sectionStack = new SectionStack();
                  JSOHelper.setAttribute(sectionStack.getConfig(), "notifyAncestorsOnReflow", true);
              However we recognize that this isn't entirely ideal as it relies on the developer to set this flag. We are internally investigating whether this can simply be enabled in the framework automatically without introducing a significant performance hit, etc -- we'll update this thread once we have an answer on this.

              In the meantime, please try explicitly setting the property and see if it resolves the problem for you. If not, please show us a test case - it's always possible you're looking at a different issue with similar symptoms!

              Thanks
              Isomorphic Software

              Comment

              Working...
              X