Closed Bug 449362 Opened 14 years ago Closed 14 years ago

[FIX]Table border is rendered incorrectly when the table cell size changes due to javascript.

Categories

(Core :: Layout: Tables, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.1a2

People

(Reporter: marklassau, Assigned: bzbarsky)

References

()

Details

(Keywords: regression, testcase, verified1.9.0.2)

Attachments

(5 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

The example page has javascript such that when you click on the bottom-right cell of the table, then bottom row must get higher.
when this happens, the bottom border on the left cell is left around after the new border is drawn further down.

If the page loses focus, then it is re-rendered correctly.

Reproducible: Always

Steps to Reproduce:
1.Load the example page.
2.Click on the bottom-right cell of the table.
3.The bottom row will need to expand to fit the new text.
4.Note the border in the bottom-left cell.
Actual Results:  
The bottom-left cell of the table still has a line where the old border used to be, as well as the new border.

Expected Results:  
The old border should disappear and be replaced by the new border.

This works on Firefox 2 and other browsers, the defect is seen on Firefox 3.
The example given is broken on Ubuntu 64 bit, but seems to work on Windows and Mac.
However, this example was distilled down from a more complicated set of HTML, CSS, and javascript where the problem was observed on both Linux and Windows, but not Mac.
Attached file Example Page (obsolete) —
Uploaded a screenshot that shows the observed behaviour.
Note that the act of taking a screenshot got the page to re-render itself correctly, so I doctored the image to show what it looks like before the re-render.
Component: General → Layout: Tables
Keywords: testcase
Product: Firefox → Core
QA Contact: general → layout.tables
I was not able to reproduce the problem on Windows XP, so it seems to be Linux-only.
The behaviour was originally observed on both Ubuntu Linux and Windows XP in a web app. 
I used my Linux box to reduce the page down to the simplest possible static html that would reproduce the issue. Unfortunately this page is only broken for Linux.

So the problem is NOT Linux-only. It is just that the example page only reproduces the problem on Linux.
Component: Layout: Tables → General
Product: Core → Firefox
Version: unspecified → 3.0 Branch
This updated example displays the buggy behaviour on Ubuntu Linux, Win XP, and Mac OSX.
Attachment #332506 - Attachment is obsolete: true
FYI, the reason the original example was OS-dependent seems to be that the text was changing in the second column, and so that column could change widths, depending on the font of the text.

Also the URL listed above has been updated to the OS-independant version.
(In reply to comment #5)
> Created an attachment (id=332655) [details]

Ok, thanks. Now I can indeed reproduce it on Windows. 

Works: 2008020613
Fails: 2008020614

Regression window is:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2008-02-06+12%3A00&maxdate=2008-02-06+15%3A00
Probably caused by Bug 414298.

Blocks: 414298
Status: UNCONFIRMED → NEW
Component: General → Layout: Tables
Ever confirmed: true
Keywords: regression
OS: Linux → All
Product: Firefox → Core
Hardware: Macintosh → All
Version: 3.0 Branch → Trunk
Flags: blocking1.9.1?
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #334517 - Flags: superreview?(roc)
Attachment #334517 - Flags: review?(roc)
Summary: Table border is rendered incorrectly when the table cell size changes due to javascript. → [FIX]Table border is rendered incorrectly when the table cell size changes due to javascript.
Attachment #334517 - Flags: superreview?(roc)
Attachment #334517 - Flags: superreview+
Attachment #334517 - Flags: review?(roc)
Attachment #334517 - Flags: review+
Pushed as 17140:7e87332a44d4.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
Comment on attachment 334517 [details] [diff] [review]
This fixes things

We should probably fix this on the branch too...
Attachment #334517 - Flags: approval1.9.0.3?
Attachment #334517 - Flags: approval1.9.0.2?
Need to add a test once we have a way to test invalidation.
Depends on: 451332
Flags: blocking1.9.1? → in-testsuite?
Boris, I'd like to let this bake a couple of days and approve it for landing (in 1.9.0.2) on Monday. Will you have time to land it then?
Flags: wanted1.9.0.x+
Yeah, that should be fine.
Comment on attachment 334517 [details] [diff] [review]
This fixes things

Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #334517 - Flags: approval1.9.0.3?
Attachment #334517 - Flags: approval1.9.0.2?
Attachment #334517 - Flags: approval1.9.0.2+
Fixed on branch.
Keywords: fixed1.9.0.2
Verified for 3.02 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2) Gecko/2008090212 Firefox/3.0.2.
Pushed those tests as http://hg.mozilla.org/mozilla-central/rev/80abbea018b2

Sorry for the lag on that, and thanks for the tests!
Flags: in-testsuite? → in-testsuite+
Hmm.  That test actually makes no sense, and will fail randomly (and just did, in one of my try server runs).

I'll try to fix it.
You need to log in before you can comment on or make changes to this bug.