Closed Bug 3444 Opened 26 years ago Closed 23 years ago

Apprunner/layout: vertical spacing improvements

Categories

(Core :: Layout: Tables, enhancement, P2)

All
Other
enhancement

Tracking

()

RESOLVED INVALID
Future

People

(Reporter: mcafee, Assigned: buster)

References

Details

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.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WONTFIX
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 :-(
Status: RESOLVED → REOPENED
But we still have the bug. Reopening, assigning to trudelle.
Assignee: kipp → trudelle
Status: REOPENED → NEW
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.
Assignee: trudelle → rickg
Summary: Apprunner/Linux: Layout is clamped to a fixed height → [BLOCK] Apprunner/Linux: Layout is clamped to a fixed height
Resolution: WONTFIX → ---
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
Assignee: rickg → ramiro
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...
Assignee: trudelle → rickg
OS: Linux → other
Hardware: PC → All
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.
Target Milestone: M3
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.
Status: NEW → ASSIGNED
Target Milestone: M3 → M5
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. ***
Assignee: rickg → buster
Status: ASSIGNED → NEW
Steve -- I'll move this to you as a reminder of the vert spacing improvements we discussed in tables. Nice guy, huh?
Summary: [BLOCK] Apprunner: Layout is clamped to a fixed height → [BLOCK] Apprunner/layout: vertical spacing improvements
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.
Status: NEW → ASSIGNED
changed misc bugs to M6
Summary: [BLOCK] Apprunner/layout: vertical spacing improvements → Apprunner/layout: vertical spacing improvements
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
Target Milestone: M9 → M11
Target Milestone: M11 → M20
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M20 → M22
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.
Severity: normal → enhancement
Status: ASSIGNED → RESOLVED
Closed: 26 years ago24 years ago
Component: Layout → HTMLTables
Resolution: --- → REMIND
Target Milestone: M22 → Future
REMIND is deprecated per bug 35839.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
No longer appears valid.
Status: REOPENED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.