fix: Update second Allow location access modal on web #51709
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
melvin-bot
bot
requested review from
alitoshmatov
and removed request for
a team
|
@alitoshmatov Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
4 tasks
|
@truph01 After not allowing location access the modal is not appearing in second submit. Maybe it is because I am in newer version of chrome where it offer different options for choosing allowing access Screen.Recording.2024-11-03.at.9.37.05.PM.mov |
|
@alitoshmatov Ah, I see it. Do you think it's actually related to our PR, given that we're focusing on updating the modal (title, subtitle, buttons) rather than modifying the logic for when it should be displayed? |
I guess not, but would be great if we considered this possibility as well. |
|
@truph01 I am also noticing that in your ios safari recording, the modal is shown second time you submit a scan but clicking continue does not show native location permission modal. In my simulator after I reject location first time, no modal is shown in second scan request permission-safari.mp4 |
|
In ios also the modal is shown only in first scan request. After rejecting native permission modal first time submitting second invoice request is not triggering modal permission-ios.mp4 |
|
That is three places – Ios native, Ios safari, Mac chrome which shows only first modal not the second modal with "Got it" button or "Settings" button. If this is accepted behavior we should reconsider testing steps to prevent further confusion |
|
@alitoshmatov We are encountering different behavior in Chrome, maybe because of the Chrome version (Here is from @alitoshmatov and the one in the screen recording section is from my side). So, I wonder how I can write the test steps properly in Chrome? cc @Julesssss |
I think that sounds like our logic that only prompts the user for location once every 7 days? (each client tracks this seprerately) I agree we need to have well defined test steps. After retesting with the 7 day throttle disabled lets see if our experiences match. To help with this I branched from these changes HERE with that logic removed, and test builds are currently being built...
Also, this screenshot is incorrect for mobile, can you change it to the native permission modal so that QA aren't confused. |
@alitoshmatov The behaviors in here, here and here are tested when disabling the 7 day throttle, no? If no, could you help try again? |
|
Same result is happening, I think branched test PR does not have correct changes - const shouldStartLocationPermissionFlow =
- !lastLocationPermissionPrompt ||
- (DateUtils.isValidDateString(lastLocationPermissionPrompt ?? '') &&
- DateUtils.getDifferenceInDaysFromNow(new Date(lastLocationPermissionPrompt ?? '')) > CONST.IOU.LOCATION_PERMISSION_PROMPT_THRESHOLD_DAYS);
+ const shouldStartLocationPermissionFlow = !lastLocationPermissionPrompt;The condition is not what we expect here. |
|
I think Also, @truph01 if there were 7 day throttle how were you able to test your PR and produce expected results(two permission modals sequentially) since it is clear that chrome version was not playing any role here. |
I forgot to mention that I also temporarily removed the 7-day throttle as a hard-coded adjustment for testing purposes. |
|
@alitoshmatov Could you give me the Chrome version from your side? I updated the version but cannot reproduce like this one:
|
|
Now after setting
location-android.movlocation-ios.mp4 |
@truph01 As I said here, branched PR by @Julesssss had wrong conditions to ignore 7 day period that is why I got the same result. Now after correctly removing 7 day throttle issue is solved in web chrome. |
|
Just a note, iOS only lets us prompt once for location permission if users says NO. But Android lets us prompt twice. So there is a slight difference. Android
This is almost correct I think: 1st attempt - 'Dont' allow'
2nd attempt - 'Dont' allow'
iOS
I think this is expected. But that's not what I see in your video -- I see the native app: 
|
|
@Julesssss Sorry uploaded wrong file, here is ios safari version location-safari.MP4 |
|
Thanks @alitoshmatov
Cool so this seems like the last thing to fix. We should be showing the updated text here for web @truph01 the test steps (and desired behaviour) is that we show this different text for web on the second attempt, do you think maybe a recent change broken that? Once that's showing again I think we are done here
|
Julesssss
reviewed
Nov 13, 2024
| @@ -81,15 +81,22 @@ function LocationPermissionModal({startPermissionFlow, resetPermissionFlow, onDe | |||
| setShowModal(false); | |||
| resetPermissionFlow(); | |||
| }; | |||
|
|
|||
| const locationErrorMessage = useMemo(() => (isWeb ? 'receipt.allowLocationFromSetting' : 'receipt.locationErrorMessage'), [isWeb]); | |||
There was a problem hiding this comment.
We don't seem to show this message on web with the current changes
|
@alitoshmatov The behavior in safari (both MacOS and IOS) is:
In Chrome, we check whether the pre-check for the current permission status returns "Blocked." This allows us to determine if the previous prompt was rejected. If it was, we display the second "Allow location access" modal. In Safari, however, the pre-check for the current permission status always returns "Denied," which makes it impossible to determine if the previous prompt was rejected. Consequently, it becomes difficult to decide when to display the second "Allow location access" modal. As a result, Safari always shows the first modal. This discrepancy leads to the observed behavior.
|
I see. I think everything looks good, @truph01 please update QA steps for each case in OP. I will complete the checklist |
|
@alitoshmatov I updated test cases for Chrome and Safari. |
Reviewer Checklist
Screenshots/VideosAndroid: Nativelocation-android.movAndroid: mWeb Chromelocation-mweb.moviOS: Nativelocation-ios.mp4iOS: mWeb Safarilocation-safari.MP4MacOS: Chrome / Safarilocation-web.movMacOS: Desktoplocation-desktop.mov |
|
🚧 @Julesssss has triggered a test build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, Desktop, and Web. Happy testing! 🧪🧪 |
Julesssss
approved these changes
Nov 19, 2024
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
github-actions
bot
added
the
DeployBlockerCash
Performance Comparison Report 📊Significant Changes To Duration
Show details
Meaningless Changes To DurationShow entries
Show details
|
|
@Expensify/mobile-deployers 📣 Please look into this performance regression as it's a deploy blocker. |
Julesssss
removed
the
DeployBlockerCash
|
This PR didn't reduce perf by 19% -- we made simple modifications to the location permission flow for web. |
|
yes, thats a false positive, sorry |
65 tasks
|
🚀 Deployed to staging by https://github.com/Julesssss in version: 9.0.65-0 🚀
|
|
🚀 Deployed to production by https://github.com/chiragsalian in version: 9.0.65-5 🚀
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation of Change
Fixed Issues
$ #50601
PROPOSAL: #50601 (comment)
Tests
Prerequisite for all test cases:
Update code:
App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx
Lines 591 to 601 in 61ea52b
to remove the 7 days period.
Test 1: For [Chrome]
Choose "Block".
FAB > Submit expense > Scan > Upload receipt.
In confirmation page, click "Submit expense". Verify the below modal is displayed:
Test 2: For [Safari]
Choose "Don't allow".
FAB > Submit expense > Scan > Upload receipt.
In confirmation page, click "Submit expense". Verify the below modal is displayed:
Test 3: For Android/IOS app
Choose "Don't Allow".
FAB > Submit expense > Scan > Upload receipt.
In confirmation page, click "Submit expense". Verify the below modal is displayed:
Offline tests
QA Steps
Test 1: For [Chrome]
Choose "Block".
7 days later: FAB > Submit expense > Scan > Upload receipt.
In confirmation page, click "Submit expense". Verify the below modal is displayed:
Test 2: For [Safari]
Choose "Don't allow".
7 days later: FAB > Submit expense > Scan > Upload receipt.
In confirmation page, click "Submit expense". Verify the below modal is displayed:
Test 3: For Android/IOS app (This PR does not change the Android/IOS logic, so just add the test steps to make sure it works as it is)
Choose "Don't Allow".
7 days later: FAB > Submit expense > Scan > Upload receipt.
In confirmation page, click "Submit expense". Verify the below modal is displayed:
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
output.mp4
Android: mWeb Chrome
Screen.Recording.2024-10-30.at.08.47.54.mov
iOS: Native
Screen.Recording.2024-10-30.at.08.41.50.mov
iOS: mWeb Safari
Screen.Recording.2024-10-30.at.09.14.04.mov
MacOS: Chrome / Safari
output.mp4
MacOS: Desktop
Screen.Recording.2024-10-30.at.09.11.28.mov