You can clone with
There has been a change to the way windows resize lately and it produces a poor user experience. Its not something that can be checked in cocoa, since you cannot really grab, move around and resize the desktop.
To demonstrate use the /Tests/Manual/CPWindowResizeStyle.
Arrange and resize the content windows to be in a position and size that you like.
Now try resizing the main platform window. As it gets smaller, the content windows that are resizeable get resized. Making it bigger again and the windows that were resized remain and do not resize.
Once the app has launched, should content windows even resize with the platform window?
Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.
Milestone: Someday. Labels: AppKit, bug. What's next? A reviewer should examine this issue.
Milestone: Someday. Labels: #accepted, AppKit, bug. What's next? A reviewer should examine this issue.
We discussed this on IRC for a while and it seems sensible to keep all windows inside of the constraints of the browser window, although not resize them. I haven't had a moment to test this but I believe on the Mac when the desktop resolution becomes smaller (such as when you disconnect a TB display) windows are moved up and to the left to ensure they always remain visible and possible to interact with.
It should be impossible to get a window "lost at sea" outside of the browser. The reduction in size might be semi-permanent for the user, e.g. they used a larger screen temporarily but now they don't have it anymore. Since windows often remember their position they could be lost "forever" if we didn't move them.
Another topic of consideration is what happens when we implement setMinSize on platform windows. In this case we might use browser scrollbars once the browser becomes too small to fully host the platform window at its minimum size. In that case it's fine if a window is in the scrollable area.
The current behavior is correct. If the user resizes the browser windows have to have a minimum area visible.
Milestone: Someday. Labels: #wont-fix, AppKit, bug. What's next? A reviewer or core team member has decided against acting upon this issue.
The current behavior is correct?
All it does is change the height of enclosing windows. It does nothing with the width and more importantly fails to move the window within the visible area of the browser. All it does it frustrate the user.
The algorithm moves the window first and only then resizes if necessary. This is exactly what Cocoa does if you reduce the resolution of your display, go ahead and try it. And then if you increase the resolution, the windows don't magically return to their previous state. If you can demonstrate different behavior, I'd be happy to see it.
I can't quite understand why your users are constantly resizing their browser windows, and unless they are drastically reducing the size, why it would make much of a difference.
If this behavior is really troublesome, you can override in two ways.
With a category:
@implementation CPWindow (override)
- (CGRect)_constrainFrame:(CGRect)aFrame toUsableScreenWidth:(BOOL)constrainWidth andHeight:(BOOL)constrainHeight
After a window is created:
window._constrainsToUsableScreen = NO;
A better solution would be to only have windows constrain to the usable screen when they are created and thus never "lost at sea". After that, any user action would be intentional and within their control. Users constantly move, resize and zoom windows. Having the position and size of the document windows change when a user resizes the browser windows is completely against apples human interface guidelines... "Allow the user, not the computer, to initiate and control actions."https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html
Alexander, that is why I suggest we only do the "moving" within the visible space when the window is created. That way even when the position is recorded in userdefaults when the window is created if it doesn't fit is gets moved into viewable space.
"What about the case where a user shrinks the size of the window, doesn't notice that a window is now offscreen, wonders where it has gone, and doesn't think of growing the window to find it?"
That happens now.
If you try the /Tests/Manual/CPWindowMovableTest for example.
Load it in a full size window and then move the browser window to be tall and narrow in width. The little "move me" window stays where it is, hidden to the user.
This is a visual simulation of what I witnessed that caused me to bring this up... The user (who happened to be my boss) was demoing some new features to a group of users. He normally uses a mac but for the demo he was using one of the users windows machine.
At some point in the demo he wants to copy text from an email. I don't know why but to do so he grabs the bottom corner of the browser window and made it small so he could access the email from the window below...
Then he makes the browser window big again...
Embarrassed by the unexpected behavior, he looks at me with a WTF?
Well, I looked more closely at what Cocoa does to windows when resizing the screen, and it is quite complex (as in not very predictable). I really don't want to spend time reproducing it, that's for sure.
I'm going to go ahead and implement a global CPWindowConstrainToScreen switch as well as the CPApplicationDidChangeScreenParametersNotification and the applicationDidChangeScreenParameters: delegate method. This will allow disabling or customization of the standard behavior.
In addition, there are two bugs in the current constraining code that need to be fixed:
Milestone: Someday. Labels: #accepted, #needs-patch, AppKit, bug. What's next? This issue needs a volunteer to write and submit code to address it.
Three solutions provided:
2183c6d implements CPWindow +setConstrainWindowsToUsableScreen:.
d751fea ensures that window's minSize is respected when constraining to the screen.
fc93190 notifies when the platform window changes, after the built in adjustments have been made, allowing you to make your own adjustments.
Milestone: Someday. Labels: #fixed, AppKit, bug. What's next? This issue is considered successfully resolved.