Table doesn't look as intended

RESOLVED FIXED in Future

Status

()

Core
Layout: Tables
P2
normal
RESOLVED FIXED
16 years ago
4 years ago

People

(Reporter: bugs, Assigned: bz)

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
I can't judge if it's poor HTML coding or a bug in Mozilla, but it's a high
visibility page, and looks very ugly in 0.9.9 (build id: 2002031008)

I will attach a screenshot if you can't reproduce it...
I assume you mean the backgrounds that are not in the right place?
(Reporter)

Comment 2

16 years ago
If that's the correct wording for it, then yes. :)

Comment 3

16 years ago
I'm seeing a javascript error. We need a test case. Moving to future (after 
m1.0) P2.

JavaScript error:
http://www.hondamotorcycle.com/models/index.htm line 293: setting a property tha
t has only a getter
Severity: minor → normal
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: qawanted
Priority: -- → P2
Target Milestone: --- → Future
OK, let me rephrase that.  "Could you please attach that screenshot"?

Is strongly suspect the site is simply misusing offset* properties in the
Mozilla-only branch of their javascript.
(Reporter)

Comment 5

16 years ago
Created attachment 73986 [details]
Incorrectly rendered table

Here is the screenshot, you just had to ask for it :)

Comment 6

16 years ago
var scrollY = 0;
function getScroll() {
  if (ie) {
    scrollY = document.body.scrollTop + 18;
  } else if (ns) {
    ===== > scrollY = window.pageYOffset + 18;
  }
}

javascript error "setting a property that has only a getter" for "scrollY"

this is a dup of bug 131311 ?

Comment 7

16 years ago
I've applied patch for bug 131311
I no longer get js error about scrolly
but now I see

Error: cell[n1].doc has no properties
Source File: http://www.hondamotorcycle.com/models/index.htm
Line: 253

so this is not a dup of bug 131311

Comment 8

16 years ago
makingtest, PEdelman@flashmail.com

Comment 9

16 years ago
It appears that the background aligning problem as well as the "cell[n1].doc has
no properties" error are caused by bugs in the web-page which doesn't check for
the correct Netscape version on some places, so it's not a Mozilla bug. (Please
let me know if I need to be more specific).
If you can verify incorrect sniffing, this should go to Tech 
Evangelism.  Reference this URL for correct sniffing procedure:
http://developer.netscape.com/evangelism/docs/articles/find-gecko/

Comment 11

16 years ago
Created attachment 87844 [details]
Testcase

I've made a testcase. The underlying problem is:
This page creates the background colors behind the table cells
(how strange) by inserting lots of background-colored divs
(c0div,e1div,d2div...)
which are positioned randomly at first but a javascript is called onLoad to
reposition them. The positions of the caption-images (like "[Touring]" in this
testcase) are read and the background-color-divs are positioned relatively to
it.
In IE, document.images[].offsetTop is used to find out the image position. In
Mozilla, document.images[].y is used. Both IE/Mozilla return a y-position
relative to the top/left corner of the *page* not the div which contains
the image. For Mozilla,however, the x/y-position of the containg div is added
*again* in Line 17/18 of the testcase.

Now there are two possibilites:
1) images[].y should unlike IE's offsetTop return only the y-position relative 

   to the containg div, then this would have to be fixed. (I doubt it)
2) we mark this WONTFIX: The browser sniffing works but forks to an
   buggy part of Javascript and inform the webmaster of this site of his
   error so he can save to find this bug ;-)

Someone would have to change keywords/status as I have no rights.
Don't get mad at me if I did something wrong I'm a newbie in bug writing.

Sorry for the long post.
Created attachment 88016 [details]
minimal-ish testcase

The problem is that in NS4 image.y is measured from the layer, while in Mozilla
it's measured from tbe body.  We need to fix that....
Attachment #87844 - Attachment is obsolete: true
Created attachment 88019 [details] [diff] [review]
Patch v1.0

So.. looks like NS4 _does_ include the border in the offset calculation
(varying the border size makes the offset bigger).  With this patch we
basically do the same thing as NS4 except of this weird 3px offset NS4 throws
in when a border is present (it throws this offset into the layout too, so not
much we can do there).
Comment on attachment 88019 [details] [diff] [review]
Patch v1.0

sr=jst
Attachment #88019 - Flags: superreview+
Comment on attachment 88019 [details] [diff] [review]
Patch v1.0

r=jkeiser
Attachment #88019 - Flags: review+
to me
Assignee: karnaze → bzbarsky
Status: ASSIGNED → NEW
checked in on the trunk.  rgpublic@gmx.net, many thanks for hunting down the
problem.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.