You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Casey Link <ca...@outskirtslabs.com> on 2016/05/28 14:35:54 UTC

RemoveRowLink causing scoll jumping

Hi folks,

Within an AjaxFormLoop, I have my RemoveRow Link. I am using the "no
changes persisted until save is pressed" pattern from Jumpstart
(http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formloop1).

Accordingly, my onRemoveObject() method is empty.

In Tapestry 5.4, when I press the remove link, the entire viewport jumps
back to scroll position 0 (aka, the top of the page). Otherwise,
everything works: the item is removed from the list, etc.

If it matters, the AjaxFormLoop is a child of a Zone and Form (in that
order), but in T5.3 I never had this issue.

Any tips?


Casey

-- 
Casey Link

Outskirts Labs { https://outskirtslabs.com }
Technology for Changemakers


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: RemoveRowLink causing scoll jumping

Posted by Casey Link <ca...@outskirtslabs.com>.
Hi again, back with some more information.

It turns out this behavior only occurs when the Confirm mixin is
attached to the remove link.

The content is not scrolled until the modal is closed with the confirmed
action. If the modal is canceled, the scroll position stays the same as
expected.

Stepping through the JS code the offending line is in
t5/core/confirm-click.coffee:94
    window.location.href = target.attr "href"

https://github.com/apache/tapestry-5/blob/master/tapestry-core/src/main/coffeescript/META-INF/modules/t5/core/confirm-click.coffee#L94

I thought I could workaround this by adding the "data-update-zone"
attribute to my removerowlink, however because the code returns
undefined instead of false, the confirmed click event is not propagated
upwards to the ajax form loop handler.

The coffee script code is vague:

      return if target.attr "data-update-zone"
      # See note above; this replicates the default behavior of a link
element that is lost because
      # of the
      window.location.href = target.attr "href"
      return false

But the generated JS makes the bug readily apparent:

       if (target.attr("data-update-zone")) {
        return; // <------------ THIS SHOULD return false, to ensure
event propagation
      }
      window.location.href = target.attr("href");
      return false;

I suppose this is a bug in T 5.4?

This is most probably related to the Confirm mixin causing double
eventlink submissions phenomenon I observed here
http://mail-archives.apache.org/mod_mbox/tapestry-users/201605.mbox/%3C5732356C.5040306@outskirtslabs.com%3E

Best,
Casey

Casey Link

Outskirts Labs { https://outskirtslabs.com }
Technology for Changemakers

On 05/28/2016 04:35 PM, Casey Link wrote:
> Hi folks,
>
> Within an AjaxFormLoop, I have my RemoveRow Link. I am using the "no
> changes persisted until save is pressed" pattern from Jumpstart
> (http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formloop1).
>
> Accordingly, my onRemoveObject() method is empty.
>
> In Tapestry 5.4, when I press the remove link, the entire viewport jumps
> back to scroll position 0 (aka, the top of the page). Otherwise,
> everything works: the item is removed from the list, etc.
>
> If it matters, the AjaxFormLoop is a child of a Zone and Form (in that
> order), but in T5.3 I never had this issue.
>
> Any tips?
>
>
> Casey
>