I've got this weird issue with my iOS app where a stuck pixel often appears after a while using the application and I can't find where it came from.
I've even done the following with LLDB and it is still there:
expr [((UIWindow *)((UIApplication *)[UIApplication sharedApplication]).keyWindow) setHidden:YES] // and removeFromSuperview
The pixel disappears when you close the app and reappears when you open it again.
Any ideas on how I can debug this further? Unfortunately I haven't managed to reproduce it consistently.
EDIT: this managed to remove the pixel:
[(UIWindow *)[(NSArray *)((UIApplication *)[UIApplication sharedApplication]).windows objectAtIndex:2] setHidden:YES]
The objectAtIndex 2 was:
<UITextEffectsWindow: 0x14de6280; frame = (0 0; 768 1024); gestureRecognizers = <NSArray: 0x14dd77a0>; layer = <UIWindowLayer: 0x14deb7f0>>
Any ideas?
EDIT: narrowed it down more. The pixel was removed while debugging by doing this:
expr [((UITextMagnifierCaret *)[(NSArray *)((UIWindow *)[(NSArray *)((UIApplication *)[UIApplication sharedApplication]).windows objectAtIndex:2]).subviews objectAtIndex:0]) remove]
Related
According to Crashlytics, this issue only on iOS 12, I can't to reproduce that.
There is an assumption that this is due to the toolbar for the keyboard, but what exactly the problem is is not clear.
Attempting to attach a window (<UITextEffectsWindow: 0x1380bfa00; frame = (0 0; 320 480); hidden = YES; layer = <UIWindowLayer: 0x2830cc5e0>>) to a screen with a nil FBSDisplayIdentity
I got a window from the code below in iOS11:
UIWindow *window = [UIApplication sharedApplication].windows.lastObject;
its infomations were printed on console is like this:
<_UIInteractiveHighlightEffectWindow: 0x7fdfe84b88e0; frame = (0 0; 375 812); hidden = YES; opaque = NO; userInteractionEnabled = NO; gestureRecognizers = ; layer = >
what's confused me is its isHidden property default value is YES, why ? I tried to search some more infomation about it with key word "_UIInteractiveHighlightEffectWindow", l got nothing but it's a new property in iOS11. Apple also gives nothing about it .
Any one know something about it ? Any help is appreciated ! thanks !
Yes, "_UIInteractiveHighlightEffectWindow" is new on iOS, and there isn't much information about it currently.
However, if the topmost layers is need, use [UIApplication sharedApplication].keyWindow instead of [UIApplication sharedApplication].windows.lastObject, that would probably solve the problem.
I found some good explanation here:
diffrence between [[[[UIApplication sharedApplication] delegate] window] and [[UIApplication sharedApplication].keyWindow?
I have a piece of code pointing a UIPopoverController to a menu item in iOS 8/9, it was working in iOS7 and in fact it's in production on the App Store. For some reason, it doesn't show properly when I tried to test the code on iOS 8/9.
For some reason, the iOS framework inserts the black shadow thing about 75% of the screen. It's like it thinks the device is in portrait mode. My app is always in the landscape mode. Portrait is not considered.
When I click on the area outside the dark shadow, I get:
_UIApplicationHandleEventFromQueueEvent, _windowServerHitTestWindow: <UIWindow: 0x1355065a0; frame = (0 0; 768 1024); opaque = NO; autoresize = RM+BM; gestureRecognizers = <NSArray: 0x174645520>; layer = <UIWindowLayer: 0x174223920>>
I suspect something is making the framework believes the app is running portrait. The error message above is saying the area outside the dark shadow has no respondent to my clicking action. It's my suspicion, I'm not 100% sure.
and the code:
-(void) showActionControllerByPopover:(UIViewController *)actionController item:(UIBarButtonItem *)item
{
UINavigationController * const navController = [[UINavigationController alloc] initWithRootViewController:actionController];
[navController.navigationBar setBarStyle:UIBarStyleDefault];
[_popController dismissPopoverAnimated:YES];
_popController = [[UIPopoverController alloc] initWithContentViewController:navController];
[_popController setDelegate:self];
[_popController setPopoverContentSize:CGSizeMake(320, 768)];
[_popController presentPopoverFromBarButtonItem:item
permittedArrowDirections:UIPopoverArrowDirectionAny
animated:YES];
}
I got the following code in a VC in an old project (no storyboard, pure code) :
- (void)viewDidLoad {
[super viewDidLoad];
self.mapView = [[MKMapView alloc] initWithFrame:CGRectInset(self.view.frame, 10, 10) ];
[self.view addSubview:self.mapView];
self.view.backgroundColor = [UIColor redColor];
self.mapView.autoresizingMask = UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth;
self.view.translatesAutoresizingMaskIntoConstraints = NO; // <--- this line
}
If I comment the last line, a rotation from portrait to landscape or the other way is about 3 seconds under ios8 !! Also, occasionally at random times Unable to allocate render buffer storage! errors appear.
If I don't comment it, it's almost instantaneous (0.7seconds).
It seems it is only related to mapviews, the other views/VCs rotate just fine.
Under ios7 the rotation is fast in any case with that line commented or not.
Why ? And why is only the mapview affected ?
Edit: It seems clearly the autoresizingmask is wrong. If in viewDidLoad I set its value to none and manually change the frame in willRotate, it works fast.
I had the same problem when the application came back from the background. It froze a few seconds and then it worked again. I used a .xib file without Autolayout.
When I updated the .xib file and added the Autolayout option the problem was gone. I came up with this idea because you wrote that autoresizing was the problem in your solution.
I'm running into a tricky glitch.
I've got a .xib, which was created by XCode when I created a new UIViewController subclass. It has quite a few elements, including some UIButtons, a bunch of UILabels, a small UIView with some other views inside it, and a UIImageView containing a mostly-transparent image.
In viewDidLoad, I set the background color of the UIImageView to a color using a pattern image.
When I display this view controller in the simulator or on my iPhone 4 (both running iOS 5.1), everything goes smoothly; the patterned background displays, all the interactions work, and so on.
When I test on iOS 4.3, however (either in the simulator or on my iPod Touch 2G), it appears that everything I'm trying to manipulate based on an outlet (e.g. [self.myBackgroundImageView setBackgroundColor...] or [self.mySegmentedControl setEnabled:NO]) just doesn't work at all.
The only even vaguely unusual thing I'm doing when the view gets presented is this, which makes it size properly in a popover:
- (void) viewWillAppear:(BOOL)animated {
CGSize size = CGSizeMake(320, 480); // size of view in popover
self.contentSizeForViewInPopover = size;
[super viewWillAppear:animated];
}
I really can't think of anything else that might be the problem. I've cleaned, rebuilt, all that stuff. Still no dice.
Has anyone else encountered this?
UPDATE per request by ott:
Added the following at the end of -viewDidLoad:
NSLog(#"self.myBackgroundImageView = %# | %#", [self.myBackgroundImageView description], [[self.myBackgroundImageView backgroundColor] description]);
...The output is:
self.myBackgroundImageView = <UIImageView: 0x6d48c80; frame = (0 0; 320 480); autoresize = RM+BM; userInteractionEnabled = NO; layer = <CALayer: 0x6d48b60>> | <UIImageView: 0x5f459b0; frame = (0 0; 320 480); autoresize = RM+BM; userInteractionEnabled = NO; layer = <CALayer: 0x5f45890>> // kCGColorSpaceModelPattern 1
So... not nil. Not sure what the story is here.
UPDATE 2:
It appears the disabling of a UISegmentedControl in iOS 4.3 doesn't dim its display, so that's what that part was about. As for the background pattern image: I can't find confirmation of this, but I'm starting to think it's a bug in iOS 4 that makes a background color using a pattern-image UIColor not display properly on a UIImageView. It works fine if I make the UIImageView have a clear background and put the pattern image UIColor as the background of the main view instead. If anyone comes up with a workaround, or confirmation that this is indeed an iOS 4 bug, it would be much appreciated.