Re: Problem with page positioning.

On Thu, Feb 26, 2015 at 06:53:54PM +0200, John Found wrote:
> On Thu, 26 Feb 2015 23:17:48 +1300
> James C <[email protected]> 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.-