scrollTop moody - again #96

Closed
arvgta opened this Issue May 22, 2016 · 0 comments

Projects

None yet

1 participant

@arvgta
Owner
arvgta commented May 22, 2016 edited

EDIT: This may be a nuissance specific to 4nf.org and was not yet re-produced on other sites,
The bounty of €100 still applies, payable via PayPal, even if this issue is closed for now...


Please see also discussion at jQuery forum

Tested the default call of Ajaxify i.e. animations and preview effect shut off - bug persists.
Additionally shut off the prefetch option - bug persists.

I have created this log file with advanced logging for inspection


Bug description

The bug can be observed, when clicking on an internal link in the main content div, that has a hash in its URL. (e.g. on the green links on Ajaxify overview)

The desired behaviour is for Ajaxify to scroll to the specified ID on the target page, which does not work the first time around. (It seems, that on subsequent clicks - it works)

What really happens with internal links in the content div, the first time around, is that it scrolls much too far down, much like in #52, at the time...


Todos (possible culprits)

  • Make sure, that the default click is not being performed in addition to the scroll.
    (However, I don't think that is the case because Ajaxify performs an unconditional stopBubbling here)

Preliminary research on the web

See also: Similar thread at stackoverlow
or
Similar thread at jQuery forum - scrollTop is inaccurate
or
this thread - How to animate scrollTop to an offset, when it is animating a font resize concurrently, changing the offset value

While the bug could be a timing problem, it is not due to the animations.


Please see also underlying Pronto solution, which most presumably works.
The logic I use is almost identical.
Therefore, there is really only room for a timing problem.

Funny enough, the desired scrollTop() works on Microsoft Edge...


In a first attempt, I have tried to force a jQuery

stop(true, true) //stop animation of main content div

...before scrolling - in vain


Salient code

in _doRender2()

$.scrolly(url);

...which calls the $.scrolly() sub-plugin code as follows

    else {  
        var url = o;
        if (url.iO('#') && (url.iO('#') < url.length - 1)) { //if hash in URL and not standalone hash
            var $el = $('#' + url.split('#')[1]); //extract part to the right of hash
            if (!$el.length) return; //nothing found -> return quickly
            $(window).scrollTop($el.offset().top); // ...animate to ID
        }
    }

Some tests

I performed the following test cases, that did not change the behaviour:

  • set aniTime and slideTime to 0 - i.e. turn animations off completely
  • set previewoff to true - i.e. turn off the preview feature
  • used position() instead of offset()
  • inserted a $(window).scrollTop(0) before the scroll to ID
  • replaced $(window) with $(document)
  • replaced $(window) with $("body") - completely breaks behaviour
  • replaced the last line with $el.scrollTop(0) - completely breaks behaviour
  • Tried introducing a third $.stop() - no change in behaviour
  • Tried out a few scrollTo plugins - no change in behaviour
  • Tried inserting a test anchor on our partner site which employs the default options - works!
  • Tested the default options on 4nf.org - does not work
@arvgta arvgta added the bug label May 22, 2016
@arvgta arvgta changed the title from scollTop moody - again to scrollTop moody - again May 22, 2016
@arvgta arvgta closed this May 24, 2016
@arvgta arvgta reopened this Jul 21, 2016
@arvgta arvgta referenced this issue Jul 21, 2016
Closed

Smart scroll #93

@arvgta arvgta closed this Oct 8, 2016
@arvgta arvgta reopened this Oct 29, 2016
@arvgta arvgta closed this Nov 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment