74149 - Changing tr tag's CSS style with JavaScript causes rendering problems and crashes

Status: VERIFIED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Sarwat Khan]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2001032319

In the page above it uses JavaScript to show and hide table rows by changing 
the <object>.style.display attribute to "none" or "inline" (or "block"). The 
code executes correctly in IE, but in Mozilla it just gets weird.

Mozilla can correctly hide the rows, but it has a lot of trouble re-displaying 
them.

I have a web page (the one that I was actually working on) that hides a bunch 
of rows when the page loads. If the user clicks an image (onclick handler) it 
sets the display of the tr tags to "block". 

With Mozilla, setting the display of the tr tags to block does not produce any 
visual result (although it seems that internally the style is now block). The 
rows are still hidden. Setting it to 'none' again causes mozilla to get stuck 
into an infinite loop, and I have to kill it.

If I use 'inline' instead of 'block', it does show and hide the rows. However, 
it renders incorrectly. Every time it re-displays the row, it draws the row and 
seems to insert a 'br' or something after the row. When I hide the row again, 
the row gets hidden but the break is still there. Showing the row again causes 
another 'br' to get inserted. The rendered display looks much uglier than that, 
though.

Reproducible: Always
Steps to Reproduce:
To test the 'inline' problem on the sample page at 
sarwat.net/mozilla/testmozjs.html
1. Click 'hide this row' in the "inline" section of the page.
2. Click "show above row."
3. Go to step one.

To test the block problem, reload then
1. Click "hide this row" in the block section of the page
2. Click "show above row."
--> nothing happens.
3. To test the infinite loop, click "hide while hidden." You'll see the Windows 
task manager showing Moz eating up the CPU.

Actual Results:  In the first test case (inline), garbage rendering resulted.

In the second case, mozilla did not correctly redisplay the row, and then it 
crashed when told to hide a hidden row.

Expected Results:  Mozilla should cleanly hide and show the rows using either 
method.

The page includes the necessary javascript to debug. I suggest downloading the 
page and tweaking it. And keeping it, I may not keep that thing up forever.

Comment 1

[Boris Zbarsky [:bzbarsky]]

You should be setting display to "table-row" if you want Mozilla to display the
rows correctly as table rows... See
http://www.w3.org/TR/REC-CSS2/visuren.html#display-prop

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comments from reporter:

Actually, I'm still getting some rendering errors, but it's much much better.

http://sarwat.net/mozilla/mozrenderprob.jpg

If you think that the problem isn't going to be investigated further, I can
try to isolate this code and submit another bug report. Basically, the rest
of the table needs to be redrawn when a row is inserted, and it doesn't
always do that properly.

In the picture you'll see that the row for 'child of child of two' wasn't
fully redrawn, it's supposed to have a solid white background (the grey
background is there from the row that was in that place before).

You can see a similar problem for the "child of two!!" row, and row 'three'
is not supposed to be repeated twice. It renders fine if I cause a refresh
by resizing the window.

BTW, it turns out that IE demands 'block' and mozilla demands 'table-row'.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Sarwat:  A minimal testcase for the redrawing bug would be great.  You may also
want to file a different bug on that, after searching for duplicates.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The redraw problems were covered in bug 74208.  I cannot reproduce the crash
with the original testcase and the 2001-04-30-08 linux Mozilla build.  Marking
worksforme.

Comment 5

[Boris Zbarsky [:bzbarsky]]

er... actually resolving.

Comment 6

[Amarendra Hanumanula]

 Verified that this a dupe of Bug # 74208 which is resolved... Marking as verified