On Thu, Feb 26, 2015 at 06:53:54PM +0200, John Found wrote:
On Thu, 26 Feb 2015 23:17:48 +1300 James C <james.from.wellington at gmail.com> wrote:
If I was looking for a part of the code to blame, then my current pick is: "nav.c" line 303 and friends; possibly "nav.c" line 308 but I know that I don't have a taxonomy of all "repush"es, and how to determine that this is the one where that case should not apply :-)
As I already said, my C/C++ skills are pretty low. But simply commenting out the lines 307 and 308 in "nav.c" and recompiling I got the proper behaviour of the scrolling.
The big question is what I have broke by this "solution"? :)
Most probably remembering the scroll position for Back and Forward. Before CSS, there was only one scroll offset, now there may be many (as many as different stylesheets the page has. A ridiculously large number sometimes, I *must* add).
Another question is why not to render the page only after the CSS files are received (or the receive failed)? Yes, it will slow down the first appearance of the page, but this first appearance is actually fairly useless for the most of the pages and only makes some flicker on the screen.
Let's say you set the fail timeout to 30 seconds... Can you imagine it? Now if the page has let's say 7 stylesheets. Which compete with the main page, and dozens of images for bandwith, add the "temporary unavailable" answers, or simple fails that need a retry which some servers use to avoid bots wasting BW, or peak usage hours, etc. Then, how many do we expect before drawing? The point is: there're plenty of factors. Now, AFAIR, we've had a scroll-to-anchor-bug for a long time (another one which relates to a race condition while the canvas grows). This one looks simpler (may be the same though). I'd like to look at it but currently work on a resize/redraw bugs fills my time. -- Cheers Jorge.-