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)
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)
725 bytes,
text/html
|
Details | |
936 bytes,
text/html
|
Details | |
228 bytes,
text/html
|
Details | |
755 bytes,
patch
|
kmcclusk
:
review+
attinasi
:
superreview+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
Comment 3•23 years ago
|
||
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
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.5
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 4•23 years ago
|
||
Comment 5•23 years ago
|
||
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 | ||
Comment 6•23 years ago
|
||
Assignee | ||
Comment 7•23 years ago
|
||
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
Assignee | ||
Comment 8•23 years ago
|
||
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.
Comment 9•23 years ago
|
||
Comment on attachment 52267 [details] [diff] [review] proposed patch r=kmcclusk@netscape.com
Attachment #52267 -
Flags: review+
Comment 10•23 years ago
|
||
who's a good sr for this?
Comment 11•23 years ago
|
||
Comment on attachment 52267 [details] [diff] [review] proposed patch sr=attinasi
Attachment #52267 -
Flags: superreview+
Comment 12•23 years ago
|
||
is this something we are gonna want on the 094 branch?
Comment 13•23 years ago
|
||
let's talk about this one in the noon PDT meeting.
Whiteboard: Fix in hand → [Fix in hand] [PDT]
Comment 15•23 years ago
|
||
pls check this into the 094 branch - PDT+
Whiteboard: [Fix in hand] [PDT] → [Fix in hand] [PDT+]
Reporter | ||
Comment 16•23 years ago
|
||
adding bugscape ref
Whiteboard: [Fix in hand] [PDT+] → [Fix in hand][bugscape: 7750][PDT+]
Assignee | ||
Comment 17•23 years ago
|
||
checked into the branch
Comment 18•23 years ago
|
||
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]
Assignee | ||
Comment 19•23 years ago
|
||
checked into tip
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 20•23 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•