fix Fixes the clipping of IFrame when scrollIntoView is triggered

[farhaanbukhsh]

Fixed clipping issue faced when scrollToXBlock is triggered

Issues/Ticket: openedx/openedx-aspects#316

Discussions: Link to any public dicussions about this PR or the design/architecture. Otherwise omit this.

Dependencies: None

Screenshots: Always include screenshots if there is any change to the UI.

Sandbox URL: TBD - sandbox is being provisioned.

Merge deadline: "None" if there's no rush, "ASAP" if it's critical, or provide a specific date if there is one.

Testing instructions:

As mentioned in the ticket.

[openedx-webhooks]

Thanks for the pull request, @farhaanbukhsh!

This repository is currently maintained by @openedx/wg-maintenance-edx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[tecoholic]

@farhaanbukhsh Hi! unfortunately, this doesn't seem to fix the clipping issue yet. Kindly see this recording

Note

Seems like my environment didn't pick up the change. When I tried again a couple of days latter, the issue was resolved as expected. Disregard the rest of the comment.

clipping.mp4

1. Clicking the component on the sidebar scrolls down to the relevant Block.
2. Scrolling back has the header clipped.
3. Interacting with it corrects the rendering.

I understand that scrollBy which runs on step 1 should correct this clipping, by moving the document down by 80px?

---

I think the issue lies in the Iframe's height calculation. In the example below, we can see that the iframe has a height of 2042 while the body element's height is ~2083. I suspected this difference is what makes the scrolling to miscalculate the position of the document.

So, I manually set the height of the iframe to see if that would solve the issue. Interestingly, the document's body height increased as well 😕

Now, I am not sure if that's the issue for sure. Do you think investigating this could lead to a potential solution?

[tecoholic]

@farhaanbukhsh 👍

• I tested this: Verified that the iframe is not clipped when autoscrolling.
• I read through the code
• I checked for accessibility issues
• Includes documentation

I am not sure what changed. I had a hunch, I needed to test this again and this time it worked.

[farhaanbukhsh]

Seems like my environment didn't pick up the change. When I tried again a couple of days latter, the issue was resolved as expected. Disregard the rest of the comment.

@tecoholic That is great to know :), I think and this is what I wanted to add to the PR as well, did you build the assets so I generally exec in the container, lms/cms and run npm run build-dev and npm run postinstall so if you didn't run these. You might not be running the latest code.

Hence, by chance, you have rebuilt the image and started the container that might have led to the code being run the right way.

[tecoholic]

@farhaanbukhsh I am not sure. I remember doing a tutor dev launch after pulling everything, which should have built everything. But I might have switched the branch after the docker context was loaded. So, it might have missed the actual changes. So, this time, I wanted to be sure and ran tutor dev exec web bash and then npm run webpack-watch to make sure I have the latest and it worked :)

[arbrandes]

This looks brittle. I'd be more comfortable approving this if the underlying reason for the clipping were discovered, and the repositioning value, if necessary, were determined programatically. It's possible this could be solved with CSS, if we understood the problem better.

[saraburns1]

I believe I've found the root cause of this @arbrandes @tecoholic - this makes the iFrame size larger than it needs to be which is fine on initial load, but when 'scrollToXBlock' is called, the content within the iFrame gets shifted up and that's why we see the cutoff

it's possible we could do window.scrollBy(0, window.innerHeight*-.02); but i haven't been able to get my environment set up for frontend testing yet (in progress...)

[farhaanbukhsh]

@saraburns1 I can help you test the hypothesis since I think I have the setup.

I wanted to let you know what I discovered if we agitate the UI, it re-renders and it switches to be okay. You can see this happening when the cut screen is rendered if we click around the area the UI renders and it becomes okay.

Hence if we put a timeout and do a scrollBy with any value the UI just re-renders and becomes alright I found this when I was testing this PR after @arbrandes's comment.

What I feel should be a polished solution is , when a postmessage gets to this point the scrollToBlock should just send the document.getElementById(data.payload.locator).top or similar value to the outside IFrame caller which tells the outside scrollbar about how much should it scroll. Because ideally the inside IFrame is configured to be non-scrollable and hence should not be disturbed. Do let me know if I can help you to test or if you have any feedback for the above solution 😄 . cc: @arbrandes @tecoholic @bmtcril

[saraburns1]

@farhaanbukhsh @arbrandes - finally have a solution for this!
#37152
openedx/frontend-app-authoring#2363

We were scrolling the iFrame to the block location which caused the cutoff because the iFrame content was actually slightly larger than the container.
I've changed the scrollToXBlock message to postMessage to the parent which will scroll to the xblock offset + iFrame container offset. This prevents the cutoff but retains the original functionality of auto-scrolling to the selected xblock.

Let me know if there are questions. If those PRs look reasonable, we can close this one

[farhaanbukhsh]

Closing this in favour of the above comment.