I've now encountered this bug again on another page, and have a little
understanding of what's happening.
Apparently, mozilla is trying to format the text and determine where the
fragment reference occurs *before* it has loaded images. If the HTML
on the loaded page does *not* specify the width and height attributes
of an image, mozilla allows some default space (probably zero?) for it
and goes on. Its estimate of where the fragment anchor will be on the
page is then earlier in the final display than the proper location.
If you ask it to "reload" the page after the images have been loaded,
mozilla now knows how big the images are, and allows the proper space
for them; so it finds the correct location for the fragment reference.
Specifying "width=***" and "height=***" attributes (giving the correct
dimensions for the images -- which are easily determined by using the
"identify" command from the ImageMagick package) allows mozilla to
allocate the correct amount of space for the images as it loads the text.
Then the fragment reference will go to the correct place in the page as
it loads.
The correct behavior for mozilla would be to wait until it has loaded an
image file to determine the space to allow for the image, rather than
to go ahead and load pages and assume some (incorrect) default size.
This deferral need only occur when a link refers to a fragment rather than
a whole page. It seems to me there's some obscure configuration setting
that affects this, but I can't seem to find it. Given the difficulty of
configuring mozilla's preferences, I think the observed behavior should
be considered a bug rather than a feature.
-- A. T. Young
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
