resizing the browser window distorts the layout

VERIFIED FIXED in mozilla0.9.5

Status

()

P2
major
VERIFIED FIXED
17 years ago
15 years ago

People

(Reporter: madhur, Assigned: alexsavulov)

Tracking

({testcase, top100, topembed})

Trunk
mozilla0.9.5
testcase, top100, topembed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: bugscape 10403, URL)

Attachments

(6 attachments)

(Reporter)

Description

17 years ago
buildid: 20010724 window2000

1. go to http://www.hotmail.com
2. resize the window

actual:
you will notice that the layout of the page gets distorted. The right hand side 
table overlaps the left hand side table.
Please view the screen shot I have attached.

NOTE: This bug can be seen in neither Netscape 4.77 nor Netscape 6.01.
But I see this layout distortion problem right from Netscape 6.1 Preview 
release onwards.
This is will directly affect the user experience. Therefore should be looked 
into with the hightest urgency.
(Reporter)

Comment 1

17 years ago
Created attachment 43412 [details]
screen shot

Comment 2

17 years ago
Created attachment 43476 [details]
Testcase

Updated

17 years ago
Component: Layout → HTMLTables
Keywords: testcase, top100
QA Contact: petersen → amar

Comment 3

17 years ago
Adding kw testcase,top100 and -> HTMLTables

Comment 4

17 years ago
Seems to be a NOWRAP issue again.

Comment 5

17 years ago
*** Bug 92185 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
Over to attinasi while karnaze is out.
Assignee: karnaze → attinasi
(Reporter)

Comment 7

17 years ago
adding keyword 'topembed' - corresponding bugscape bug 
http://bugscape.mcom.com/show_bug.cgi?id=7897.

I will be attaching another reduced testcase also.
Keywords: topembed
(Reporter)

Comment 8

17 years ago
Created attachment 48239 [details]
reduced testcase
WFM, recent linux CVS build.

Comment 10

17 years ago
The second testcase works fine, but the first testcase and the actual URL still
do not work. It looks like a cell with a specified width and NOWRAP is allowed
to shrink below the specified width, and is allowed to wrap as well (?). Same
problem on Linux ans Win2K

Looks like a table bug to me... cc'in Alex so he can check it out.
OS: Windows 2000 → All
Priority: -- → P2
Hardware: PC → All
Target Milestone: --- → mozilla0.9.5
(Assignee)

Comment 11

17 years ago
ressigning to me
Assignee: attinasi → alexsavulov
(Assignee)

Comment 12

17 years ago
when we rebalance the table after the initial reflow, we have to keep the fixed
width on a width cell even though the available width falls below the fixed
width of the cell.
that means that in quirks mode we have to check for nowrap on a fixed width cell
and change the way rebalancing column widths works (honour the width request) to
emulate the IE behaviour. (BTW: Opera does the same we do at the moment)
(Assignee)

Comment 13

17 years ago
Created attachment 49291 [details] [diff] [review]
proposed fix for hotmail.com (read following comment)
(Assignee)

Comment 14

17 years ago
the proposed patch [attachment 49291 [details] [diff] [review]] fixes the URL hotmail.com.
 
in this patch in the case of a fixed width cell, I check for quirks mode and
then  I check the HTML content for the nowrap attribute. I cannot check the cell
frame be cause we don't map nowrap if there is a fixed width on the cell. one
may propose to map the nowrap so we don't have to check the content, but this
would result in displaying the text in a sigle line and this is not what the
effect of the pach is intended to be. IE/NAV use the nowrap attribute as a hint
for not resizing (shrinking) the cell bellow the fixed width size. 

the patch is not perfect be cause if i add a procentage cell on the same row, 

  <tr>
   <td width="312" nowrap>...</td>
   <td width="50%"></td>
  </tr>

this will cause the WIDTH="..." of the fixed width cell to be ignored. IE/NAV
keep the width of the fixed width cell (that also has nowrap on it) even then
when the adjacent cell has a procentage width on it while resizing.

anyway, with the proposed patch mozilla performs better than what we did before
in quirks mode and repairs a top100/topembed issue

need r/sr=
Status: NEW → ASSIGNED
(Assignee)

Comment 15

17 years ago
Created attachment 49958 [details] [diff] [review]
moved patch from BasicTableLayoutStrategy to nsTableCellFrame
(Assignee)

Comment 16

17 years ago
modified the first patch. moved to nsTableCellFrame as proposed by Chris Karnaze.

the new patch is testing for the following conditions to modify the min width
(max element size) of a cell:

- the cell has to have either width="[number]" or width: [number]px | cm | em...
- the cell does not have white-space: nowrap | pre
- the cell has nowrap in the tag (not mapped but still visible in the content)

then the max element size is set to the value of the fixed width.

need sr=/r=

Comment 17

17 years ago
Comment on attachment 49958 [details] [diff] [review]
moved patch from BasicTableLayoutStrategy to nsTableCellFrame

You do not need to call get() on cellContent, just use the operator -> like cellContent->GetAttr(...)

check the result via NS_SUCCEEDED(result) instead of comparing to NS_OK.

Those two nits, and a review from karnaze and sr=attinasi
Attachment #49958 - Flags: superreview+

Comment 18

17 years ago
r=karnaze, assumming it passes the table regression tests.

Comment 19

17 years ago
Actually, check the documentation for GetAttr, it says:

 * <LI>If the attribute is not set and has no default value, return
 * NS_CONTENT_ATTR_NOT_THERE.
 * <LI>If the attribute exists, but has no value, return
 * NS_CONTENT_ATTR_NO_VALUE.
 * <LI>If the attribute has a non-empty value, set ret to
 * be the value, and return NS_CONTENT_ATTR_HAS_VALUE (== NS_OK).

So for NOWRAP, I think you need to check for NS_CONTENT_ATTR_NO_VALUE and for
NS_CONTENT_ATTR_HAS_VALUE. Please disregard what I said before about checking
for NS_SUCCESS, it is incorrect for this call.
(Assignee)

Comment 20

17 years ago
Created attachment 50006 [details] [diff] [review]
final patch with the modifications requested by Marc Attinasi
(Assignee)

Updated

17 years ago
Attachment #50006 - Flags: superreview+
Attachment #50006 - Flags: review+
(Assignee)

Comment 21

17 years ago
we (Marc and I) agreed subsequently that checking 

NS_CONTENT_ATTR_NOT_THERE != result

is sufficient in this case
(Assignee)

Comment 22

17 years ago
*** Bug 93318 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 23

17 years ago
*** Bug 95936 has been marked as a duplicate of this bug. ***

Comment 24

17 years ago
The patch has been checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
*** Bug 89427 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 26

17 years ago
I can still see the bug on win2000 -- buildID : 2001-10-16-05-0.9.4 (branch 
build)
(Assignee)

Comment 27

17 years ago
this needs PDT+ approval to be checked into the branch (work in progress)

Comment 28

17 years ago
was this present in Netscape 6.1?

Comment 29

17 years ago
was this present in Netscape 6.1?
(Assignee)

Comment 30

17 years ago
yes, the bug is present in Netscape 6.1
amar: can you verify that this bug was fixed on the trunk? Thanks
Keywords: edt0.9.4
Whiteboard: bugscape 10403

Comment 32

17 years ago
 The checkins fixed the problem. verified on build ID : 2001103103- Trunk
Platforms: WIN2K and redhat linux 7.1
Status: RESOLVED → VERIFIED

Comment 33

17 years ago
please land on the 0.9.4 branch and mark it w/ the "fixed0.9.4" keyword once
it's landed there.
Keywords: edt0.9.4 → edt0.9.4+
(Assignee)

Comment 34

17 years ago
fixed on branch 0.9.4 (+ fix for bug 101883 that had to go with this fix)

Updated

17 years ago
Keywords: fixed0.9.4

Comment 35

17 years ago
 Verified.. Fixed on branch 0.9.4ec build Id: 2002011320. Adding "verified0.9.4" 
keyword
Keywords: verified0.9.4

Updated

15 years ago
Keywords: fixed0.9.4
You need to log in before you can comment on or make changes to this bug.