Skip to content
This repository

Platform windows resize their content windows #1867

Closed
BlairDuncan opened this Issue March 19, 2013 · 23 comments

5 participants

Blair Duncan Aparajita Fishman CappBot Andrew Hankinson Alexander Ljungberg
Blair Duncan

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?

CappBot
Collaborator

Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.

Andrew Hankinson

-#new
+bug
+AppKit

refs #101

CappBot
Collaborator

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

Aparajita Fishman
Owner

#accepted

CappBot
Collaborator

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

Alexander Ljungberg
Owner

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.

Aparajita Fishman
Owner

The current behavior is correct. If the user resizes the browser windows have to have a minimum area visible.

#wont-fix

Aparajita Fishman aparajita closed this August 01, 2013
CappBot
Collaborator

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

Blair Duncan

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.

Aparajita Fishman
Owner

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
{
    return aFrame;
}

@end

After a window is created:

window._constrainsToUsableScreen = NO;
Blair Duncan

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 Ljungberg
Owner
Aparajita Fishman
Owner
Blair Duncan

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.

Aparajita Fishman
Owner
Blair Duncan

"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.

Alexander Ljungberg
Owner
Aparajita Fishman
Owner
Blair Duncan

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.
normal

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...
small

Then he makes the browser window big again...
backtonormal

Embarrassed by the unexpected behavior, he looks at me with a WTF?

Aparajita Fishman
Owner

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:

  • The min size of windows is not respected when constraining.
  • Windows are not constrained horizontally to remain on screen.

#accepted
#needs-patch

Aparajita Fishman aparajita reopened this August 04, 2013
CappBot
Collaborator

Milestone: Someday. Labels: #accepted, #needs-patch, AppKit, bug. What's next? This issue needs a volunteer to write and submit code to address it.

Aparajita Fishman aparajita closed this August 09, 2013
Aparajita Fishman
Owner

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.

#fixed

CappBot
Collaborator

Milestone: Someday. Labels: #fixed, AppKit, bug. What's next? This issue is considered successfully resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.