156206 - {ib}Unable to set "display" style prop. from JS code

Status: RESOLVED DUPLICATE of bug 171830

(Core :: Layout, defect, P4)

Description

[ptashek]

I have code like this in HTML:

<input TYPE="BUTTON" CLASS="EDIT" VALUE="SHOW FILTER DIALOG" 
OnClick="ToggleFilter('dfilter',1);"><form NAME="dfilter" ACTION="$PHP_SELF" 
STYLE="display: none;">
<table BORDER="0">
.
.[some content]
.
<tr><td><input TYPE="BUTTON" CLASS="EDIT" VALUE="HIDE FILTER DIALOG" 
OnClick="ToggleFilter('dfilter',0);"></td></tr>
</table></form>

and the ToggleFilter() function in an external JS file:

function ToggleFilter(filterForm,isOn) {
	if (isOn == 1) {
		document.forms[filterForm].style.display = "inline";
	} else {
		document.forms[filterForm].style.display = "none";
	}
}

The above code should display my form when isOn == 1 and hide it in any other 
case. While the showing works OK, there is a problem with hiding the form back. 
JSEngine in Mozilla doesn't do anything although the "else" part is fired 
(tested with some other code). JS Console reports no errors/warnings/whatever

In MS Internet Explorer 5.x/6 everything works smooth.

Tested mozilla builds: 0.9.6, 0.9.8, 1.0 RC1, 1.0 final, 1.1 alpha (build 
2002070204) and 1.1 alpha (build: 2002070708)

Comment 1

[Boris Zbarsky [:bzbarsky]]

If you use "block" instead of "inline" to show, does it work?

Comment 2

[Lasse Marøen]

Re: comment 1 - Yes, I tested it with block, and it works.

Comment 3

[Marcus Campbell]

Also seems to work if you remove the table code.

Comment 4

[Boris Zbarsky [:bzbarsky]]

To layout.  I'll investigate in more detail tomorrow....

Comment 5

[ptashek]

Yes, it works if changed from "inline" to "block".
However, it should work with both.

Comment 6

[Marcus Campbell]

Should it? If you switch FORM to "display: inline" then you're saying an inline
element (FORM) should contain a block element (TABLE). That can't be right.

-> INVALID

Comment 7

[Boris Zbarsky [:bzbarsky]]

Reopening.  There's nothing wrong with having a block inside an inline (except
in the HTML4 specification, but those are different blocks and inlines).

We should be handling this case; I have not yet figured out what breaks here...

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimal testcase

OK, this is quite confusing....  I've traced the code, and even calling
RecreateDocElementHierarchy (which succeeds and all that) does not make the
second <input> disappear.....

Could this have something to do with the framestate restoration forms do, by
any chance?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: same without form controls. :(

Comment 10

[Lasse Marøen]

Attachment: This one works..

I don't know if this is relevant, but this is a simple script I use on an
intranet which toggles the display of a span between none and inline. Works
fine in Moz.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Lasse, your testcase has no blocks inside the <span>.  Hence it works.

Comment 12

[Marcus Campbell]

*** Bug 163451 has been marked as a duplicate of this bug. ***

Comment 13

[Marcus Campbell]

*** Bug 174704 has been marked as a duplicate of this bug. ***

Comment 14

[Tal Cohen]

Attachment: Small testcase

I've encountered this bug while developing a product for IBM which generates
HTML output. I've attached a small testcase. The 'click to flip' link works
only once (in IE it works repeatedly). Note that everything works fine if the
table is removed.

Since I need to hide/reveal the entire table, the workaround I've found is
marking the <table> itself as the element to hide/reveal, without an enclosing
<span>. It seems to work with Mozilla 1.1. Has anyone tried this before and
encountered any problems?

I realize this workaround can probably be used in general when you have to play
around with whole blocks (just replace the <span> with a single-cell <table>),
but the bug itself seems painful and must be solved.

Comment 15

[Boris Zbarsky [:bzbarsky]]

tal, you're not seeing this bug.  You're seeing bug 146409 or something it
blocks (as in, my build with the patch for that bug works fine on your testcase
but fails the testcase in comment 9).

In general, testing this bug without a build with that patch or equivalent is
pointless, since the almost all occurrences of these symptoms are fixed by that
patch...

Comment 16

[Boris Zbarsky [:bzbarsky]]

Looks fixed by bug 171830

*** This bug has been marked as a duplicate of 171830 ***