Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixes blankArea-for-corruptedPDF #34302

Closed

Conversation

ishpaul777
Copy link
Contributor

@ishpaul777 ishpaul777 commented Jan 10, 2024

Details

WIP will add later...

Fixed Issues

$ #32109
PROPOSAL: #32109 (comment)

Tests

  • Verify that no errors appear in the JS console
  1. Navigate to https://staging.new.expensify.com/
  2. Log in
  3. Upload a corrupted PDF to any conversation
  4. Verify No blank space in chat area while loading the pdf file
  5. Verify if the pdf fails to load it falls back to default attachment view
Screenshot 2024-01-22 at 9 30 31 PM

Offline tests

QA Steps

  • Verify that no errors appear in the JS console
  1. Navigate to https://staging.new.expensify.com/
  2. Log in
  3. Upload a corrupted PDF to any conversation
  4. Verify No blank space in chat area while loading the pdf file
  5. Verify if the pdf fails to load it falls back to default attachment view
Screenshot 2024-01-22 at 9 30 31 PM

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for the expected offline behavior in the Offline steps section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
    • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • Android: Native
    • Android: mWeb Chrome
    • iOS: Native
    • iOS: mWeb Safari
    • MacOS: Chrome / Safari
    • MacOS: Desktop
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • I verified that if a function's arguments changed that all usages have also been updated correctly
  • If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
  • If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
  • If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
  • If the PR modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label so the design team can review the changes.
  • If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
Record_2024-02-07-17-20-44.mp4
Android: mWeb Chrome
VIDEO-2024-02-18-03-04-16.mp4
iOS: Native
Screen.Recording.2024-01-22.at.9.09.30.PM-1.mov
iOS: mWeb Safari
Screen.Recording.2024-01-22.at.9.20.28.PM-1.mov
MacOS: Chrome / Safari
Screen.Recording.2024-01-22.at.9.23.15.PM-1.mov
MacOS: Desktop
Screen.Recording.2024-01-22.at.9.35.23.PM-1.mov

@ishpaul777 ishpaul777 changed the title fix v1 fixes #32109 Jan 10, 2024
@ishpaul777 ishpaul777 changed the title fixes #32109 fixes blankArea-for-corruptedPDF Jan 10, 2024
src/styles/index.ts Outdated Show resolved Hide resolved
@ishpaul777 ishpaul777 marked this pull request as ready for review January 24, 2024 13:03
@ishpaul777 ishpaul777 requested a review from a team as a code owner January 24, 2024 13:03
@melvin-bot melvin-bot bot requested review from parasharrajat and removed request for a team January 24, 2024 13:03
Copy link

melvin-bot bot commented Jan 24, 2024

@parasharrajat 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]

@ishpaul777
Copy link
Contributor Author

ishpaul777 commented Jan 24, 2024

@parasharrajat I'll take care of the remaining checklist in a while, Can you proceed with the code review in mean time if you get the chance. Thanks!

@ishpaul777 ishpaul777 force-pushed the fix/blankArea-for-corruptedPDF branch from 183d11f to a712f60 Compare January 24, 2024 13:10
@parasharrajat
Copy link
Member

Please don't do force pushes. We prefer merge commits.

@ishpaul777
Copy link
Contributor Author

ishpaul777 commented Jan 24, 2024

Actually. i pushed a unsigned commit by mistake, the way i know rectify this currently is:

  1. soft reset unsigned commits
  2. Sign commits and then force push the sign commits

Let me know if there's a better way 🙇‍♂️

Copy link
Member

@parasharrajat parasharrajat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of initial requests.

src/components/Attachments/AttachmentView/index.js Outdated Show resolved Hide resolved
src/components/Attachments/AttachmentView/index.js Outdated Show resolved Hide resolved
src/components/Attachments/AttachmentView/index.js Outdated Show resolved Hide resolved
src/components/PDFView/WebPDFDocument.js Outdated Show resolved Hide resolved
@ishpaul777
Copy link
Contributor Author

ishpaul777 commented Jan 25, 2024

@parasharrajat Please hold your review found some unaccounted major issues on android

@ishpaul777
Copy link
Contributor Author

@parasharrajat I am facing this bug https://expensify.slack.com/archives/C049HHMV9SM/p1706234706816449 on main, blocking me to test the android Can you confirm if this is reproducible for you too?

@ishpaul777
Copy link
Contributor Author

still held on this issue #35808

@ishpaul777
Copy link
Contributor Author

ishpaul777 commented Feb 7, 2024

@parasharrajat Can you check issue should be resolved, also if you are satisfied with response of above review comments can i mark them as resolved?

@ishpaul777
Copy link
Contributor Author

@parasharrajat friendly bump!

@parasharrajat
Copy link
Member

Back on this PR. Catching up with details. I will have an update by tomorrow.

@ishpaul777
Copy link
Contributor Author

merged main but not yet tested (going offline for today 😴

@ishpaul777
Copy link
Contributor Author

There are conflicts i'll resolve them when i got chance asap. (not able to priortize today sorry)

@parasharrajat
Copy link
Member

Currently, I am not getting a good gut feeling about the code. My mind says that we should refactor this.

@ishpaul777
Copy link
Contributor Author

ishpaul777 commented Mar 1, 2024

Currently, I am not getting a good gut feeling about the code. My mind says that we should refactor this.

What is it that you think needs a change, i agree the changes seems a little messy than i expected initially but i think evey change is important

@ishpaul777
Copy link
Contributor Author

Solution is still the same as proposed initially:

  • We have the loading indicator outside the Pdfview and when loading in progress set pdf view invisible so no extra space is visible
  • incase the pdf fails to load, we have a fallbackcomponent passed as prop from upstream

@parasharrajat
Copy link
Member

I will spend some time looking at the code from a different perspective and let you know.

Comment on lines 167 to 172
{/* We are rendering the loading indicator here because we are invisbly rendering the PDF component to validate if it is not corrupted */}
{shouldShowLoadingIndicator && isUsedAsMessageAttachment && (
<View style={[themeStyles.chatItemAttachmentPlaceholder, themeStyles.bgTransparent, StyleUtils.getWidthAndHeightStyle(200, 200)]}>
<FullScreenLoadingIndicator style={[themeStyles.opacity1, themeStyles.bgTransparent]} />
</View>
)}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I am still unsure why we have to load the PDF invisibly. I know you have answered this before but can you please explain this again? The comment above does not explain anything moreover creates more confusion.

  • What is the issue?
  • How does this solve that issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'll adress this concern after the refactoring 🙇‍♂️ if its still valid

Comment on lines 190 to 204
<AttachmentViewPdf
source={source}
file={file}
isFocused={isFocused}
isAuthTokenRequired={isAuthTokenRequired}
encryptedSourceUrl={encryptedSourceUrl}
onPress={onPress}
onToggleKeyboard={onToggleKeyboard}
onLoadComplete={() => !loadComplete && setLoadComplete(true)}
errorLabelStyles={isUsedInAttachmentModal ? [styles.textLabel, styles.textLarge] : [styles.cursorAuto]}
style={isUsedInAttachmentModal ? styles.imageModalPDF : styles.flex1}
isUsedInCarousel={isUsedInCarousel}
renderFallbackAttachmentView={renderFallbackAttachmentView}
isUsedInAttachmentModal={isUsedInAttachmentModal}
/>
Copy link
Member

@parasharrajat parasharrajat Mar 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After giving a deep thought, I think it will be much better to render the fallback UI here in this component by detecting the error. This is already happening at the last thing at the component. let's try to hoist the error state till this component via callback onError.

We should disable the error UI in the PDFView completely. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will save us from making a lot of unnecessary changes like.

  • AttachmentViewPdf/index.android.js

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like a very good idea, i'll spend some time refactoring later today or tomorrow for sure 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you.

@parasharrajat
Copy link
Member

@ishpaul777 Any updates?

@ishpaul777
Copy link
Contributor Author

Srry no update yet, i'll provide a update tommorrow I really apologize for delay

@parasharrajat
Copy link
Member

No problem.

@ishpaul777
Copy link
Contributor Author

ishpaul777 commented Mar 6, 2024

@parasharrajat I just came across a issue closed a week ago #34601, which seems to conflict for what we are doin here, it suggests the expected that if a pdf fails to load it should show the placeholder image, it seems you were also involved in the issue so do you think we should do the same here? asking becuase if follow this expected behaviour we will not have touch any other unncessary file and not need change AUTOSCROLL_TO_TOP_THRESHOLD

Screenshot 2024-03-07 at 4 11 32 AM

@parasharrajat
Copy link
Member

parasharrajat commented Mar 7, 2024

That PR adds a fallback when an image or thumbnail fails to load. But this is interesting.

We have two conflicting behaviors. Let's take a pause here and go back to discussing the solution. Do you mind raising this on slack or initiating a new discussion on the issue and tagging the design team as well?

@ishpaul777
Copy link
Contributor Author

ishpaul777 commented Mar 8, 2024

i'll bring this to discussion once i have some bandwidth to actively work on this one, hope you understand 🙇

A quick update i have refactored locally based on your idea here #34302 (comment) and it works 🎉

what's left is to decide on what's the expected behaviour once the Pdf fails to load whether to show default view or failed thumbnail state

@parasharrajat
Copy link
Member

A quick update i have refactored locally based on your idea here #34302 (comment) and it works 🎉

Can you please push the changes @ishpaul777 ?

@ishpaul777
Copy link
Contributor Author

ishpaul777 commented Mar 8, 2024

Sorry i missed the ping, pushing all the changes with the failed state thumbnail and defaukt attachement view both for now then we'll get the approval from design team on which way to go

@ishpaul777 ishpaul777 closed this Mar 8, 2024
@ishpaul777 ishpaul777 force-pushed the fix/blankArea-for-corruptedPDF branch from 97ce0a8 to 5404018 Compare March 8, 2024 22:00
@ishpaul777
Copy link
Contributor Author

New PR #38010, conflicts was brutal 😭

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants