187901 - images don't line up at nationalgeographic.com

Status: RESOLVED WORKSFORME

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

Description

[R.K.Aa.]

2003010522 trunk, Linux
confirmed by several people on IRC

Not quite new - i see this with a week old CVS also:

Load http://www.nationalgeographic.com/
Notice that the images at top don't line up
Now select View->Text zoom->smaller
And then make the text 100% again

Result: The images now line up like they should have done intially.

Now hit reload (not shift-reload):
Result: Page lays out wrong again.


I browse that site once a month or so, and can't remember that it rendered like
this before. Possible regression.

Comment 1

[Ruslan Ismailov]

The source of this case is style (it applied to sertain select with "go" button
after it):

#magazines { width: 142px; }

This slect placed in one subcolumn of left column, and it is obvious, that there
is not enough place for each 142px' select in with column. When you lovered
zoom, letter become smaller and it's becoma possible to layd in this one in cell.

So this is precise width box inside not to low width cell. 

P.S. correct value in such case in { width: 100%; }

Comment 2

[R.K.Aa.]

So why is the layout still correct when i zoom up to 100% zoom again?

Comment 3

[Ruslan Ismailov]

Seems to be zooming bug, because anytime I switch zoom to 100% (only exept 100%
to 100% of course), table switched to correct view, even before this zooming
table was incorrect, it become correct. So load on zoom 120% (table incorrect),
that zoom to 100% -- correct.  

Comment 4

[Ruslan Ismailov]

BTW, I think that this kind of incorrect zooming describe in bug 103582.

Comment 5

[kfoozd]

Marking invalid - Temp seek review

Comment 6

[R.K.Aa.]

huh?

Comment 7

[R.K.Aa.]

same problem at
http://www.dagbladet.no/nyheter/2003/01/12/358409.html

Comment 8

[Andrew Schultz]

Attachment: testcase

testcase exhibits the bug with linux trunk 20030112
on initial load, the blue div (a floating image from the original) is put to
the right of "foooooooooooooobar" (the select dropdown from the original).  on
text zoom-up, foooobar goes below the div and layout is fixed.	zooming back to
normal is still ok.

Comment 9

[Andrew Schultz]

this is similar in spirit to bug 188634

==> tables

Comment 10

[R.K.Aa.]

Adding regression keyword.

This worked perfectly before, see for instance the same pages in Netscape 6.2.3,
Mozilla 1.2.1.. Absolutely all story pages in Norway's third largest newspaper
are broken because of this. http://www.dagbladet.no

Are you quite sure this should be futured?

Comment 11

[R.K.Aa.]

might add that unlike in bug 188634, nothing here change if i go back/forth or
reload the page. The only reflow that affects the layout to set it right is if i
change font-zoom up/down OR down/up

Comment 12

[R.K.Aa.]

the 1.3a release doesn't have the bug either.

Comment 13

[Andrew Schultz]

FWIW, if I load the testcase in 1.2.1, it looks ok, but if I decrease the font,
the layout is bad, and if I increase it again, the layout remains bad, so it
appears that the unrelated changes in layout shifted the bug's existence (in the
testcase at least) to lower font sizes.

On the nationalgeographic page (with 1.2.1), I have to decrease the font twice
to hit the bad layout.  Increasing the font size once doesn't fix it.

Comment 14

[R.K.Aa.]

well well. Sometime veru recently - within the past 24 hours - this seems to
have been fixed. Must have been before 02/22/2003 08:56, possibly the fix for
bug 186593

Resolving as WFM.