Re: Full-screen mode broken after upgrading to Yosemite
Re: Full-screen mode broken after upgrading to Yosemite
- Subject: Re: Full-screen mode broken after upgrading to Yosemite
- From: Daryle Walker <email@hidden>
- Date: Sat, 14 Mar 2015 05:24:29 -0400
On Mar 13, 2015, at 9:16 PM, Ken Thomases <email@hidden> wrote:
>
> On Mar 13, 2015, at 4:29 PM, Daryle Walker <email@hidden> wrote:
>
>> My main browser window supports full-screen and optimized zoom. In Yosemite, those two functions share the green titlebar button. When I activate full-screen mode, with either the green button or the menu item, the window freezes without any visual change. The window can’t be moved or shifted out of the way upon switching apps. (The window doesn’t corrupt other Spaces, though.) The rest of the app still works, but new windows are always beneath the frozen one.
>>
>> When trying full-screen, this appears on the Xcode debug log:
>>
>>> 2015-03-13 17:17:18.850 Prairie[7319:1920249] *** Assertion failure in -[PrBrowserController windowWillUseStandardFrame:defaultFrame:], /Users/.../Prairie/PrBrowserController.m:297
>>> 2015-03-13 17:17:18.856 Prairie[7319:1920249] An uncaught exception was raised
>>> 2015-03-13 17:17:18.857 Prairie[7319:1920249] Standard web-browser window size too tall.
>
> You have an assertion in your code. The assertion is failing and thus throwing an exception. Once that happens, stuff is broken. This is the expected consequence of an assertion failing or an exception being thrown. The nature of the resulting brokenness is not predictable or diagnostic.
I knew my assertion was being triggered, but I don’t why it should since:
>> Why is my optimized-zoom sizing method called during a full-screen adjustment?
>
> Because it's not just for zoom. It's for computing the standard frame.
But this didn’t happen in Mavericks. Is this a bug in Yosemite? Or a possible allowable behavior?
>> Here’s my zoom sizing method:
>>
>>> - (NSRect)windowWillUseStandardFrame:(NSWindow *)window defaultFrame:(NSRect)newFrame {
>>> NSParameterAssert(self.window == window);
>>>
>>> // Based on the web content, get the maximum desired width and height.
>>> NSView<WebDocumentView> * const view = self.webView.mainFrame.frameView.documentView;
>>> NSSize const desiredContentSize = NSMakeSize(NSWidth(view.frame), NSHeight(view.frame) + ((CGFloat)!!self.isLoadingBarVisible * PrLoadingBarHeight) + ((CGFloat)!!self.isStatusBarVisible * PrStatusBarHeight));
>>>
>>> // Adjust that desired size to what's actually available.
>>> NSRect frame = [window contentRectForFrameRect:newFrame];
>>>
>>> frame.size.width = MIN(desiredContentSize.width, frame.size.width);
>>> frame.size.height = MIN(desiredContentSize.height, frame.size.height);
>>>
>>> // Adjust to the window's size bounds.
>>> frame = [window frameRectForContentRect:frame];
>>> frame.size.width = MAX(window.minSize.width, frame.size.width);
>>> frame.size.height = MAX(window.minSize.height, frame.size.height);
>>> NSAssert(frame.size.width <= newFrame.size.width, @"Standard web-browser window size too wide.");
>>> NSAssert(frame.size.height <= newFrame.size.height, @"Standard web-browser window size too tall.");
>
> Why do you think those are legitimate things to assert? Have you checked the values involved and the inputs to the computation?
I don’t quite remember. I think the default frame traditionally was the screen with most of the window, minus the dock, menu bar, and some other areas. This works for zoom, but not full screen.
I added NSLog line for the frame and new-frame’s width and height. Zooming out and back gets:
> 2015-03-14 04:51:26.839 Prairie[7802:2074846] Width: frame—768.000000, new-frame—1440.000000
> 2015-03-14 04:51:26.839 Prairie[7802:2074846] Height: frame—810.000000, new-frame—810.000000
> 2015-03-14 04:51:30.443 Prairie[7802:2074846] Width: frame—768.000000, new-frame—1440.000000
> 2015-03-14 04:51:30.443 Prairie[7802:2074846] Height: frame—810.000000, new-frame—810.000000
(I think the screen is 1440 x 900. The window is 684 x 513, plus 32 more in height for the top bar, and 22 more for the bottom bar, both active by default.) Doing the full screen, which craps out, gets:
> 2015-03-14 04:48:00.216 Prairie[7754:2061691] Width: frame—768.000000, new-frame—1440.000000
> 2015-03-14 04:48:00.216 Prairie[7754:2061691] Height: frame—895.000000, new-frame—859.000000
> 2015-03-14 04:48:00.217 Prairie[7754:2061691] *** Assertion failure in -[PrBrowserController windowWillUseStandardFrame:defaultFrame:], /Users/daryle/Documents/Repositories/Prairie/Prairie-osx/Prairie/PrBrowserController.m:299
> 2015-03-14 04:48:00.217 Prairie[7754:2061691] Standard web-browser window size too tall.
When the broken full screen is created during app restart & resume, all four lines appear as the full screen mode is created:
> 2015-03-14 04:51:05.662 Prairie[7802:2074846] Width: frame—684.000000, new-frame—1440.000000
> 2015-03-14 04:51:05.662 Prairie[7802:2074846] Height: frame—567.000000, new-frame—859.000000
> 2015-03-14 04:51:05.676 Prairie[7802:2074846] Width: frame—684.000000, new-frame—1440.000000
> 2015-03-14 04:51:05.676 Prairie[7802:2074846] Height: frame—567.000000, new-frame—859.000000
Nothing is logged when ending full-screen mode.
When I comment out the asserts, full-screen mode is still broken. Nothing is frozen, the black screen appears, and the browser content expands. In Mavericks, the content takes the entire screen; in Yosemite, the content fills the same space as the optimized-zoom does (which is smaller than full screen), even under-lapping the full-screen toolbar. The title bar, when shown by moving the cursor up top, is still broken with the title string off-center.
Am I the only programmer that doesn’t consider optimized-zoom old and busted? I think full-screen calling a function meant for zoom is a bug introduced in Yosemite, and no one at Apple made a program with a window that supports both expansions, so the improper mixture never got tested. (Remember that this doesn’t happen in Mavericks.)
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden