Closed Bug 99691 Opened 23 years ago Closed 23 years ago

nsBoxToBlockAdaptor should not be creating a space manager

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla0.9.9

People

(Reporter: waterson, Assigned: waterson)

References

Details

(Keywords: perf)

Attachments

(2 files, 1 obsolete file)

I don't think that the nsBoxToBlockAdaptor should be creating a space manager. Instead, I think what we probably ought to do is make sure that blocks that are contained within box frames are marked with the NS_BLOCK_SPACE_MGR bit so that the block frame can create and own the space manager.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 90725
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Attached file testcase with float inside box (deleted) —
Presumably this testcase would break (probably crash) if there were no space manager.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Attached patch proposed fix (obsolete) (deleted) — Splinter Review
This ought to do the trick, although I'm not sure it's the cleanest way to do it. Is there a better place to be setting the NS_BLOCK_SPACE_MGR flag? Also, we wrap a fair number of non-block frames with the nsBoxToBlockAdaptor: on startup, I get... *** nsBoxToBlockAdaptor: wrapping non-block frame Canvas(html)(-1)@0x824db08 *** nsBoxToBlockAdaptor: wrapping non-block frame Placeholder(tooltip)(-1)@0x84ddb70 *** nsBoxToBlockAdaptor: wrapping non-block frame Placeholder(tooltip)(0)@0x850efec *** nsBoxToBlockAdaptor: wrapping non-block frame Placeholder(tooltip)(0)@0x85af3b8 *** nsBoxToBlockAdaptor: wrapping non-block frame FrameOuter(browser)(0)@0x85e8c10 *** nsBoxToBlockAdaptor: wrapping non-block frame Canvas(html)(-1)@0x860dc78 *** nsBoxToBlockAdaptor: wrapping non-block frame Placeholder(popup)(0)@0x865cdec *** nsBoxToBlockAdaptor: wrapping non-block frame LeafBox(outlinerbody)(0)@0x8679ae0 *** nsBoxToBlockAdaptor: wrapping non-block frame Canvas(html)(-1)@0x8758e14 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(0)@0x8616c98 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(2)@0x86171d4 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(0)@0x86167f8 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(2)@0x8616a64 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(4)@0x8617350 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(6)@0x8617550 *** nsBoxToBlockAdaptor: wrapping non-block frame Placeholder(tooltip)(-1)@0x861aeb8 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(0)@0x861af4c *** nsBoxToBlockAdaptor: wrapping non-block frame Text(2)@0x86165e8 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(4)@0x860dcb8 *** nsBoxToBlockAdaptor: wrapping non-block frame Text(6)@0x860deb8 *** nsBoxToBlockAdaptor: wrapping non-block frame FrameOuter(browser)(0)@0x8830324 *** nsBoxToBlockAdaptor: wrapping non-block frame Placeholder(tooltip)(-1)@0x87d37bc *** nsBoxToBlockAdaptor: wrapping non-block frame Canvas(html)(-1)@0x8765ba8 *** nsBoxToBlockAdaptor: wrapping non-block frame Canvas(html)(-1)@0x8859af0 *** nsBoxToBlockAdaptor: wrapping non-block frame Canvas(html)(-1)@0x88418b4 There aren't that many of these, so it's probably not too wasteful, but I was thrown off a bit. Was this really what evaughan expected?
How about at least removing the member variable? What about patching the frame construction code instead -- or is that hard?
Oops, I did remove the member variable but didn't include the header file when I created the patch. And I'll take another look at the frame construction code.
Keywords: patch
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Keywords: perf
Okay, I dug a little bit deeper. It turns out that some <xul:label> and <xul:description> elements are creating block frames by virtue of the fact that they've got a `display: block' in xul.css (the XUL label frame creation code is tortured, as jag can attest to after we dug through it last week). If we want these to be blocks, then we'll need some way of calling these frames out for the frame constructor so that it can create area frames with the NS_BLOCK_SPACE_MGR (and probably NS_BLOCK_MARGIN_ROOT) bit(s) set. I could create another CSS property (or another value for the CSS `display') that would cause this to happen. Or, I could simply force the XUL <label> and <description> to create area frames, and remove the style rule from xul.css. I'm inclined to do the latter, since I don't see any reason that people would want to change the display type for these elements. Once I fix this problem, it should be possible to remove the space manager code from box-to-block adapter completely. hyatt, jag, dbaron: do you have any thoughts?
(FWIW, I was able to verify that this approach will work. Specifically, I removed the space manager code for nsBoxToBlockAdaptor.cpp, and then added `overflow: scroll' to the rule for <label> and <description> in xul.css: this forces us to create an area frame with the NS_BLOCK_SPACE_MGR bit set.)
Keywords: patch
Attached patch proposed fix (deleted) — Splinter Review
Remove space-manager cruft from nsBoxToBlockAdaptor; hard-code <xul:description> and <xul:label> to use area frames.
Attachment #62166 - Attachment is obsolete: true
Keywords: review
Comment on attachment 66221 [details] [diff] [review] proposed fix r=dbaron, although I wonder whether you want NS_NewBlockFrame or NS_NewAreaFrame.
Attachment #66221 - Flags: review+
Comment on attachment 66221 [details] [diff] [review] proposed fix r=dbaron, although I wonder whether you want NS_NewBlockFrame or NS_NewAreaFrame.
Comment on attachment 66221 [details] [diff] [review] proposed fix sr=hyatt
Attachment #66221 - Flags: superreview+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
can this have caused bug 121860?
Blocks: 121860
Blocks: 122367
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: