Hi all. It is my first post on this mailing list. I want to use Dillo as a HTML help browser for my program. I need it, because it has faster startup time and this is very important for a help system, where the user presses F1 and expects the help to open instantly. (What is not the case with all other browsers). Anyway, the problem I have is that when starting Dillo with URL that contains local anchor ID, it first positions properly, but short time later, (when the CSS get loaded?) it repositions the page and the needed element moves somewhere else, very far from the current page position. Example that can be tested: http://fresh.flatassembler.net/index.cgi?page=content/articles/2_FreshLibDoc... Once the page is loaded (on the wrong position), pressing Ctrl+R or clicking on "Reload" button, repositions the page to the proper position. Is this problem can be easily solved? I can try to fix it by myself, but my C/C++ skills are very low and then I will need some assistance. Best Regards and thanks for the great browser. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
Hi All, I can reproduce the reported behavior, with the reported test-case, with source up to change 986b7e7 I'm fairly sure that: - the page loads, and a scroll position is determined - the css loads, and the page is re-drawn -- wrongly, at the same scroll position, rather than at the scroll position that now matches the request I'm fairly sure that FRAGMENT is the part of the URL that contains a request to scroll to an anchor. 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 :-) Regards, James. On 26/02/2015, John Found <johnfound at asm32.info> wrote:
Hi all. It is my first post on this mailing list.
I want to use Dillo as a HTML help browser for my program. I need it, because it has faster startup time and this is very important for a help system, where the user presses F1 and expects the help to open instantly. (What is not the case with all other browsers).
Anyway, the problem I have is that when starting Dillo with URL that contains local anchor ID, it first positions properly, but short time later, (when the CSS get loaded?) it repositions the page and the needed element moves somewhere else, very far from the current page position.
Example that can be tested: http://fresh.flatassembler.net/index.cgi?page=content/articles/2_FreshLibDoc...
Once the page is loaded (on the wrong position), pressing Ctrl+R or clicking on "Reload" button, repositions the page to the proper position.
Is this problem can be easily solved? I can try to fix it by myself, but my C/C++ skills are very low and then I will need some assistance.
Best Regards and thanks for the great browser.
-- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
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"? :) 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. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
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.-
On Thu, 26 Feb 2015 15:09:15 -0300 Jorge Arellano Cid <jcid at dillo.org> wrote:
Most probably remembering the scroll position for Back and Forward.
Well, surprisingly not. I didn't tested extensively, but simply browsing several URLs and navigating forward/backward works fine and the page is positioned exactly where the page was left.
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.
Well, yes there are plenty of factors. But IMHO, there are some arguments for the opposite: If the page is already received (at least partially) there is very big probability that the CSS files (if they are on the same web site) will be delivered successfully and approximately in the same time range. If this time is small enough, why not to wait a little in order to get better user experience (not flickering pages). There is some network performance limit, where rendering the page twice will be slower than waiting for the CSS files and rendering once. As long as with the time the network performance increases and with the Dillo supporting more and more HTML features, the rendering speed is expected to decrease, then this wait for the CSS files probably will be implemented one day. This way IMHO, some more complex logic (and probably some heuristics) could improve the overall performance. At least, this feature deserves dillorc option. :)
I'd like to look at it but currently work on a resize/redraw bugs fills my time.
Take your time! You are doing great work in all cases. Best Regards. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
Hi, On Thu, 26 Feb 2015 18:53:54 +0200 John Found <johnfound at asm32.info> 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"? :)
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.
well, that depends on the situation and available bandwidth, In many cases I even disabled the css because I wanted to use some forms before css is loaded. I prefer the way it is now. Greetings Andreas Kemnade
-- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
On Thu, 26 Feb 2015 19:39:54 +0100 Andreas Kemnade <andreas at kemnade.info> wrote:
well, that depends on the situation and available bandwidth, In many cases I even disabled the css because I wanted to use some forms before css is loaded. I prefer the way it is now.
Your logic is wrong here. If the current implementation is fine, you should not disable CSS, but you could work on these forms on the first rendered screen (without CSS) and to continue to work transparently when the page refreshes after the CSS get loaded. Your need to disable CSS proves exactly my theory: The first, fast, CSS-less rendering is useless at all and only provides screen flickering. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
Hi, On Thu, 26 Feb 2015 21:03:18 +0200 John Found <johnfound at asm32.info> wrote:
well, that depends on the situation and available bandwidth, In many cases I even disabled the css because I wanted to use some forms before css is loaded. I prefer the way it is now.
Your logic is wrong here. If the current implementation is fine, you should not disable CSS, but you could work on these forms on the first rendered screen (without CSS) and to continue to work transparently when the page refreshes after the CSS get
Forms are disabled so that you cannot enter data when there is still css to load. So I have to disable CSS if I do not want to wait ages in theese cases. BTW: What was the reason for that behaviour?
loaded. Your need to disable CSS proves exactly my theory: The first, fast, CSS-less rendering is useless at all and only provides screen flickering.
So a blank screen is your preferred way to fill out forms or should I rather wait some minutes before starting to work on the page? I do not understand your logic. As you write in your other mail, some more intelligent solution might help, like wait 2 seconds and if css is not there, display what is displayable, so no flickering with good internet connection and no site problems. Greetings Andreas Kemnade
Andreas wrote:
Forms are disabled so that you cannot enter data when there is still css to load. So I have to disable CSS if I do not want to wait ages in theese cases. BTW: What was the reason for that behaviour?
Here's the relevant thread: http://lists.dillo.org/pipermail/dillo-dev/2009-April/006310.html
On Thu, 26 Feb 2015 22:34:45 +0100 Andreas Kemnade <andreas at kemnade.info> wrote:
So a blank screen is your preferred way to fill out forms or should I rather wait some minutes before starting to work on the page? I do not understand your logic.
Waiting for the CSS prior to rendering the page, does not forbid switching CSS off, as you described. Both features can co-exists without any conflict. My logic is that if the CSS files loads so slow as you describe (I still think it is a very, very rare case that can not rule the whole design), it is not important whether the rendering will happen twice or once - the page still will be not usable at all and you will need to disable CSS in order to get some usability at all. Notice, that nothing changes for your mentioned site, but on the normal, fast web sites, the screen flicker will be removed at all. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
Peripheral to the original issue, preserving smooth behavour of a form across a re-render would be an interesting (possibly in a slightly hair-pull way) problem. The content of fields, cursor position, and keystrokes received during the re-render, would all have to be preserved. I'm not volunteering. Regards, James. On 27/02/2015, John Found <johnfound at asm32.info> wrote:
On Thu, 26 Feb 2015 22:34:45 +0100 Andreas Kemnade <andreas at kemnade.info> wrote:
So a blank screen is your preferred way to fill out forms or should I rather wait some minutes before starting to work on the page? I do not understand your logic.
Waiting for the CSS prior to rendering the page, does not forbid switching CSS off, as you described. Both features can co-exists without any conflict.
My logic is that if the CSS files loads so slow as you describe (I still think it is a very, very rare case that can not rule the whole design), it is not important whether the rendering will happen twice or once - the page still will be not usable at all and you will need to disable CSS in order to get some usability at all. Notice, that nothing changes for your mentioned site, but on the normal, fast web sites, the screen flicker will be removed at all.
-- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
I kept thinking about this, and I think I have some unimplementable poetry for a correct behaviour, and some implementable prose that would do as a substitute. The poetry is: whatever the user is attending to: after the re-render, it should be in the same place on the screen. It's unimplementable because: - we don't know where in the rectangle the user is attending - different parts of the rectangle can move in different directions -- eg folding up navigation links into a side-bar - parts of the rectangle can be forced to move horizontally, in ways that we would not be able to cancel out with scrolling The prose is: however far the (top of the) page is displaced from the anchor position, after the re-render, the top of page should be displaced by the same amount from the new anchor position. Do people think that this prose is a reasonable version of correctness? Regards, James. On 28/02/2015, James C <james.from.wellington at gmail.com> wrote:
Peripheral to the original issue, preserving smooth behavour of a form across a re-render would be an interesting (possibly in a slightly hair-pull way) problem.
The content of fields, cursor position, and keystrokes received during the re-render, would all have to be preserved.
I'm not volunteering.
Regards, James.
On 27/02/2015, John Found <johnfound at asm32.info> wrote:
On Thu, 26 Feb 2015 22:34:45 +0100 Andreas Kemnade <andreas at kemnade.info> wrote:
So a blank screen is your preferred way to fill out forms or should I rather wait some minutes before starting to work on the page? I do not understand your logic.
Waiting for the CSS prior to rendering the page, does not forbid switching CSS off, as you described. Both features can co-exists without any conflict.
My logic is that if the CSS files loads so slow as you describe (I still think it is a very, very rare case that can not rule the whole design), it is not important whether the rendering will happen twice or once - the page still will be not usable at all and you will need to disable CSS in order to get some usability at all. Notice, that nothing changes for your mentioned site, but on the normal, fast web sites, the screen flicker will be removed at all.
-- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev
participants (5)
-
andreas＠kemnade.info -
eocene＠gmx.com -
james.from.wellington＠gmail.com -
jcid＠dillo.org -
johnfound＠asm32.info