Apprunner: Layout is clamped to a fixed height and doesn't respect vertical resizing. Width is Ok. kipp says: I have fixes sitting in my tree that make the box model handling for block elements much *much* better. Having said that, I have't yet looked at the xul source for the top level apprunner chrome so I don't know if my fix will apply there. I'm starting to think that they need to use a table to get what they want.

I did some more digging and I was mistaken. I'm going to start an email exchange with steve clark and chris karnaze and troy and see what we can come up with that will work easily. Otherwise, the only vanilla html alternative is framesets :-(

But we still have the bug. Reopening, assigning to trudelle.

I'm not quite sure what you mean by this bug, but I think I'm seeing something similar on Windows 95 (you probably know this, but the bug is marked Linux and all the discussion has been about Linux). If I start apprunner, the window is a certain size, and whatever I do to the window, the status bar stays the same distance from the top of the page being displayed. If I shrink the window, I get a scrollbar so I can see the status bar, and if I enlarge the window, I get the status bar somewhere in the middle of the page with white space below it.

This is a blocker for the dogfood milestone. reopening and reassigning to rickg for triage.

Ramiro -- this is a pretty high priority issue. Can you get with Kipp/Troy (others?) to help resolve this? Thanks - Rick

This bug has nothing to do with linux so I took that out of the title. It is really a request for enhancement because the only way to achieve the desired UI using HTML is with framesets. Since that is not considered acceptable, something needs to be done about it. I did start an email discussion, but it didn't get anywhere :-( Somebody in peter trudelle's group needs to pester the layout group, in particular rickg/karnaze, about getting a feature done that supports them. I'll be glad to sit in and help design a solution if necessary. Alternatively, just as the toolbar and progress meter, and tree code are custom frames, so can the outer container for the application be a custom frame...

This bug has nothing to do with linux so I took that out of the title. It is really a request for enhancement because the only way to achieve the desired UI using HTML is with framesets. Since that is not considered acceptable, something needs to be done about it. I did start an email discussion, but it didn't get anywhere :-( Somebody in peter trudelle's group needs to pester the layout group, in particular rickg/karnaze, about getting a feature done that supports them. I'll be glad to sit in and help design a solution if necessary. Alternatively, just as the toolbar and progress meter, and tree code are custom frames, so can the outer container for the application be a custom frame...

clearing all Linux-ness and reassigning to rickg again. Rick, this bug keeps bouncing back to me, which I don't think is your intent.

Ah, this is indeed happening on Windows as well. A workaround for M3 would be to increase the initial vertical layout size, not pretty, doesn't fix the problem, but it would let us focus on other M3 things.

setting (desired) target M3

This bug has to do with the fact that XUL doesn't handle HTML:STYLE, which is where the fixed positioning rules were placed. I tried moving the rules to a place where they'd be picked up by XUL (into a CSS file), but then AppRunner looked completely horked. I'm going to double-check the rules to decide if they're correct. If so, then it's still a fixed positioning bug.

As far as I can tell, fixed positioning just doesn't work right yet.

A major issue - but not technically a bug. Will plan meeting to resolve.

Adding Troy to the cc list. One of the commets was that fixed positioning doesn't work right.

It's not a fixed-positioning bug: that's the way CSS2 defines things to work. They need to change their style rules Removing Troy from Cc

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

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

Should this go to evaughan now, since his box tag layout will fix it?

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

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

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

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

Steve -- I'll move this to you as a reminder of the vert spacing improvements we discussed in tables. Nice guy, huh?

Re-summarizing to avoid M4 confusion. Apprunner clamped vertical problem has been solved, we're good-to-go for M4. Leaving this for M6 & rickg/buster.

changed misc bugs to M6

I don't think this is a blocker anymore, resummarizing so. Please add [BLOCK] back if you think this is blocking something.

setting my table bugs to M9

redistributing bugs across future milestones, sorry for the spam

Y'all seem to understand which bug you're talking about here/what bad behavior, but I don't. Perhaps I'm stupid ;-> , but if someone could explicitly state the current vs. desired behavior & the impact of not fixing this, I'd be grateful!

This bug is a RFE to the table code to handle stylistic attributes similar to what box layout does today. Originally, it was hoped that enhanced tables could make it so eric wouldn't need to write box layout. But box is written, so internally the point is moot. It may still be interesting for tables to do better vertical layout, so I'll mark this future/remind.

REMIND is deprecated per bug 35839.

No longer appears valid.