725 bytes, text/html
936 bytes, text/html
228 bytes, text/html
755 bytes, patch
|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.
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
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
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.
Comment on attachment 52267 [details] [diff] [review] proposed patch email@example.com
Attachment #52267 - Flags: review+
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]
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+]
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: 18 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
You need to log in before you can comment on or make changes to this bug.