130415 - Table doesn't look as intended

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P2)

Description

[bugs]

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...

Comment 1

[Boris Zbarsky [:bzbarsky]]

I assume you mean the backgrounds that are not in the right place?

Comment 2

[bugs]

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

Comment 3

[karnaze (gone)]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[bugs]

Attachment: Incorrectly rendered table

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

Comment 6

[Bernard Alleysson]

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

[Bernard Alleysson]

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

[Pieter Edelman]

makingtest, [e-mail]

Comment 9

[Pieter Edelman]

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).

Comment 10

[Jonadab the Unsightly One (Nathan Eady)]

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

[r]

Attachment: 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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: 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....

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: 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 14

[Johnny Stenback (:jst)]

Comment on attachment 88019 [details] [diff] [review]
Patch v1.0

sr=jst

Comment 15

[John Keiser (jkeiser)]

Comment on attachment 88019 [details] [diff] [review]
Patch v1.0

r=jkeiser

Comment 16

[Boris Zbarsky [:bzbarsky]]

to me

Comment 17

[Boris Zbarsky [:bzbarsky]]

checked in on the trunk.  [e-mail], many thanks for hunting down the
problem.