202567 - {inc}International Herald Tribune page is displayed incorrectly (compare with Mozilla 1.3)

Status: RESOLVED WORKSFORME

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

Description

[Minko Markov]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4b) Gecko/20030418
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4b) Gecko/20030418

The individual news items in the page are displayed
incorrectly, at the right side, in a narrow column
one above the other.


Reproducible: Always

Steps to Reproduce:
1.go to www.iht.com/frontpage.html
2.load the same URL with 1.3
3. observe the difference




iht.com relies heavily on javascript
it has been problematic in the past with mozilla,
if that is relevant.

Comment 1

[Chris Casciano]

page seems to WFM OS X 2003041808

Comment 2

[Eric Lawrence]

encoding problem?  OS X 2003041808 guesses that the page is UTF-8 and it renders
badly, but if you switch it to ISO-8859-1 Western (via View -> Character
encoding), everything fixes itself.  This has come up in other bugs, although I
can't locate an example at the moment. 

(incidentally, I noticed this when I tried opening the page in DOM inspector--
it changes its guess to Western.  is this normal?)   

Comment 3

[Chris Casciano]

something else is going on here having to due with the page loading/intial
layout... as I'm seeing it fine over here although some elements on the screen
are fixing/adjusting themselves during the load process (including, on occation
the content in a narrower then normal column).

I have yet to have a load without an end result that doesn't look ok.

Comment 4

[Phil Schwartau]

Browser, not engine. Reassigning to Browser-General until the right
component can be determined. The site looks fine in my 2003-04-16
build on WinNT; but the same-date build on Linux exhibits the bug.
On Linux Moz said it was using the ISO-8859-1 encoding, so I don't 
know if that has any bearing -

Comment 5

[Andrew Schultz]

==> layout

Comment 6

[Andrew Schultz]

Attachment: testcase

with linux trunk 20030418, the left column is too big and the right column too
small.

reload will fix it, shift-reload will re-break it.  sometimes the testcase
displays ok even after shift-reload.  an additional shift-reload will break it.


I downloaded and inlined the <script src="...">, but the problem disappeared
with that.

1.3 release exhibits the bug with the testcase

Comment 7

[fondacio]

This also occurs on Win98SE.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6

I've also seen this on Mozilla 1.3.1 on Win98.

Comment 8

[Olivier Cahagne]

*** Bug 208575 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 209405 has been marked as a duplicate of this bug. ***

Comment 10

[David A. Cobb]

Since part of my report duplicated this, I thought the following observations
might help localize this.

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030608
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030608

Note: In general, this failure is more likely to be visible the first time the
URI is visited.  Clearing the cache should make each visit seem like the first.

This page includes a float that intends to place a bar at the top of the screen,
even though the page is scrolled.  The bar does not stay at the top, but behaves
as though there were friction with the scrolling page pulling it down.  

A rectangular area on the right-hand side may then be seen to move out of place,
causing the text to rip.  The area contains part of the right-hand ad boxes plus
part of the article text.

Trying to recover from this situation, I then did a Reload.  This caused all the
article lead paragraphs except the first to layout in a narrow column to the
right of the boxes in which they are supposed to be displayed.

NOTE: This latter problem happens 100% on Firebird (2003-06-08).

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: slightly simpler testcase

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm guessing this is a tables problem.

Comment 13

[Olivier Cahagne]

*** Bug 211463 has been marked as a duplicate of this bug. ***

Comment 14

[fondacio]

Could this be related to bug 201814? Both showed up around the same time while
iht.com worked fine before.

Comment 15

[Hermann Schwab]

*** Bug 222252 has been marked as a duplicate of this bug. ***

Comment 16

[Matthias Versen [:Matti]]

*** Bug 223850 has been marked as a duplicate of this bug. ***

Comment 17

[Damian Yerrick]

With the attached test cases, Mozilla 1.5 shows the following behavior:

  load: OK
  reload: broken
  Shift+reload: broken
  reload, then click in location bar and press enter: OK

Comment 18

[Mats Palmgren (inactive)]

*** Bug 225773 has been marked as a duplicate of this bug. ***

Comment 19

[David A. Cobb]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031210
Firebird/0.7+

First view: broken
Reload: Almost correct - could well be the source: top article text / image overlap.

shift-reload: broken
shift-reload(2): broken a different way 
shift-reload(3): broken a still different way.

Each time, the placement of the (I assume) tables changes.  The article text is
first displayed in a 1-inch column on the right, then it is the correct width
but still over in the righthand culumn which properly belongs to some advertising.  

Comment 20

[fondacio]

Appears to work correctly now with 1.6 (Win2K).

Comment 21

[Andrew Schultz]

the testcase still exhibits the bug.  the iht URL changed.

Comment 22

[Brian Lee]

Attachment: Screen shot of IHT on Mac OS X 10.2.3 with Mozilla 1.6 release

Heres a screen shot of the IHT homepage notice the text is still overlapping
the picture for the main article, but the articles below and the banner on the
side render properly.

Comment 23

[Brian Lee]

Please refer to my attachement I've attached a screen shot of the IHT page with
mozilla 1.6release on Mac OS X 10.2.3 the text is still overlapping the image
for the main article. However the articles below along with the banner on the
side of the page render correctly.

Comment 24

[Andrew Schultz]

Brian: that's a different bug (might be Evang)

Comment 25

[David A. Cobb]

Re: Comment#20
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040120
Firebird/0.8.0+

Very much still busted (the same way)

Comment 26

[Martijn Wargers (dead)]

I don't see the bug with the simpler testcase in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/2004-02-15
Firebird/0.8.0+
and newer builds.
However, I see the bug with the simpler testcase in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/2004-01-13
The left table cell with the images is taking almost all of the space in this build.

Comment 27

[Mats Palmgren (inactive)]

WFM, 2004-08-05-10 trunk Linux.

Comment 28

[Steve England [:stevee]]

I see no difference in layout of reflowing with "slightly simpler testcase" with these two builds:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)

Comment 29

[Andrew Schultz]

as suggested by comment 26, this worked in Mozilla 1.7.x