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...
Tested the default call of Ajaxify i.e. animations and preview effect shut off - bug persists.
Additionally shut off the prefetch option - bug persists.
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)
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
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)
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
...before scrolling - in vain
Salient code
in
_doRender2()...which calls the
$.scrolly()sub-plugin code as followsSome tests
I performed the following test cases, that did not change the behaviour:
aniTimeandslideTimeto0- i.e. turn animations off completelypreviewofftotrue- i.e. turn off the preview featureposition()instead ofoffset()$(window).scrollTop(0)before the scroll to ID$(window)with$(document)$(window)with$("body")- completely breaks behaviour$el.scrollTop(0)- completely breaks behaviourscrollToplugins - no change in behaviour