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)
Core
Layout
Tracking
()
RESOLVED
DUPLICATE
of bug 129350
mozilla1.0
People
(Reporter: attinasi, Assigned: attinasi_layout)
References
Details
(Keywords: testcase)
Attachments
(1 file)
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.
Reporter | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
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...
Reporter | ||
Comment 3•23 years ago
|
||
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?
Reporter | ||
Comment 4•23 years ago
|
||
not gonna make it --> 098
Priority: -- → P3
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Comment 5•23 years ago
|
||
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
Reporter | ||
Comment 6•23 years ago
|
||
Bulk push to next milestone
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Reporter | ||
Comment 7•23 years ago
|
||
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
Updated•23 years ago
|
Summary: [RR]Changing 'visibility' property on a 'special inline-block' element fails → [RR]{ib}Changing 'visibility' property on a 'special inline-block' element fails
Comment 10•23 years ago
|
||
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>
Reporter | ||
Comment 11•23 years ago
|
||
Clearing nsbeta1+ for reconsideration - there are a number of more critical bugs
on my plate now, and this one is not causing crashes...
Comment 12•23 years ago
|
||
nsbeta1- based on comment #11
Reporter | ||
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
*** 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.
Description
•