images don't line up at nationalgeographic.com

RESOLVED WORKSFORME

Status

()

Core
Layout: Tables
P2
normal
RESOLVED WORKSFORME
16 years ago
16 years ago

People

(Reporter: R.K.Aa., Unassigned)

Tracking

({regression, testcase})

Trunk
Future
x86
Linux
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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

16 years ago
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%; }
(Reporter)

Comment 2

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

Comment 3

16 years ago
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

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

Comment 5

16 years ago
Marking invalid - Temp seek review
(Reporter)

Comment 6

16 years ago
huh?
(Reporter)

Comment 7

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

Comment 8

16 years ago
Created attachment 111377 [details]
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

16 years ago
this is similar in spirit to bug 188634

==> tables
Assignee: other → table
Component: Layout → Layout: Tables
Keywords: testcase
QA Contact: ian → amar

Updated

16 years ago
Priority: -- → P2
Target Milestone: --- → Future
(Reporter)

Comment 10

16 years ago
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?
Keywords: regression
(Reporter)

Comment 11

16 years ago
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
(Reporter)

Comment 12

16 years ago
the 1.3a release doesn't have the bug either.

Comment 13

16 years ago
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.
(Reporter)

Comment 14

16 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.