On Mar 13, 2015, at 9:16 PM, Ken Thomases <[email protected]> wrote:
>
> On Mar 13, 2015, at 4:29 PM, Daryle Walker <[email protected]> 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 protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
