If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

wrong placed spacer image in cel




Layout: Tables
17 years ago
9 years ago


(Reporter: Mark van Beek, Unassigned)



Windows ME

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [awd:tbl][line-breaking], URL)


(2 attachments)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)
BuildID:    2000102620

At www.mtnsms.com I constantly get a wrong placed spacer image. You can see a 
screenshot at http://flamoes.edup.tudelft.nl/mtnsms/mtnsms.jpg

Reproducible: Always
Steps to Reproduce:
1.Go to www.mtnsms.com

Actual Results:  just look                   

Expected Results:  a right placed image...

Comment 1

17 years ago

The page has terrible html, especially the table structure. The basic problem is
one of the nested tables.  Seems that the width of the table is smaller than the
row of graphics (610 is given, but should be 620). Attaching testcse, even
though this is invalid imho.  

Comment 2

17 years ago
Created attachment 18125 [details]

Comment 3

17 years ago
updating component and setting default owner.
Assignee: asa → karnaze
Component: Browser-General → HTMLTables
Ever confirmed: true
QA Contact: doronr → chrisd

Comment 4

17 years ago
QA contact update
QA Contact: chrisd → amar

Comment 5

17 years ago
Further on in the site the view is messed up even more. (If I recall correctly
older Mozilla versions didn't mess it up this much, although they did do the
wrongly placed spacer image)

Comment 6

16 years ago
testcase isnt working properly.
Whiteboard: [awd:tbl][NEED TESTCASE]

Comment 7

16 years ago
Temporarily moving to future until a milestone can be assigned. 
Target Milestone: --- → Future

Comment 8

16 years ago
Sorry that the old screenshot is temporarily down, but I have another testcase
for you: http://www.edup.tudelft.nl/cgi-bin/index.pl

Haven't checked it with the html validator, but it looks good in IE and Opera.

Comment 9

16 years ago
Created attachment 75954 [details]
Testcase 2

This is a semi-simplified valid testcase for the bug, created from the site
mentioned in comment 8. It could be simplified further, but I don't have the
time now so I'll just attach my achievements. 

Some notes:

In this test case the problem seems to be related to the rightmost cells in the
table; if I remove them, it almost disappears.

If I change the doctype to HTML 4.0 Transitional, the problem disappears. I
guess it's a difference between quirk and standard modes.

Comment 10

16 years ago
The same problem (and many alterations of this problem) has been bugging me in
all the mozilla versions i have tested in the last.. 2 years?

One effect i notice in a lot of sites, when viewed with mozilla, is that the
images 'move' a pixel when i mouse over them, and they are links (have a <a ..>
</a> around them). The images have no javascript or any other factors, but are a
plain <a href=".."><img src=".." border=0></a> type image.. When i move my mouse
over them they apear to move one or two pixels to the left (?!)  After they
moved, and you mouse over again, they stay in the 'new' position. Then when you
reload the page, or when you even alt-tab to another window or goto a new
workspace, and the browser's content is redrawn, the images go back to the
original location, and move again when mouse-overed.

The interesting thing to notice with the above is that it seems that when you
mouse over the image, and it shifts one pixel to the left, and there is an image
to the left of it, this pixel 'is hidden under' the left image (this is very
easely to visualy see)

Somehow this offset when using links + images bug also makes it into the table
rendering code. 

In site i am using to demonstate this (http://www.boomchicago.nl/) the top part
of the table has images in it which are links, and in that top table, rendering
problems exist in mozilla (occasionaly it will show a spacing between table
cells which _both_ have a background image set, so a spacing is not posible
there!) The same goes for the 'article header' (the redish bar with the title in
it). It visualy displays spacing's between the table cells when the title in it
is in a <a href=..>..</a> situation. However when the text in the table is 
_not_ a link, no rendering errors are made.

So it would seem to me that the engine that deals with the links creates a
(offset - 1) bug in the render coordinates of the image, which in turn is then
continued into the table rendering engine, causing weird spacing errors for tables.

(i never managed to reproduce this error without using links, so the two are
definatly linked <pun intented>)

The weird thing is that images with javascript attached to them (forinstance the
left side menu on www.boomchicago.nl which uses standard dreamweaver JS for
mouse overs) the bug is _not_ present. 

Maybe the above could mean that the mouse-over event handling code has the
actual bug in it? (w/o JS, there is a bug, w/ JS there's no bug, so its logical
sounding that the 'dummy mouse over code' or 'standard mouse over handler code'
has the actual bug)

Another way to easely visualy see the bug, is to mouse over the 'boom chicago'
logo which is @ the top left of the page (http://www.boomchicago.nl).

The logo was split up into 4 images (to be able to make the table structure
work) all of which link back to / (the home page). When you mouse-over the 4
images that make up the logo, you will visualy see it 'dance around', and you
will notice how the right-two images of the logo will go 'under' the images on
the left of them. (Keep your eye on the 't' from 'amsterdam', notice one line of
pixels disapearing when you mouse-over it?)

As i mentioned in the beginning, i have been seeing this behavious since i
started testing (more then a 2 years ago), but i have always tested this on linux.

I have seen the same behaviour on all the redhat linux versions i have ran in
that time, including, but not limited to: Redhat 6.2, 7.0, 7.1, 7.2, 7.3, and
some mandrake versions. This leads me to believe it is not caused by screwed up
platform image libraries, but in the browser it self.

I have seem the same effect, regardsless of self-compiling or using pre-compiled
mozilla releases, so it is also not likely to be influanced by the build system
/ platform / libraries.

(ps, i would vote for changing the severity of this bug to 'major', since it
seems to affect all platforms, and can make for a visualy broken surfing experiance)

Also, can the bug reported, or bug owner change the platform from 'Win ME' to
'All' ? Since i am experiancing this bug in linux, and the original reported in
Windows ME, it seems to be not limited to the originaly reported platform.

Comment 11

16 years ago
(ps, you could remove the [NEED TESTCASE] keyword, since new test cases were
already provided (attached testcase 2) and the bug is also reproducable on the
site i mentioned (www.boomchicago.nl)

Comment 12

16 years ago
Pps, presumably the component could / should be switched from HTMLTables to
'Image Layout', since the image + link combination creates the bug effect, and
not the HTML table layout around it

the x-offset - 1 bug happens to for free standing images which are not
constrained in a table cell. However, it is also triggered when the link in the
able which causes the bug is plain text (the bug is never triggered by a table
structure when there are no links in it). 

So i gues the best place for this bug would be 'HTML Renderer' + 'Link parser' ?

Comment 13

15 years ago
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---


15 years ago
Target Milestone: --- → Future


14 years ago
Keywords: testcase
Whiteboard: [awd:tbl][NEED TESTCASE] → [awd:tbl]
Whiteboard: [awd:tbl] → [awd:tbl][line-breaking]

Comment 14

9 years ago
Is this still valid, I do not get what the test cases try to demonstrate.

Comment 15

9 years ago
or a dupe of bug 81947


9 years ago
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 81947
You need to log in before you can comment on or make changes to this bug.