280918 - when following a link with a name tag to a specific spot on the page, Firefox misses by several screens the first time

Status: RESOLVED EXPIRED

(Firefox :: General, defect)

Description

[Dan Kriegman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

On this page (www.yoism.org), when clicking on the link (in the upper right hand
corner) to "Video of a Genuine Miracle"
(http://www.yoism.org/index.php?id=word#miracles)
which should go to the point in the "word" page where the "miracles" tag is
located, Firefox misses by several screens.

However, this always happens but only the first time that Firefox is directed to 
http://www.yoism.org/index.php?id=word#miracles.

If I go back to www.yoism.org and hit the link again, Firefox renders the page 
correctly.

If I hit reload, the page is rendered correctly.

If I close the window altogether but Firefox is still running and I return and
click the link, the page is rendered correctly.

It only happens the first time I go to that page and name tag.

I assume this has to do with cache?  I found many bugs similar to this (needing
to hit reload to get the page to render right or page position being wrong when
using the back button) so this may not be a new bug.  But I didn't see any that
involved page position being wrong going forward with an embedded name tag.

Reproducible: Always

Steps to Reproduce:
1.go to www.yoism.org

2.click link to "Video of a Genuine Miracle" (upper right hand corner of screen)

3.hit reload or hit the back button and then go to step 2 and the page will
render correctly.

4.as long as Firefox remains open, step 2 will now result in page rendering
correctly

Actual Results:  
First time after Firefox is opened, when link is followed, Firefox goes to a
point in the document several screens above the named tag.  After the first try,
it works correctly when tried again.

Expected Results:  
Go to the correct point the first time.

If this is related to cache, then it may be related to another bug that has been
reported for several years (that I have also encountered):  Animated gifs do not
display correctly unless I hold down the shift key and hit reload and/or unless
I manually empty the cache and hit reload.  Not sure there is any relation
between the bugs, but it seems to have something to do with the way Firefox
handles cached  info.  In the GIF bug, the cached info presents the correct
reloading of the page.  In this bug, the page only loads correctly after there
is some info in the cache.

Comment 1

[Dan Kriegman]

Sorry.  I forgot to mention that the problem can be recreated by emptying the
cache.  That is, the second and subsequent attempts to follow the link lead to
the page rendering correctly.  But if I empty the cache, the next try produces
the problem again.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Works fine for me. Could be caused by the plugin I suppose, it doesn't seem to
be bug 162369.

Comment 3

[Dan Kriegman]

To Gavin:

If you empty the firefox cache and then go to
http://www.yoism.org/index.php?id=word#miracles it renders a screen with
"Witnessing genuine miracles" at the top of the page?  It doesn't for me until I
hit reload.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #3)
> To Gavin:
> 
> If you empty the firefox cache and then go to
> http://www.yoism.org/index.php?id=word#miracles it renders a screen with
> "Witnessing genuine miracles" at the top of the page?

Yes.

Comment 5

[Dan Kriegman]

I don't know if this is obvious---or if you have time to answer this---but what
plugin?  The media players?  And why would they cause firefox to lose its place
around a name tag?  Finally, do you understand why it would work for you and not me?
 
Dan
 
In a message dated 2/3/2005 6:50:07 P.M. Eastern Standard Time,
[e-mail] writes:
https://bugzilla.mozilla.org/show_bug.cgi?id=280918


[e-mail] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]




------- Additional Comments From [e-mail]  2005-02-03 15:48 PST -------
Works fine for me. Could be caused by the plugin I suppose, it doesn't seem to
be bug 162369.

Comment 6

[Ben Fowler]

It may be due to the plugin, but that could be a side effect. Is it due to
the "weight" of the page, id est, the downloading of all those media files?

When Firefox comes to jump to a "named anchor" it is bound to have difficulty
if that part of the page has not been downloaded or flowed.

This won't occur when the HTML can be reloaded from cache and is complete, 
ready to be flowed and rendered.

Yes, pressing reload will also correct this as Firefox will then have 
the location of the anchor to hand. I have seen this on the web for as 
long as there has been a web, and reloading a link to a named anchor is
instinctive to me.

I normally only see this with very long pages exempli gratia 
http://linux-ip.net/html/linux-ip.html#links-software : 
you appear to have shown that it can also occur when the home
or index page to a site has much linked media. 

This may be a rare case where you need to use frames, or possibly 
break your subject matter up into smaller chunks. You could re-assemble
it into one long page when your users have T1 network connections or
better.

Comment 7

[Dan Kriegman]

To Gavin and Ben:

Three things.  

One, thanks a lot!  This has been very helpful and saved me a great deal of work.

Two, I will adjust to the problem (probably break the page into smaller pages).
 But it still seems like a bug to me if IE renders the page correctly and FF
does not.  Ben, you have become "used to" this problem; have you been using
Mozilla for years?  I.e., is there an inherent problem that could be fixed?

Three, a long shot:  Could the explanation of this issue have anything to do
with the three year old unresolved problem with animated gifs?  This was
Bugzilla Bug 129986 which I referred to in comment #1?  

From comment #1:  "If this is related to cache, then it may be related to
another bug that has been reported for several years (that I have also
encountered):  Animated gifs do not display correctly unless I hold down the
shift key and hit reload and/or unless I manually empty the cache and hit
reload.  Not sure there is any relation between the bugs, but it seems to have
something to do with the way Firefox handles cached info.  In the GIF bug, the
cached info prevents the correct reloading of the page.  In this bug, the page
only loads correctly after there is some info in the cache."

That is, if IE is "waiting" to get all the info it needs before it decides where
to go on a page, does it also wait to get all the instructions from the gif file
about the animation before deciding what to do with it?  Meanwhile, to speed
things up, Mozilla is not waiting as long and looks to cache to double check in
the rare event that the info needed wasn't available.  If it finds the final
state of the gif there, it renders it (overriding the instructions arriving in
the reloaded gif itself) and does not play the animation correctly unless the
cache is emptied.  Rather than wait for the entire page to load to decide where
to go, it follows that instruction last assuming that, by that time, things will
be loaded, and then double checks the cache (or the information from the cache
is used to override its earlier decision) for those rare times when the info
needed didn't arrive in time and then it gets it right.

If this makes any sense at all, it might be helpful to those folks struggling
with the other problem.

Comment 8

[Ben Fowler]

(In reply to comment #7)
> To Gavin and Ben:
>  ... But it still seems like a bug to me if IE renders the page correctly 
> and FF does not.  Ben, you have become "used to" this problem; have you 
> been using Mozilla for years?  I.e., is there an inherent problem that 
> could be fixed?

Yes I have been using Mozilla since the year 2000; before that I used iCAB.

I don't see an 'inherent problem'. If I am loading a URL such as the one
I quoted, there will be a long period time during which the 'target' is
below the bottom of the window. Obviously, the browser cannot scroll
to that point. If anything happens to pause or interrupt that process
(such as the user hitting the 'stop' button), then I
wouldn't expect the browser to correct the scroll, or even have a notion
of where the target scroll is, until the reload button is pressed, 'unlocking'
or 'unpausing' the screen.

If you really want the kind of control over your readers' experience
that the phrase "IE renders the page correctly and FF does not" then 
you need to use Flash or even a full multimedia format rather than HTML.

Since there are now standards compliant browsers, web authors have
no excuse for ignoring the fact that the render and the user experience
is not not going to be the same in all browsing situations. You will be 
able to make your life easier if you break your content into chunks
each of which can be appreciated in isolation, and each of which
can be presented in 8 seconds or less. This is what lead be to the
suggestion of frames (I assume that you are expert enough to use frames
competently).

> That is, if IE is "waiting" to get all the info it needs before it 
> decides where to go on a page, ...

I am not, of course, all that familiar with IE, but if it really waits until
all your media are downloaded before beginning to scroll and render the page,
then your users are probably waiting beyond the maximum that 'normal'
people are prepared to wait. Have you had feedback on this?

If you can you want to read pp 15-16 of Nigel Macfarlane's book
'Rapid Application Devlopment with Mozilla', the sections starting
"Gecko Content Display Model" - I have looked and have not found 
anything on the web that covers this quite as well - in particular
you want to form a clear mental picture of how the layout strategy 
has matured and how the Mark III strategy (in Macfarlane's terminology)
differ's from the Mark II one.

Comment 9

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 10

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.