App
App copied to clipboard
[$1000] Address line 1&2 validation error
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Action Performed:
- Go to Settings -> Profile
- Personal details -> Home address
- Add maximum text -> Remove single character and Add Single quote or Double quote
Expected Result:
It should save the single quote or double quote if it’s in text limit
Actual Result:
Address is not saved if using maximum characters and have single/double quote inside
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:
Which of our officially supported platforms is this issue occurring on?
- [ ] Android / native
- [ ] Android / Chrome
- [x] iOS / native
- [x] iOS / Safari
- [ ] MacOS / Chrome / Safari
- [ ] MacOS / Desktop
Version Number: 1.3.1 Reproducible in staging?: y Reproducible in production?: y If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/43996225/232872181-8192fc04-c8e6-4c36-aea8-1a384af156f6.MP4
https://user-images.githubusercontent.com/43996225/232878076-36dd50fc-b494-44e9-b72a-ca2686314878.MP4
Expensify/Expensify Issue URL: Issue reported by: @DinalJivani Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1681765669263719
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~01aa2ce8df43d54a01
- Upwork Job ID: 1649138520691912704
- Last Price Increase: 2023-04-27
Triggered auto assignment to @isabelastisser (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
Bug0 Triage Checklist (Main S/O)
- [x] This "bug" occurs on a supported platform (ensure
Platforms
in OP are ✅) - [x] This bug is not a duplicate report (check E/App issues and #expensify-bugs)
- If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
- [x] This bug is reproducible using the reproduction steps in the OP. S/O
- If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
- If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
- [x] This issue is filled out as thoroughly and clearly as possible
- Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
- [x] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync
Job added to Upwork: https://www.upwork.com/jobs/~01aa2ce8df43d54a01
Current assignee @isabelastisser is eligible for the External assigner, not assigning anyone new.
Triggered auto assignment to Contributor-plus team member for initial proposal review - @eVoloshchak (External
)
Triggered auto assignment to @tylerkaraszewski (External
), see https://stackoverflow.com/c/expensify/questions/7972 for more details.
Not overdue.
Proposal
Please re-state the problem that we are trying to solve in this issue.
Unable to save Address line 1 & 2 if the last character is “
.
What is the root cause of that problem?
The root cause is
- Characters such as
“
are not in the ASCII range from 32 to 126, these characters are stored with their Unicode which is a way of representing the character as a sequence of hexadecimal values that can be stored and transmitted using ASCII - This issue occurs only where
“
are smart quotes and not normal '"'. (This can happen on any device regardless of the OS. iOS has smart quotes inbuilt but for other platforms if we add smart quote as last character the field update will still fail . - This bug is not only limited to address field. It is present across the board for most of the fields.
- This is happening mainly because special characters are first processed as Unicode i.e hexadecimal values and then stored and this is leading to increased field character limit in the BE.
What changes do you think we should make in order to solve the problem?
FE change
- We can have a function that takes a string, removes any characters that are not within the ASCII range of 32 to 126, replaces those characters with their Unicode escape sequence, and returns the length of the final string and we ensure that the final length after replacement is less than 50 characters and not characters characters as there is character limit in the backend and non ASCII are stored as Unicode which has more characters than expected.
OR BE change
- Create larger field size limits in the BE. Say if the limit in FE is 50 the BE character field limit should be around 150.
What alternative solutions did you explore? (Optional)
📣 @shivansh9007! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork. Please follow these steps:
- Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
- Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
- Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>
⚠️ Invalid email. Please make sure to create an Expensify account with this email first here.
Contributor details Your Expensify account email: [email protected] Upwork Profile Link: https://www.upwork.com/freelancers/~01037dac9f01599d4b
✅ Contributor details stored successfully. Thank you for contributing to Expensify!
Proposal
Please re-state the problem that we are trying to solve in this issue.
In IOS devices, we can't save address line1/line2 with single quote or double quote ending + text length is maximum limit characters
What is the root cause of that problem?
In IOS devices, there is feature called Smart quotes
, when it's turned on, it will automatically change straight quotes
to smart quotes
(or curly quotes).
I don't really now how it's handled in BE side, if we send address line 1/line 2 with single smart quote or double smart quote ending + text length is maximum limit characters (like we saw in the recording issue). The API will return error:
What changes do you think we should make in order to solve the problem?
To align with other platform like Web/Android, we can disable smart quotes
in address line1. To do it, we can pass textInput prop: autoCorrect: false
to this line. I think it makes sense if we disable autoCorrect
here, because:
- it's an autocomplete field and we already disable autoComplete there.
- Users don't really need
smart quotes
in this case.
What alternative solutions did you explore? (Optional)
- Option 1: We can verify this issue in BE side why it's return invalid input parameter in this case.
- Option 2: In case we don't want to disable
autoCorrect
here, we can update the onInputChange callback so that it replaces smart quotes by straight quotes.
Bug is not getting reproduced after new update, https://drive.google.com/file/d/1h85QexXIQqK4sw0lbGgZ_sU_gNzQQDnf/view?usp=share_link
@kaushiktd the issue is with smart quotes and not normal quotes. The quotes in your recording are normal quotes. Its " in your recordings and the issue is with “
@tylerkaraszewski, @eVoloshchak, @isabelastisser Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@tylerkaraszewski @eVoloshchak:
https://github.com/Expensify/App/issues/17619#issuecomment-1519473517
Can I close this issue since it seems like it's fixed?
@isabelastisser the issue still persists. I have added the possible solutions as well.
@eVoloshchak are we still reviewing the proposals? Should we move forward with one?
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
We could implement a function that would escape characters and return the true length, but that would mean that
- the number of individual characters the user can enter is different depending on the symbols
- we'll need additional logic to strip characters, which could cause flickering problems, while currently we use a simple
maxLength
Disabling smart quotes as @hoangzinh proposed isn't ideal, since it's possible to manually paste a curly quote, plus there still could be issues with other symbols that aren't in ASCII range from 32 to 126.
I think @shivansh9007's alternative solution is the best and simplest approach we could take
Create larger field size limits in the BE. Say if the limit in FE is 50 the BE character field limit should be around 150.
@tylerkaraszewski, what are your thoughts?
Not overdue, awaiting for @tylerkaraszewski's opinion
We should count characters, rather than bytes in the input string, and allow 50 input characters, not 50 escaped characters. Docs on string.length explain how to do this already.
We may need to update the backend to accept longer strings as well? I haven't verified whether this needs to be done, but it's an easy change.
@tylerkaraszewski the 50 character check is already present in the FE. According to the API response I see the BE being a bottle neck. Could you guide on how the BE is setup(I have a basic idea after reading the readme, just need few more inputs). Just curious to learn about it and contribute.
The error is thrown here: https://github.com/Expensify/Web-Expensify/blob/main/lib/PersonalDetailsAPI.php#L687
I know you won't be able to see that. I'll have to change this to internal
and I can make the fix.
Current assignee @eVoloshchak is eligible for the Internal assigner, not assigning anyone new.
Issue not reproducible during KI retests. (First week)
@tylerkaraszewski @eVoloshchak @isabelastisser this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
@tylerkaraszewski @eVoloshchak @isabelastisser this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
Not overdue, internal!