By placing a watchpoint on the SDL_Window->w I found where this happens. Here's the backtrace:

 * frame #0: 0x000000010a5939bf MyApp`SDL_SendWindowEvent(window=0x00006000023fc000, windowevent='\x05', data1=1024, data2=768) at SDL_windowevents.c:124
    frame #1: 0x000000010a701a7b MyApp`-[SDL_uikitviewcontroller viewDidLayoutSubviews](self=0x00007fc7a5604d20, _cmd="viewDidLayoutSubviews") at SDL_uikitviewcontroller.m:200
    frame #2: 0x0000000118047914 UIKitCore`-[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1824
    frame #3: 0x000000010d436b19 QuartzCore`-[CALayer layoutSublayers] + 175
    frame #4: 0x000000010d43b9d3 QuartzCore`CA::Layer::layout_if_needed(CA::Transaction*) + 395
    frame #5: 0x000000010d3b47ca QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 342
    frame #6: 0x000000010d3eb97e QuartzCore`CA::Transaction::commit() + 576
    frame #7: 0x000000010d3ec6fa QuartzCore`CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 76
    frame #8: 0x000000010d720c27 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    frame #9: 0x000000010d71b0be CoreFoundation`__CFRunLoopDoObservers + 430
    frame #10: 0x000000010d71ae34 CoreFoundation`CFRunLoopRunSpecific + 660
    frame #11: 0x000000010a6fa157 MyApp`UIKit_PumpEvents(_this=0x00007fc7a9002a00) at SDL_uikitevents.m:59

Ok that's very weird. Indeed the code in SDL_uikitviewcontroller#viewDidLayoutSubviews looks rather innocent.

Yet it's called when the view is like this:
<SDL_uikitopenglview: 0x7fc7a551a370; frame = (0 0; 1024 768); autoresize = W+H; layer = <CAEAGLLayer: 0x600001a97d60>>

For some reason, the SDL_uikitopenglview got a 1024x768 frame...

When in SDL_uikitviewcontroller#viewDidLayoutSubviews, the view hierarchy looks like this :
(lldb) po self.view.superview
<SDL_uikitwindow: baseClass = UIWindow; frame = (0 0; 320 728)>
   | <SDL_uikitopenglview: frame = (0 0; 1024 768);>
   |   | <UITextField: 0x7fc7a6808000; frame = (0 0; 0 0); >
   |   |    | <_UITextFieldContentView: 0x7fc7a5401c10; frame = (0 0; 0 0); >

Ok, got it (mostly). The issue comes from the soft-keyboard.
For some reason, [SDL_uikitviewcontroller keyboardWillHide] is called, and this destroys the view frame.

Indeed, #define SDL_IPHONE_KEYBOARD 0 fixes this problem.

Now, I've only quickly looked at the soft-keyboard code, but I think it's a bit outdated. Namely, it looks like it makes a lot of assumptions about the keyboard layout (e.g. app is fullscreen, keyboard will come from the bottom), all of which are most likely wrong on iPad.

Also, #ifdef SDL_IPHONE_KEYBOARD needs to become #if SDL_IPHONE_KEYBOARD in SDL_uikitwindow.m:299

Looks like I spoke too fast. "#define SDL_IPHONE_KEYBOARD 0" does indeed fix the problem when typing text in Safari, but a similar corruption happens later on.

Steps to get another corruption:

 - Start Safari
 - Bring up dock, drag SDL app to the right of the screen in "slide over"
 - Move SDL app right to remove it
 - Slide from the right of the screen towards the center to bring back the SDL app

At this point SDL_GetWindowSize is wrong yet again.

Ok, find the other culprit again. When sliding the app away, it receives a "will resign active" event, which eventually calls UIKit_ComputeViewFrame which, once again, assumes iOS runs apps fullscreen.

Here's the backtrace:

  * frame #0: 0x000000011cafaf36 UIKitCore`-[UIView(Geometry) setFrame:]
    frame #1: 0x000000010f1de6b7 MyApp`UIKit_UpdateWindowBorder(_this=0x00007f8bd6014e00, window=0x00006000008f47e0) at SDL_uikitwindow.m:296
    frame #2: 0x000000010f1de7cd MyApp`UIKit_SetWindowFullscreen(_this=0x00007f8bd6014e00, window=0x00006000008f47e0, display=0x0000600001ae8230, fullscreen=SDL_FALSE) at SDL_uikitwindow.m:320
    frame #3: 0x000000010f13402e MyApp`SDL_UpdateFullscreenMode(window=0x00006000008f47e0, fullscreen=SDL_FALSE) at SDL_video.c:1333
    frame #4: 0x000000010f138dd7 MyApp`SDL_OnWindowMinimized(window=0x00006000008f47e0) at SDL_video.c:2603
    frame #5: 0x000000010f06efb2 MyApp`SDL_SendWindowEvent(window=0x00006000008f47e0, windowevent='\a', data1=0, data2=0) at SDL_windowevents.c:132
    frame #6: 0x000000010f13b19c MyApp`SDL_OnApplicationWillResignActive at SDL_video.c:4045
    frame #7: 0x000000010f1d4e6c MyApp`-[SDLUIKitDelegate applicationWillResignActive:](self=0x00006000033e40a0, _cmd="applicationWillResignActive:", application=0x00007f8bd4d00000) at SDL_uikitappdelegate.m:475
    frame #8: 0x000000011c62641a UIKitCore`-[UIApplication _deactivateForReason:notify:] + 786

It looks like this is too involved to fix for 2.0.10 release.

Let's hold off with potential breaking changes and revisit this after release.

Thanks!

(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.