Platform windows resize their content windows #1867

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

Projects

None yet

5 participants

@BlairDuncan

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
cappbot commented Mar 19, 2013

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

@ahankinson

-#new
+bug
+AppKit

refs #101

@cappbot
Collaborator
cappbot commented Mar 19, 2013

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

@aparajita
Collaborator

#accepted

@cappbot
Collaborator
cappbot commented Mar 20, 2013

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

@aljungberg
Member

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
Collaborator

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

#wont-fix

@aparajita aparajita closed this Aug 1, 2013
@cappbot
Collaborator
cappbot commented Aug 1, 2013

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

@BlairDuncan

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
Collaborator

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;
@BlairDuncan

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

@aljungberg
Member

The user did initiate the action - they resized the window. Apple does the same thing, and they did write the guidelines.

We do a minimal amount of work to keep windows inside the area the user can interact with.

One thing to keep in mind here is that if we allow a shrinking browser window to cause internal windows to end up "outside" the browser, then there might be no way for a user to recover that window. The fact that their browser shrunk might be 'permanent' - maybe they disconnected their huge Thunderbolt display, and now they're on a little MacBook Air and they're on a 5 month vacation. Should it be literally impossible to get that 'lost' window within view in this case?

We have to keep the non-platform windows reasonably within shrinking browser windows, or they can be irretrievably lost.

Alexander

On 2 Aug 2013, at 21:27, Blair Duncan notifications@github.com wrote:

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


Reply to this email directly or view it on GitHub.

@aparajita
Collaborator

Users constantly move, resize and zoom windows.

Your users do. My users don't, at least not during a session with an application. As Alexander said, it is imperative that we do a minimal amount to ensure that windows are not lost.

I will make the constraining behavior a global setting and also make it a public property for each window so that if users can't make through an application session without resizing their browser window to watch YouTube, it won't affect your application. :-)

@BlairDuncan

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
Collaborator

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's why I'm going to create a global setting. If you want windows to remain where they are (and potentially be lost) when the platform window resizes, you can specifically say so.

Note that we haven't received any other complaints about the current behavior, so I'm not inclined to change the default.

@BlairDuncan

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

@aljungberg
Member

But the window might already have been created by the time the screen resolution is reduced.

I believe that Cocoa does allow you to programatically place windows outside of the screen, and perhaps there are use cases for that - like a window about to slide in.

On 2 Aug 2013, at 23:34, Blair Duncan notifications@github.com wrote:

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.


Reply to this email directly or view it on GitHub.

@aparajita
Collaborator

Currently we are not moving windows if the window is decreased in width, only in height. That is a bug in the current implementation. In any case, he doesn't want them to be moved at all.

@BlairDuncan

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
Collaborator

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 aparajita reopened this Aug 4, 2013
@cappbot
Collaborator
cappbot commented Aug 5, 2013

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
Collaborator

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

@aparajita aparajita closed this Aug 9, 2013
@cappbot
Collaborator
cappbot commented Aug 10, 2013

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