Closed
Bug 58193
Opened 24 years ago
Closed 15 years ago
wrong placed spacer image in cel
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
Future
People
(Reporter: markvanbeek, Unassigned)
References
()
Details
(Keywords: testcase, Whiteboard: [awd:tbl][line-breaking])
Attachments
(2 files)
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•24 years ago
|
||
http://validator.w3.org/check?uri=www.mtnsms.com 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•24 years ago
|
||
Comment 3•24 years ago
|
||
updating component and setting default owner.
Assignee: asa → karnaze
Status: UNCONFIRMED → NEW
Component: Browser-General → HTMLTables
Ever confirmed: true
QA Contact: doronr → chrisd
Comment 5•23 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)
testcase isnt working properly.
Whiteboard: [awd:tbl][NEED TESTCASE]
Comment 7•23 years ago
|
||
Temporarily moving to future until a milestone can be assigned.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Reporter | ||
Comment 8•23 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•22 years ago
|
||
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•22 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•22 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•22 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•21 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
QA Contact: amar → madhur
Target Milestone: Future → ---
Updated•21 years ago
|
Target Milestone: --- → Future
Whiteboard: [awd:tbl] → [awd:tbl][line-breaking]
Comment 14•16 years ago
|
||
Is this still valid, I do not get what the test cases try to demonstrate.
Comment 15•16 years ago
|
||
or a dupe of bug 81947
You need to log in
before you can comment on or make changes to this bug.
Description
•