Trouble receiving note on iOS

[ryanpcmcquen]

My editor works fine in Firefox on a desktop comp, but on an iPhone, the note doesn't seem to receive data, so the note is aways blank.

https://github.com/ryanpcmcquen/standardnotes_org_mode_editor

I am on iOS 14. Any ideas on how I can fix this?

[JaspalSuri]

Currently on our internal beta, anything that I type into the note doesn't get saved. Reloading the latest stable web app shows that the changes I've made weren't saved, either. Can you open a duplicate tab of the web app to see if the changes were saved (if you haven't already)?

[ryanpcmcquen]

The web app works correctly.

[JaspalSuri]

Does the README on the repo have the latest link to the extension? I've noticed that it changed, but the desktop said that it was unable to download the extension for some reason, despite having successfully installed it.

[ryanpcmcquen]

The link changed because that CDN was creating issues ... as far as I know it should install successfully with the new link.

[ryanpcmcquen]

@mobitar and @JaspalSuri, this is actually a regression with 1.2.8.

1.2.7 works perfectly with my extension.

[moughxyz]

Security related changes in 1.2.8: 23987a8#diff-fcef9a4765497500d480c035ab3870c8

[ryanpcmcquen]

I think this would break all external editors on at least iOS.

[ryanpcmcquen]

Has anyone found a workaround for iOS?

[SebTota]

I am having the same issue. I initially started building an editor using editor-kit when I experienced this issue. I then switched to component-relay thinking editor-kit was the issue, but the issue persisted. Rolling back to sn-component-api@1.2.7 does fix the issue as @ryanpcmcquen mentioned.

The issue seems to be coming from this change going from 1.2.7 to 1.2.8.

This actually causes problems on all platforms (in certain environments), but it happens to be more prevalent on iOS. Contrary to this inline comment, the first event is not always the most reliable one.

The first event on iOS seems to be an incomplete message.

And all further messages actually lack an origin.

There is actually a note, and fix, regarding what I believe is this issue in the unit test.

Further, this is not only an issue on iOS but on all platforms. I've noticed this exact same issue on Android but it happens much less frequently. My guess is that most of the time the first event that is fired in Android is a valid event and the origin is set properly.

Also, a similar issue occurs on desktop platforms (at least on Mac OS), but it is slightly different and occurs quite rarely in development mode when using Webpack.

Dev:

Prod:

This event is rare and most of the time the component-registered event will fire off first, therefore ignoring the webpackOK event, but it is not a guarantee. This can be pretty frustrating because it's difficult to debug an issue like that and it can cause a lot of confusion for developers.

I propose this if statement is changed to check if the action of the event data is a register-component event because that would theoretically be more reliable than just assuming the first event is the most reliable.

I can make a PR for this if you'd like, I just want to make sure you know how I came to this conclusion and to see if you agree.

[JaspalSuri]

Hi @SebTota, thank you for looking into this! I'll forward this to the dev team to review and they'll let you know whether or not to make a PR for it. (You can always make a PR, of course, but I'll have them review your comment to save you time.)

[johnny243]

Hi @SebTota, thanks for your insight on this. Just to make sure I'm following you correctly, is this issue present on latest component-relay@2.1.0?

[SebTota]

Hi @johnny243, yes this issue was present on the latest component-relay@2.1.0. To be completely clear, it was on the latest version of editor-kit. Once I saw the issue while using editor-kit, I removed the editor-kit logic and started using component-relay where the issue persisted.

I then rolled back to component-relay@1.2.7, like @ryanpcmcquen suggested, which finally allowed the application to work on all platforms. Finally, I rolled up to component-relay@1.2.8 where the issue came back on iOS.

Strangely though, I've built two editors and only one experienced the issue. With both editors, the editors themselves do actually render and are usable. The issue is that they do not load the saved notes content and they also don't save any new updates to the note content as you type.

I was going to test my other editor that did work on iOS, or maybe even just the Bold Editor since that also works, but I haven't had the time. I'll update the issue here if I get a chance to test one of them today.

[moughxyz]

The proposed fix of taking the origin from the component-registered event makes sense, but in your screenshots that event doesn't have an origin, so this wouldn't ultimately solve the issue right? Given that none of our editors have this issue, and that our editors don't do anything special, this is most likely something to do with your editor. Can you share the code for your working editor on iOS, and non-working editor on iOS? Perhaps we can deduce a difference.

[SebTota]

Can you share the code for your working editor on iOS, and non-working editor on iOS?

Both of these are using editor-kit, but if you'd like me to revert them back to component-relay please let me know.
Working on iOS
Not working on iOS

As a heads up, the editor that works on iOS didn't have its font finished so everything looks super dark and hard to read. But you can still see the changes being made and saved.

The proposed fix of taking the origin from the component-registered event makes sense, but in your screenshots that event doesn't have an origin, so this wouldn't ultimately solve the issue right?

After looking into the events that come from Bold Editor, it does look like the event that is causing trouble for me doesn't occur in the Bold Editor. I can probably figure something out to try to block that event for my editor, but I just thought it was interesting that I wasn't the only one having this issue.