We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Hey Alex, how should we handle this?

(In reply to Sam Lantinga from comment #1)
> Hey Alex, how should we handle this?

Taking a quick look at SDL's iOS source code, there's a few bits like this which seem like they'll require a good amount of testing to make sure no regressions are introduced by supporting split view:

@implementation SDL_uikitwindow

- (void)layoutSubviews
{
    /* Workaround to fix window orientation issues in iOS 8+. */
    self.frame = self.screen.bounds;
    [super layoutSubviews];
}

@end

Alex, is this something we can fix after we ship 2.0.10?

(In reply to Sam Lantinga from comment #3)
> Alex, is this something we can fix after we ship 2.0.10?

I probably won't be able to dedicate enough time to properly test and fix this in the very near future, myself. In my opinion we can ship 2.0.10 without a fix for this, but it should ideally be solved before iOS 13 ships.

Agreed. Will you be able to revisit this in that timeframe?

I think so, yeah.

Great, thanks!

I submitted a change here which fixes it for me: https://hg.libsdl.org/SDL/rev/d3a97780aa05

I did a good amount of testing, and it looks like it was only that line which needed to change. I haven't found any regressions so far. Let me know if it works for you!

As a matter of fact I had eventually written a very similar patch. I didn't submit it because I wasn't confident enough in the fix though, but my patch was virtually the same (I just removed the offending line instead of making it conditional to iOS 9, so yours is definitely better).

Anyway, for what it's worth, it worked in my use case too :-)

I spoke too fast, there are still some issues with this.

Here's a way to reproduce a problem:
 - Run Safari
 - Bring up the dock by swiping up from the bottom of the screen
 - Drag the icon of your SDL app to the right side of the screen to run it in side mode
 - So far, so good, everything works well
 - Now type something in Safari's address bar

Result : rendering is botched in the SDL app.

Tested on iPad Air 2 simulator running iOS 12.1.

Actually this might be another bug in "SDL_GetWindowSize".

I'm using "SDL_GetWindowSize" to recompute the layout of elements in my window, and doing the steps before corrupts the output of SDL_GetWindowSize.

Before clicking the Safari address bar, SDL_GetWindowSize returns 320x728, after clicking the Safari address bar (and not touching anything else), it returns 1024x768.

Can you please report the other issue as a separate bug?

Thanks!

Sure! See #4705.

Actually I'm sorry but I think this is far from resolved, so I took the liberty of reopening this issue.
 - See #4705 for at least two bugs in SDL_GetWindowSize that breaks SplitView on iOS
 - Also SDL_uikitwindow.m:111 is now wrong ("window->flags &= ~SDL_WINDOW_RESIZABLE;  /* window is NEVER resizable */"
 - Globally, UIKit_ComputeViewFrame is wrong too (and I'm not sure how it can be easily fixed)

Forgot to reopen w/ my previous comment.

(In reply to romain.goyet from comment #14)
>  - Also SDL_uikitwindow.m:111 is now wrong ("window->flags &=
> ~SDL_WINDOW_RESIZABLE;  /* window is NEVER resizable */"
That particular bit of code is only run when the window is on an external display.

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

I think I've fixed the issues as of https://hg.libsdl.org/SDL/rev/806598d72494 , let me know if you have any more.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.