In xul, it seems to be that overflow: scroll/auto kicks in before the line wrapping (<description>, <html:div>) happens. If I remove the overflow: auto, it correctly occupies enough space to show all lines incl. wrapping. With overflow: auto, it gets only as much space as one line per <description> takes, and so essentially always gets a scrollbar when there's line-wrapping.

You can open the testcase in the browser here in bugzilla, but you need to make the browser window small to trigger the line wrapping. Alternatively, you can use it as main window of a XULRunner app. The testcase can also show another, even more strange bug: If you remove the "overflow:hidden" style rule from the last vbox, it stays the same, but the *first* vbox (overflow:auto) gets no scrollbar anymore.

Enn, any idea how hard/scary this bug would be to fix? Any chance of us getting a fix for this for 1.9.1?

Enn Deakin: ping?

Compare bug 513318

See bug 525225 for what problems this cases. There are screenshots, too.

dbaron: is this something you could take a look at?

I talked to roc a bit yesterday about driving this bug forward, and it doesn't look like the layout folks are likely to have the bandwidth for this soon. To wit (pasted with permission): roc: that looks like the "XUL layout and HTML layout interaction is fundamentally broken" bug [6:00pm] dmose: roc: ROFL [6:00pm] dmose: roc: does that break down into anything smaller that's actually resolvable? [6:02pm] roc: not easily [6:02pm] roc: the XUL layout code all needs to be rewritten [6:03pm] roc: for critical bugs we can patch on band-aids but that's time-consuming and fragile :-(

Yes, XUL and line wrapping simply don't seem to go well together. XUL seems to calculate both height and width at the same time. (That happens in 2 passes: first asking all elements how large they need to be minimally/ideally/maximally, then making a second pass to divide up the available space among the elements, and assigning each element its size. Yet, these passes calculate height and width at the same time.) For line wrapping, you first need to calculate the width (with the 2 passes described above), only then can you know how long a line can be and where to wrap. Then you wrap. Only then do you know how high your element needs to be. Then the 2 passes need to happen for the height. That's something very fundamental to layout, not easy to change. (If I'm wrong, please feel free to correct me, I'm not a layout hacker.)

I think behaviour of testcase attachment 377001 [details] has changed, compared to description in comment 0: I'm viewing testcase with FF 9.0.1 on WinXP, and I never see any scrollbars at all, even after resizing the browser window to be too narrow and very high. Wider content is just truncated/hidden at the right side. I understand from comment 0 that at least in certain circumstances, the testcase would display a scrollbar? Ben, or anybody, any conlusions to draw from that? Can you file STR, Actual Behaviour, and Expected behaviour? (In reply to Dan Mosedale (:dmose) from comment #7, dated 2010-02-10) > I talked to roc a bit yesterday about driving this bug forward, and it > doesn't look like the layout folks are likely to have the bandwidth for this > soon. Is "likely not soon" the Mozilla shorthand for "perhaps in 5 or 10 years time"? More than 2 years after this bug was filed, and almost 2 years after that statement, it seems this bug has moved way beyond "not soon"... So what's the way forward? Anybody from core layout team who should/could be cc'ed on this? Do they need more details to address the issue? I'm aware it may not be easy to fix, but I what I really miss is some sort of bug queue or priority list or time frame that makes the whole process more transparent and predictable.

> Is "likely not soon" the Mozilla shorthand for "perhaps in 5 or 10 years time"? Correct. Like in any other project. however, jcramner did move that bug forward recently, and I'm thankful for that. > So what's the way forward? Wait for jcramner to finish it. > I really miss is some sort of ... time frame This is open-source.

(In reply to Ben Bucksch (:BenB) from comment #10) > however, jcramner did move that bug forward recently, and I'm thankful for > that. ... Wait for jcramner to finish it. That's good news, and I am thankful for that, too. Does "that bug" refer to this bug, or another bug, or...? I don't see jcramner assigned or cc'ed on this bug, so I'm just wondering in what way this bug was moved forward? Ben, thank you for addressing the whining part of my comment. To move this bug forward, could you also reply to the more helpful part of my comment? Description in Comment 0 says (Actual behaviour, I suppose): > In xul, it seems to be that overflow: scroll/auto kicks in before the line > wrapping (<description>, <html:div>) happens. However, with current testcase attachment 377001 [details], I don't see any scrollbars at any time (wide or narrow window). So afasict the description no longer applies. Therefore, imo a new description with STR, Actual Behaviour, and Expected Behaviour (as kindly requested in comment 9) would still be helpful to move this bug forward. Or Screenshots. Bugs with unclear descriptions may not get the intention they deserve. OT: > > I really miss is some sort of ... time frame > This is open-source. I'm aware of "no obligations" for free OSS, but I'm sure Mozilla-paid developers must have some way of prioritizing their work, and they won't just randomly pick the bugs they work on. I'll be glad for any pointers to any sort of document that sheds some light on such processes, or who currently works on what (via PM pls, let's not hijack Ben's bug with this).

Thomas, I was referring to bug 80713. > I'm viewing testcase with FF 9.0.1 on WinXP I can't, because remote XUL is disabled. To the subject of this bug: I've seen similar problems in other projects, and they were fixed by adding an appropriate flex="1". The <description> would *not* wrap, if there's not enough horizontal space, but enough vertical space, but it *would* wrap, if it had a flex, and all its parents up to the window top. I/We'll have to test whether that is the case here, too.

(In reply to Ben Bucksch (:BenB) from comment #12) > > I'm viewing testcase with FF 9.0.1 on WinXP > I can't, because remote XUL is disabled. Fortunately, the workaround for *that* problem takes less than a minute :) 1) Install https://addons.mozilla.org/de/firefox/addon/remote-xul-manager 2) Then: add "bugzilla.mozilla.org" to the list of exceptions to allow remote xul (Tools > Web developers > Manage remote XUL)