Closed Bug 101936 Opened 23 years ago Closed 23 years ago

[FIX]WRMB: Cell content shifts outside of cell boundary

Categories

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

All
Windows 98
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.6

People

(Reporter: rubydoo123, Assigned: rods)

References

Details

(Keywords: testcase, topembed, Whiteboard: [Fix in hand][bugscape: 7750][PDT+] [Fix in 094 branch])

Attachments

(4 files)

This issue comes from bugscape bug 7750

Ignore the bad html! The attached test case is a reduced example from the 
referenced website.

Look at the attached test case, I think I have found the problem with the Go 
button. Try these steps:

1. open the test case
2. select the second option in the drop-down: notice the width of the select box 
 increases, and the Go button shifts to the right
3. select the first option in the drop-down: notice the width of the select box 
continues to grow.
4. select the second option again
5. Look at the Go button, notice that part of the Go button is beyond the cell 
boundary. Select the part of the Go button the is out of the cell boundary.

Result: selecting the portion of the button that is outside the boundary is not 
functional.
In the 1st attachment, during the initial reflow the cell block containing the 
select reports a desired and max elem width = 2415. 

          Cell 02593FE8 r=0 a=UC,UC c=UC,UC cnt=10
           Block 02594044 r=0 a=UC,UC c=UC,UC cnt=11
           Block 02594044 d=2415,330 me=2415
          Cell 02593FE8 d=2475,390 me=2475

During the incremental reflow which happens as a result of operating the select, 
it requests a larger desired size than previously and larger than the avail 
width. 

          Cell 02593FE8 r=1 a=2475,UC c=2415,UC cnt=44
           Block 02594044 r=1 a=2415,UC c=2415,UC cnt=45
           Block 02594044 d=2475,330 me=2415 m=2415
          Cell 02593FE8 d=2535,390 me=2475 m=2475

->waterson, cc attinasi, alexsavulov
Assignee: karnaze → waterson
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Keywords: testcase
Okay, rods, I give up. The combobox code is just way beyond my powers of
comprehension. It looks to me like what's happening is that the computed width
which you're passing in to flow the anonymous block frame that holds the combo
box's text (Block(-1)) increases by some multiple of the border each time.
Perhaps the block needs to be set to shrinkwrap.
Assignee: waterson → rods
Status: ASSIGNED → NEW
Keywords: topembed
Attached patch proposed patchSplinter Review
The fix makes sense. If we are hitting this part of the code with resize reflow 
it means we have already gotten the 'initial' size of the dropdown and and added 
the border and padding to it. 

So when the resize reflow comes thru and it gets to this point because the 
height is set via style so it fails some tests up above that would allow it to 
bail earlier.  So we remove the border & padding and let it re-calc everything.
Status: NEW → ASSIGNED
Summary: WRMB: Cell content shifts outside of cell boundary → [FIX]WRMB: Cell content shifts outside of cell boundary
Whiteboard: Fix in hand
I tested a fair number of the top 100 and put a test case together with various 
different tests in and out of tables and the patch doesn't appear to affect 
anything else.
who's a good sr for this?
Comment on attachment 52267 [details] [diff] [review]
proposed patch

sr=attinasi
Attachment #52267 - Flags: superreview+
is this something we are gonna want on the 094 branch?
let's talk about this one in the noon PDT meeting.
Whiteboard: Fix in hand → [Fix in hand] [PDT]
Marking nsbranch+.
Keywords: nsbranch+
pls check this into the 094 branch - PDT+
Whiteboard: [Fix in hand] [PDT] → [Fix in hand] [PDT+]
adding bugscape ref
Whiteboard: [Fix in hand] [PDT+] → [Fix in hand][bugscape: 7750][PDT+]
Blocks: 64833
checked into the branch
can we pls verify the fix on 094?
Whiteboard: [Fix in hand][bugscape: 7750][PDT+] → [Fix in hand][bugscape: 7750][PDT+] [Fix in 094 branch]
checked into tip
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
 Verified.. when you select second option which is a long string the "GO" button 
behaves good and stays inside the cell in both the testcases..
Verified on Build ID : 2001-10-15-05-0.9.4
Platform : win2K and win98
Marking verified
Status: RESOLVED → VERIFIED
Keywords: vtrunk
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: