Crash in exported view when using TextInput


#1

We are experiencing crash that occurs when TextInput gets focused in exported view:

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[AppDelegate uKeyboardWillChangeFrame:]: unrecognized selector sent to instance 0x1d022d440'

I traced it down to resize event in https://github.com/fusetools/fuselibs-public/blob/master/Source/Fuse.Platform/iOS/SystemUI.uno#L98 but can’t debug it further due to limited iOS knowledge.

Any hints would be appreciated!


#2

Hey!

We need to see some code. It would be nice to see something to work with.


#3

I don’t think this is anything to do with our code - we have a TextInput, which triggers EnableKeyboardResizeNotifications() from Fuse.Platform/iOS/SystemUI.uno where crash occurs.

It is worth restating that crash happens only when we export view and embed it in native app. Everything works fine when running in standalone mode.

If you insist, I can prepare a test case, but I believe any TextInput can trigger that crash.


#4

@Maciek: of course we need a minimal repro. It’s much easier to work with something that is known to crash reliably. Otherwise it’s just random poking at the code in hopes to get the same result you are seeing.

Repro, and exact steps to take to get to the crash, including details on target platforms etc. would be highly appreciated.


#5

Hi Uldis!

Minimal reproduction here: https://dsc.cloud/vv/TextInputCrash.zip

It’s totally minimal as not much is needed to trigger that behaviour:

<App>
	<ClientPanel ux:Class="TCView">
		<Panel Width="200" Height="40">
			<TextInput Background="#EDE2FF" />
		</Panel>
	</ClientPanel>
	<ExportedViews>
		<TCView ux:Template="TCView" />
	</ExportedViews>
</App>

In that zip file you’ll find Xcode project that embeds exported view - if you run it on device, you’ll see the exact error I reported in my first post.

Thanks!


#6

Hey!

Thank you for minimal reproduction, I have created an issue.


#7

This is now becoming more and more pressing matter, as our app would only operate in a embedded view.

Right now we feel kinda cornered as the only thing we can achieve ourselves is to disable problematic notifications, at expense of loosing everything that comes with it (effectively rendering keyboard access useless).

I believe that it isn’t anything we could fix ourselves - however I might be wrong here as my knowledge of iOS internals is limited.

I’d really appreciate any hints on what we could try to mitigate to issue while waiting for official fix


#8

Hey there,
here’s a patch that hopefully fixes the issue. It would be great if you could test this assumption and confirm if it indeed is so.


#9

Nice one - I’ll get on it tonight

I guess I should apply this patch on the master branch of fuselibs-public?


#10

OK, I had a chance to give it a spin now

I took that patch, applied it on release-1.8 branch (with a small conflict as SystemUI is no longer public), and when used that fuselibs for exporting a framework, I got keyboard working as expected in native app!

I haven’t tested it inside-out, but crash is definitely gone

Thanks a lot, we feel much safer now!


#11

While that fix worked great for us, are there any plans to incorporate it into upcoming version of Fuse?


#12

This was fixed here: https://github.com/fuse-open/fuselibs/pull/1182