Closed Bug 111238 Opened 23 years ago Closed 23 years ago

[RR]{ib}Changing 'visibility' property on a 'special inline-block' element fails

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 129350
Milestone:
mozilla1.0

People

(Reporter: attinasi, Assigned: attinasi_layout)

References

Details

(Keywords: testcase)

Attachments

(1 file)

testcase that toggles the visibility property on a special inline-containing-block element: fails
857 bytes, text/html
Details 
If there is an inline element that contains a block, as in:

<span id="foo">
 <div> Some Text </div>
</span>

then changes to the visibility property are not shown. Script like this, for
example:

function disappeartext(){
 var mm=document.getElementById("foo");
 mm.style.visibility='hidden';
}

will fail to hide the text

This is a spin-off from bug 56894, which reported that visibility and display
were causing problem, but the issues are seperate, hence this bug.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Even forcing a reframe does not make the visibility property work. Debugging, I
find that the block inside of the inline is NOT getting the visibility property
propagated into its context (in other words, the visibility property is wrong,
so it does not show or hide). The trick is figuring out why it works when the
visibility is set in the markup, but not from the DOM. I have some ideas to try:

1) clear the style data for the primary frame and, if it is a special
inline-block frame, its special sibling. Maybe the special sibling is not
getting its style reresolved correctly.
2) ensure that we are reresolving style on the special inline-block sibling: it
may be that we are not, but visibility is not inherited so I am not sure what
the ruleNode is doing with visibility in a ReResolve when only the parent has
changed.
3) beg for help from Hyatt :) I think that I at least need to understand how the
visibility property is handled in the ruleTree...
Some more data: looking at the style contexts for the frames in question before
and after the DOM modification of the visibility I see the problem (or part of
it anyway). After the visibility is changed on the outer SPAN, it is getting a
new style context, however the SC for the inner block is left intact, and is
still parented to the original SC of the outer SPAN, which is still left in the
style-tree!

So, I'm not sure why the original SC for the outer SPAN is being left in the
tree, it is not referenced by any frames, and I'm also not sure why the outer
SPAN needs to get a new style context.
Here is the arrangement that I am referring to above:

<span id="vis">
 <div>text</div>
</span>
It looks like this could be a big problem, especially the part about the SC
being left around and acting as the parent - could lead to dangling style
contexts maybe?

not gonna make it --> 098
Priority: -- → P3
Target Milestone: mozilla0.9.7 → mozilla0.9.8
This might be the underlying cause of a bunch of other bugs in
ReResolveStyleContext ([RR]): bug 119585, and perhaps the others as well.
Summary: Changing 'visibility' property on a 'special inline-block' element fails → [RR]Changing 'visibility' property on a 'special inline-block' element fails
Bulk push to next milestone
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Moving to 1.0 but increasing prioority since it is likely related to many other
problems, as David pointed out.
Priority: P3 → P1
Target Milestone: mozilla0.9.9 → mozilla1.0
Marking nsbeta1+
Keywords: nsbeta1+
Keywords: testcase
Summary: [RR]Changing 'visibility' property on a 'special inline-block' element fails → [RR]{ib}Changing 'visibility' property on a 'special inline-block' element fails
lowering priority to P2 since not a crasher...
Priority: P1 → P2
Another demo page to illustrate this 
bug under slightly different circumstances.  

<html>
<script>
<!--
  function toggle() {
    outer=document.getElementById("outerdiv");
    if (outer.style.display=="none") {
      outer.style.display="inline";
    } else {
      outer.style.display="none";
    }
  }
-->
</script>
<body>
<input type="button" onclick="toggle()" value="toggle">
<br />
<div id="outerdiv" style="display:none">
  <div style="display:block">
  This block div within the invisible <b>inline</b> div <br />
  will not disappear anymore after the toggle. It correctly <br />
  disappears though, if the enclosing block is a <b>block</b> <br />
  div.
  </div>
</div>
</body>
</html>
Clearing nsbeta1+ for reconsideration - there are a number of more critical bugs
on my plate now, and this one is not causing crashes...
Keywords: nsbeta1+ → nsbeta1
nsbeta1- based on comment #11
Keywords: nsbeta1 → nsbeta1-
I have a fix for bug 129350 that fixes this too.  Basically, we were not
handling special inline blocks situations in ReResolveStyle.  The patch is not
optimal, and just like every other situation with blocks in inlines, we indicate
that we must the reframe containing block.
Depends on: 129350

*** This bug has been marked as a duplicate of 129350 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: