One of the takeaways from WWDC should always be a renewed promise to yourself and Apple engineers: “File better Radars”. With some time at my hands jettting back over the Atlantic Ocean, I prepared a demo project and the text for my latest filing.
When filing a bug, you should try to provide the following items:
- Steps to Reproduce should be absolute idiot-proof in reproducing the steps. If an Apple engineer cannot immediately follow your instructions to see the issue the Radar will most likely go to the bottom of the pile and has thus lost its chance of being fixed soon.
- Sometimes new features make certain assumptions that are in contract to previously known behavior. This Radar is one such case. This is what the Expected Results versus Actual Results is for. Explain why you were led to expect a behavior of the software that turned out to be different in actuality. Here I was expecting for presentViewController to obey the presented VC’s wantsFullScreenLayout, but it doesn’t.
- It also helps a great deal if you can provide a good usage scenario. What are you trying to do? In this case I am trying to present a full screen view controller from a non-full-screen-view-controller with a custom animation. I need to do that for my iCatalog app where the catalog library will always show the status bar, but when viewing one catalog the user might want to hide the status bar.
- If the problem only started to appear in a certain iOS version, then you should mention this in the Regression section. The new presentViewController supposedly replaced the previously existing presentModalViewController in iOS 5, so this is when my problem here first appeared.
- Finally, if your bug report is original enough, then you will be asked for a sample project to demonstrate the issue. As you get better at evaluating whether a problem stems from your own code or Apple’s you will find more and more bug reports going to Attention status and asking you for such a small sample project as opposed to simply being closed as Duplicate. Screenshots are nice too, but not as valuable because with the sample project the engineer can actually test if the problem has been fixed as well.
So, what Radars did you file right after getting back from WWDC? Good ones, I hope!
View frame inconsistency using presentViewController + wantsFullScreenLayout Y/N
Summary:
If presentViewController is used from a VC that has wantsFullScreenLayout == NO to present a modal view with wantsFullScreenLayout == YES then the frame set is incorrect.
Steps to Reproduce:
Run the supplied Demo Project.
- tap the top button (uses presentModalViewController)
- note that the blue view covers the entire display, even when hiding the status bar (via the toggle button)
- return to the root VC via the dismiss button
- tap the second button (uses presentViewController)
- note that the blue view background now begins below the status bar. Hiding it makes the black UIWindow background show through
Expected Result
A presentViewController with custom animations should obey the wantsFullScreenLayout property of the presented ViewController.
Actual Results:
The presented ViewController’s view is always offset to match the presenting viewController’s wantsFullScreenLayout property. The frame set on the manually added subview gets overridden and shifted to the same origin as the presenting viewController’s view’s origin.
Regression:
As demonstrated by the demo project the (now deprecated) presentModalViewController does the right thing. The behavior should be consistent between the deprecated and the method replacing it.
Notes:
The demo project has two view controllers, the RootViewController with wantsFullScreenLayout == NO, the ModalViewController with wantsFullScreenLayout == YES. When presented with presentModalViewController then ModalViewController goes properly under the status bar. When presented with the new iOS 5 method presentViewController in combination with a custom animation then the ModalViewController’s view is always forcefully put below the status bar.
There is a button to hide the status bar in ModalViewController. If it was presented with the deprecated method the blue background color shows because the view is properly layouted below it. With the new method the UIWindow’s black color shows because the frame is set incorrectly ignoring the wantsFullScreenLayout property.
The use case for this behavior is to have a root view that is showing the status bar (e.g. a scroll view showing digital catalogs). A modal view (is to be presented from this that requires hiding of the status bar, e.g. for full screen viewing of a digital catalog.
The only workaround is to have also the presenting ViewController with wantsFullScreenLayout == YES and offset all subviews on the RootVC so that they don’t get positioned below the status bar.
This is filed as Radar 11688188, and also on Open Radar to allow developer colleagues to find and dupe it. Download the Sample Project.
Categories: Bug Reports
