264628 - Clicking on an image based link just moves the image - subsequent click loads the link

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Joe Schottman]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041015
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041015

This does not happen in <= Moz 1.7.3.

When you click on the bottom set of navigation images in the bottom of the page
(left arrow, up arrow, right arrow), the set of images get moved down ~8 pixels
or so.  On some occassions after the images move down, the link gets followed. 
At other times, you have to click the image a second time to get it to follow
the link.

Reproducible: Always
Steps to Reproduce:
1. Scroll to the bottom of the page.
2. Click any of the arrow based images
3.

Actual Results:  
Set of images moves down a few pixels.  In some cases the link is followed, in
others you have to click the image again.

Expected Results:  
Moz 1.6 (Linux) and 1.7.3 (Windows) (the versions I have handy) as well as IE
and Opera, the link is followed.

Images in question are pngs.  I tried to duplicate the bug on an external site,
but couldn't find one easily that uses pngs for the same purpose.

Comment 1

[Hermann Schwab]

Attachment: minimal testcase

replaced original grafics with Mozilla.org grafics, click on 'RSS' instead of
Arrows.
Style internal, float: left and clear: both 
styled elements: <div> <span> <p>

Comment 2

[Hermann Schwab]

Arrows from the original url replaced with rss.png from mozilla.org
Click on RSS to see them jumping.

<a href=""><img src="http://www.mozilla.org/images/rss.png" alt="Previous"
border="0"></a>

Always jumping: <a href="">
Once jumping:   <a href="#">
Never jumping:  <a>

Comment 3

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041015

margin-top is creating the jump, default 1em per gre/res/html.css line 51

try overriding this in the testcase: 0em stops the jumping, 3em jumps wider.

.distinct{
	clear: left;
	margin-top: 3em
	}

I´m setting Severity to major, as it isn´t normal that links are jumping around
avoiding to get working.

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

Probably a DUP of bug 261153.

Comment 5

[Hermann Schwab]

Regressed: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041007
1.8a5: 2004100605 working, 1.8a5: 2004100705 regressed

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-10-06+03%3A00&maxdate=2004-10-07+06%3A00&cvsroot=%2Fcvsroot

Perhaps the HTML-part of check-in for Bug 261707?
mozilla/ content/ html/ content/ src/ nsHTMLAnchorElement.cpp
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/content/html/content/src&command=DIFF_FRAMESET&file=nsHTMLAnchorElement.cpp&rev1=1.133&rev2=1.134&root=/cvsroot

I did the regression testing only on the testcase, which doesn´t have real
links, only href="". 

(In reply to comment #4)
> Probably a DUP of bug 261153.

No, Bug 261153 was  Opened: 2004-09-23, and bug 261153 comment 16 specifies
2004091105 - 2004091306 as regression window.

Comment 6

[Hermann Schwab]

Stephen, sorry for the noise.
This bug has the same regression timeframe as bug 261153 comment 16, and similar
testcases. The images loading here give lots of loading delay, so behaviour is
seen differently.
The builds I wrongly tested as working are showing the bug on reload, not on
first load, and that was the regression I found, though maybe it wasn´t a
regression, but an improvement, as the layout got better as a margin was
rendered which wasn´t rendered before, or something like that.

In the regression timeframe I first mentioned, 2004100605-2004100705 the
behaviour of the testcases changed, but it must also have changed somewhere
between this point and the original timeframe 2004091105-2004091306

Maybe related ?
Bug 209694 [MARGIN-C]clear margin merged with bottom margin on empty last child

feel free to dupe, mark dependent, or something else, I don´t know better.

Comment 7

[Joe Schottman]

1. I'm willing to say that this is a dupe of bug 261153.  I replaced the images
with a normal text link and it exhibits the same behaviour EXCEPT in some cases
with the images, the link is followed, just after a jump and a delay.  In none
of the times I've tried with a text link has the link been followed.  Live
example at: <a href="http://www.vbs.vt.edu/helps/Real5a.html">here</a>

2. In the live page, changing the margin-top to zero (or commenting out the
margin-top entirely) removes some, but not all of the jumps.  Increasing the
margin does increase the size of the jumps.

3. I don't know if this will help or not, but there was a bug related to floats
and clears that was fixed between 1.7.3 and the current - If you look at any of
the pages in the series cited in the first part of the report with <= 1.7.3,
sometimes the footer will display partway up the page, despite the footer having
an CSS position of absolute; bottom: 5px; clear: left (or both).  Reloading the
page causes the page to display properly.  I've tried to track down that bug but
couldn't find it, but that's a change related to floats/clear that changed.

Comment 8

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041016

I´m marking a dependency to bug 261153 until someone will decide to dupe it.

Testing the testlink, I noticed some strange effects.

http://www.vbs.vt.edu/helps/Real5a.html
clicking 'Click here' http://www.vbs.vt.edu/helps/Real4.html should be loaded.
Instead, the link jumps down below the image, a huge gap below it is created to
the next image, and the footer div jumps up, the text links 'Privacy Policy' and
Contact VBS' are rendered between the last image and the three navigation
buttons, partly overlapping the image.
When I click the second time, Real4.html is loaded, sometimes having the footer
as overlay in the mid of the page. I´ve been seeing this at other files from
this manual as well, but I didn´t find ways to reproduce.

Comment 9

[Martijn Wargers (dead)]

Fixed by bug 209694

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build 2004-12-20-05 on
https://bugzilla.mozilla.org/attachment.cgi?id=162310 under Windows XP.