BUG - Sev 3 - Android - Attaching file with camera, on screen cancel button is not functional when camera is open

[DJUltraTom]

What happened?

In secure messaging when in photo mode (camera) the on screen "cancel"(x) button is non functional tapping it does nothing. With talkback on the button is read outloud but is still non functional

Specs:

• Device: pixel 4A
• OS: Android 13
• User Account: +226
• Accessibility State: N/A (issue occurs on both)

Steps to Reproduce

• on an account with secure messaging, navigate through flow to attach an image
• select "camera
• observe "X" button in the upper left of the screen is non functional

Desired behavior

All buttons appearing on screen should be functional

Acceptance Criteria

TBD

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See [Bug Tracking](https://department-of-veterans-affairs.github.io/va-mobile-app/docs/QA#issue-severity) for details on severity levels

• Impact: Low
• Frequency: Low

• 3 - Low

Linked to Story

Screen shot(s) and additional information

Full JSON response for services related to issue (expand/collapse)

Ticket Checklist

• [ ] Steps to reproduce are defined
• [ ] Desired behavior is added
• [ ] Labels added (front-end, back-end, relevant feature, accessibility, etc)
• [ ] Estimate of 1 added (for front-end tickets)
• [ ] Added either to the relevant feature epic (if found during new feature implementation), or the bug epic

[Sparowhawk]

@DJUltraTom that is a native screen meaning we have no control over it.

Can you please provide a video of it to confirm as I tried that and the x button was functional when I did it.

[bischoffa]

@DJUltraTom can you review Dylan's question above?

[DJUltraTom]

Attached video, when you see the camera open and the image shaking thats me tapping the "X" with no result, eventually I use the HW back button. I am able to open the camera app inside of chrome (visual search) and all on screen options function. Inside the eBay and Nike app it also works fine, When I open the camera function through sms/text I get the same behavior as when using our app. Meaning its probably a "tom only" or a pixel 4A issue. Private Zenhub Video

[Sparowhawk]

@bischoffa @DJUltraTom this is a native component created by our react-native-image-picker dependency

Looking over the issues in the github there wasn't any mention of it so I created this bug report

https://github.com/react-native-image-picker/react-native-image-picker/issues/2244

From what you are saying it seems like it may potentially be a phone/phone OS issue. I don't believe this bug I created will get resolved as it takes quite sometime for these issues to get resolved from the looks. of it and it looks like they just invoke the native picker with some flags and likely have little control over that button as well.

[Sparowhawk]

To elaborate more this is how the code is structured for that screen

1. our code(launchCamera call function)
2. react-native-image-picker library(creates the intent and adds the needed flags and then passes it to the native picker/code(we potentially can fix this one if this is where the bug is, but unfortunately it doesn't look like it is)
3. native code that handles the activity(we can't fix this one, which is a bummer as this is where the problem would be)

I believe the issue may be an old android OS version and the phone needs updating

[Sparowhawk]

Last thing to note is that this dependency is pretty far out of date, but they do have some game breaking changes that will need to be addressed when we do get to upgrading it. I was going to tackle updating several of the major versions of several of our dependencies as some of my post planning adds when I next have some time and hopefully it resolves this

[bischoffa]

@Sparowhawk is this impacting every feature in the app using the phone to attach a file or only specific ones? Asking to identify which team will own this Health / Global

[Sparowhawk]

@bischoffa this affects everything however it is pretty much out of our hands is waiting on the dependency to be updated and hopefully fixed on their end. So this could be moved to blocked with blocked external label and whoever ends up upgrading the dependency will take care of this be it health or global

[bischoffa]

@Sparowhawk can you add more detail as to what the external blocker is ? Above it in comments I thought it was related to react native dependencies that engineering needs to work on vs waiting for an external team.

[timwright12]

@Sparowhawk ping on this for @bischoffa 's last comment

[TKDickson]

changing from global to health, as the camera is only used in health (messaging) and benefits (claims file request) features.

[Sparowhawk]

@bischoffa The blocker is that the library we use react-native-image-picker hasn't fixed this issue internally yet. So until they do this is currently blocked.

https://github.com/react-native-image-picker/react-native-image-picker/issues/2244

[TKDickson]

@Sparowhawk do you know - after the library fixes their stuff, will we need to change our code or not? (Or is this a "until we know how they'll fix it, it's unclear if we'll need to change our code" situation?)

[Sparowhawk]

@TKDickson if/when the library updates it should be as simple as updating the dependency. If we have to switch to a different library then it is dependent on what the implementation would be.

[ala-yna]

@Sparowhawk, any updates on this one?

[TKDickson]

Previously we didn't have official guidance on when to close tickets as not fixing, but we do now.

Externally-owned bugs (ones we can't fix because we don't own the code) should be closed after reporting to the responsible team (Dylan's comment above). So closing now.