ios: crashing when opening the app with notifications allowed #5100
Comments
teidesu
changed the title
|
is this still happening to you? i am unable to repro |
yep, still happening on iOS 18.1 (22B5045g), app 1.91.1.464 2feb5be. screencast: https://github.com/user-attachments/assets/15b8bbf3-0292-4cb2-b4cb-1c3463b6a264 |
|
Are you able to scroll down the notifications at all on web to see if there's a weird post or anything? |
|
Ah, never mind. I'm able to see some logs now, though this is quite bizarre. Need to figure out how to possible reproduce this, not entirely sure how yet... Will keep you posted. |
|
This happens to me exactly as described on my account with handle edit to add: I had previously tried reinstalling the app from scratch and trying both accounts, it only fails if using the @erisa.mraow.party and with notifications on or when viewing notifications page without notifications on. |
|
yep, im using my own pds as well. though i did test with a bsky.social account and it happened it there as well so i figured it's not that relevant |
|
The strange thing is that I'm running my own PDS as well and don't have any issue there. What PDS versions are you all running? (https://pds.haileyok.com/xrpc/_health will tell you) It's definitely something with the |
0.4.51 for me
with notifications disabled i don't see a registerPush at all with them enabled the app seems to crash before the 
i can give you an account on my pds if that might help :> |
|
Yea, that could actually be useful if you don't mind. |
|
dmed on bluesky |
|
Well, I found the issue - at least, what's causing the crash. I'm not sure what exactly is going on aside from that yet. Anyway, there are two endpoints that are causing the crash: There's a check in https://github.com/facebook/react-native/blob/1288e38423f93ed57737dd9b40ad55696494d6f4/packages/react-native/Libraries/Blob/RCTFileReaderModule.mm#L76 for Note that the Anyway, I'm also curious why |
|
After more closely looking, it looks like there's a @Erisa, I'd be curious if you see the same header in your response. I'm going to patch/PR a fix for the RN crash itself, but also trying to figure out where that header is coming from since it shouldn't be there for these responses. |
i believe it's being added by cloudflare, since accessing the reverse proxy directly doesn't return that header: |
|
Interesting! Well, if you figure out how to remove that header in the short term then that should fix the problem. Otherwise, I'm going to write a fix and it'll come out in the next release. Thanks for all your help in debugging this! |
|
I have no idea why Cloudflare adds that header, but this works: on https://dash.cloudflare.com/?to=/:account/:zone/rules/transform-rules/modify-response-header |
…46635) Summary: This issue original arose out of bluesky-social/social-app#5100. Copying the description (with my general understanding of the problem) from the patch PR to here as well. There's a crash that comes up in the following, pretty specific scenario: - Have a response that has an empty body - Do not include a `content-type` header in the response - Set the `x-content-type-options` header to `nosniff` RN handles the response for a request in this block of code: https://github.com/facebook/react-native/blob/303e0ed7641409acf2d852c077f6be426afd7a0c/packages/react-native/Libraries/Blob/RCTBlobManager.mm#L314-L326 Here, we see that values of `nil` - which `[response MIMEType]` will return when no `content-type` is provided in the response and the actual type cannot be determined (https://developer.apple.com/documentation/foundation/nsurlresponse/1411613-mimetype) - gets converted to `NSNull` by `RCTNullIfNil`. When we get back over to `readAsDataURL`, we see that we grab the type from the dictionary and check if its `nil` before calling `length` on the string. https://github.com/facebook/react-native/blob/303e0ed7641409acf2d852c077f6be426afd7a0c/packages/react-native/Libraries/Blob/RCTFileReaderModule.mm#L74-L77 However, this check is dubious, because the value will never actually be `nil`. It will always either be `NSString` or `NSNull` because of the `RCTNullIfNil` call made above and `[RCTConvert NSString]` seems to just return the input if it is `NSNull`. ## Changelog: [IOS] [FIXED] - Convert `NSNull` to `nil` before checking `type` in `readAsDataURL` Pull Request resolved: #46635 Test Plan: This is a little awkward to test, but essentially this comes up in the following scenario that is described (and "tested" as being fixed by tweaking) in bluesky-social/social-app#5100. I have personally tested by using Cloudflare rules to add/remove that particular header from an empty body response. You could also test this with a little local web server if you want. ### Before https://github.com/user-attachments/assets/deb86c68-2251-4fef-9705-a1c93584e83e ### After https://github.com/user-attachments/assets/9ffab11b-b2c8-4a83-afd6-0a55fed3ae9b Reviewed By: dmytrorykun Differential Revision: D63381947 Pulled By: cipolleschi fbshipit-source-id: b2b4944d998133611592eed8d112faa6195587bd
…46635) Summary: This issue original arose out of bluesky-social/social-app#5100. Copying the description (with my general understanding of the problem) from the patch PR to here as well. There's a crash that comes up in the following, pretty specific scenario: - Have a response that has an empty body - Do not include a `content-type` header in the response - Set the `x-content-type-options` header to `nosniff` RN handles the response for a request in this block of code: https://github.com/facebook/react-native/blob/303e0ed7641409acf2d852c077f6be426afd7a0c/packages/react-native/Libraries/Blob/RCTBlobManager.mm#L314-L326 Here, we see that values of `nil` - which `[response MIMEType]` will return when no `content-type` is provided in the response and the actual type cannot be determined (https://developer.apple.com/documentation/foundation/nsurlresponse/1411613-mimetype) - gets converted to `NSNull` by `RCTNullIfNil`. When we get back over to `readAsDataURL`, we see that we grab the type from the dictionary and check if its `nil` before calling `length` on the string. https://github.com/facebook/react-native/blob/303e0ed7641409acf2d852c077f6be426afd7a0c/packages/react-native/Libraries/Blob/RCTFileReaderModule.mm#L74-L77 However, this check is dubious, because the value will never actually be `nil`. It will always either be `NSString` or `NSNull` because of the `RCTNullIfNil` call made above and `[RCTConvert NSString]` seems to just return the input if it is `NSNull`. ## Changelog: [IOS] [FIXED] - Convert `NSNull` to `nil` before checking `type` in `readAsDataURL` Pull Request resolved: #46635 Test Plan: This is a little awkward to test, but essentially this comes up in the following scenario that is described (and "tested" as being fixed by tweaking) in bluesky-social/social-app#5100. I have personally tested by using Cloudflare rules to add/remove that particular header from an empty body response. You could also test this with a little local web server if you want. ### Before https://github.com/user-attachments/assets/deb86c68-2251-4fef-9705-a1c93584e83e ### After https://github.com/user-attachments/assets/9ffab11b-b2c8-4a83-afd6-0a55fed3ae9b Reviewed By: dmytrorykun Differential Revision: D63381947 Pulled By: cipolleschi fbshipit-source-id: b2b4944d998133611592eed8d112faa6195587bd
…46635) Summary: This issue original arose out of bluesky-social/social-app#5100. Copying the description (with my general understanding of the problem) from the patch PR to here as well. There's a crash that comes up in the following, pretty specific scenario: - Have a response that has an empty body - Do not include a `content-type` header in the response - Set the `x-content-type-options` header to `nosniff` RN handles the response for a request in this block of code: https://github.com/facebook/react-native/blob/303e0ed7641409acf2d852c077f6be426afd7a0c/packages/react-native/Libraries/Blob/RCTBlobManager.mm#L314-L326 Here, we see that values of `nil` - which `[response MIMEType]` will return when no `content-type` is provided in the response and the actual type cannot be determined (https://developer.apple.com/documentation/foundation/nsurlresponse/1411613-mimetype) - gets converted to `NSNull` by `RCTNullIfNil`. When we get back over to `readAsDataURL`, we see that we grab the type from the dictionary and check if its `nil` before calling `length` on the string. https://github.com/facebook/react-native/blob/303e0ed7641409acf2d852c077f6be426afd7a0c/packages/react-native/Libraries/Blob/RCTFileReaderModule.mm#L74-L77 However, this check is dubious, because the value will never actually be `nil`. It will always either be `NSString` or `NSNull` because of the `RCTNullIfNil` call made above and `[RCTConvert NSString]` seems to just return the input if it is `NSNull`. ## Changelog: [IOS] [FIXED] - Convert `NSNull` to `nil` before checking `type` in `readAsDataURL` Pull Request resolved: #46635 Test Plan: This is a little awkward to test, but essentially this comes up in the following scenario that is described (and "tested" as being fixed by tweaking) in bluesky-social/social-app#5100. I have personally tested by using Cloudflare rules to add/remove that particular header from an empty body response. You could also test this with a little local web server if you want. ### Before https://github.com/user-attachments/assets/deb86c68-2251-4fef-9705-a1c93584e83e ### After https://github.com/user-attachments/assets/9ffab11b-b2c8-4a83-afd6-0a55fed3ae9b Reviewed By: dmytrorykun Differential Revision: D63381947 Pulled By: cipolleschi fbshipit-source-id: b2b4944d998133611592eed8d112faa6195587bd
Describe the bug
/subj. no extra actions needed, it crashes as soon as the app is opened when notifications are allowed
crash log: Bluesky-2024-09-03-040430.ips.json
To Reproduce
Expected behavior
it doesn't crash
Details
Additional context
disallowing notifications in ios settings fixes the crash on startup, but it still crashes when opening the notifications tab
The text was updated successfully, but these errors were encountered: