Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

CPWindow setMinSize does not set overflow properly #101

Open
cappuccino opened this Issue May 3, 2009 · 12 comments

Comments

Projects
None yet
4 participants
@ghost

ghost commented May 3, 2009

CPWindow includes utilities to setMinSize and setMaxSize. While these seem to work correctly, when the user resizes the window to less than it’s minimum size, the overflow of the window/contentView should be changes to add browser scroll bars into the window.

original LH ticket

This ticket has 0 attachment(s).

@ghost

ghost commented May 3, 2009

CPWindow setMinSize does not set overflow properly

CPWindow can not (or at least should not be able to) be resized smaller than its minimum size, or larger than its maximum size. I’m not sure what you’re proposing.

by Ross Boucher

@ghost

ghost commented May 3, 2009

CPWindow setMinSize does not set overflow properly

Sorry, I meant to specify this is relating only to the bridge window. By default, you remove the browsers scroll bars. However, I feel that the bridge window’s setMinSize should implement special behavior to add the browser’s scroll bars back if the user resizes their browser to less than the minimum size (which is not prevented by setMinSize).

by nciagra

@ghost

ghost commented May 3, 2009

CPWindow setMinSize does not set overflow properly

We should just prevent this from happening, that can be done right?

by Francisco Tolmasky

Contributor

aparajita commented Apr 10, 2012

Theoretically it can be done, we will have to track resize events and change the window size if necessary. It could be kind of ugly with the window size jumping around. Perhaps setting the contentView div's min-size would be preferable.

cappbot commented May 9, 2012

Milestone: Someday. Labels: #accepted, AppKit, feature. What's next? A reviewer should examine this issue.

Contributor

daboe01 commented Jul 12, 2014

the feature is controversial among the core-devs.
nobody has missed it during the past 5 years.
+#wont-fix

cappbot commented Jul 12, 2014

Milestone: Someday. Labels: #wont-fix, AppKit, feature. What's next? A reviewer or core team member has decided against acting upon this issue.

@cappbot cappbot closed this Jul 12, 2014

cappbot commented Jul 12, 2014

Milestone: Someday. Labels: #wont-fix, AppKit, feature. What's next? A reviewer or core team member has decided against acting upon this issue.

Contributor

aparajita commented Jul 12, 2014

#accepted

I'm reopening this, because it can be implemented rather easily in the future once we standardize on IE9+. The problem before was that IE6-8 did not have a working min-width/min-height CSS attribute.

@aparajita aparajita reopened this Jul 12, 2014

cappbot commented Jul 12, 2014

Milestone: Someday. Labels: #accepted, AppKit, feature. What's next? A reviewer should examine this issue.

Contributor

daboe01 commented Jul 15, 2014

please keep in mind that constraining the browser window may annoy the user. this is unexpected and a bit like popups.
i would prefer the original proposal to introduce the native scrollers.

Contributor

aparajita commented Jul 15, 2014

i would prefer the original proposal to introduce the native scrollers.

That's what min-width/min-height would do in conjunction with overflow: auto.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment