Bug: Applying MoveTo on Pinned Panels is broken

#1

Steps to Reproduce:

  1. Add a pinned panel to the top of a page.
  2. In the OnWindowScroll event for the page, set the pinned panel to move to [[ - Window.scrollY]]
  3. If you are doing this in a new project you will need to add some object down the page so you can scroll
    Expected Results:
    Scrolling the window should result in the pinned panel moving with the page. (like it was not pinned)
    Actual Results:
    Scrolling the window causes the pinned panel to move upward off the screen. Even scrolling back to the top causes the pinned panel to move upward.

A better way to reproduce the problem is to load the attached rp file into both Axure 8 (which shows the correct behavior) and Axure 9 and compare them.

Sticky Mobile Test.rp (50.8 KB)

The file also show why I do this in the first place. I want my header to be sticky on Mobile, but not on desktop. The logical question here is, “Hey, Brian, why don’t you just use the OnWindowScroll event to “pin” the header on mobile, instead of trying to override an already pinned header on desktop?” Answer: Well, because when I do that the mobile header skips up and down as I scroll, whereas the pinned version stays put nicely as I scroll. Given that, you would think that using my approach, the desktop header would skip, but it doesn’t. It scrolls with the page nicely.

#2

Hi bedgin!

Just to confirm, did you experience this incorrect movement behavior while using a mobile device, or while previewing the “Base” view on your computer’s web browser? I have not been able to reproduce this behavior on a mobile device, but I have been able to reproduce this behavior in your file and in a new file in a web browser. It looks as if the “Move to” action is overruling the dynamic panel’s pin to browser styling and pushing the dynamic panel past it’s original (0,0) positioning and into negative vertical space.

This behavior appears to be unexpected, so I will be filing a bug report regarding your experiences with our QA team. One workaround to this issue in the meantime could be to place a duplicate header on your “Base” adaptive view, remove the pin to browser styling, and then unplace the pinned and unpinned versions of the header according to the needs of the adaptive view.