fix: fill the fullscreen component editor with the editor

[ihor-romaniuk]

Description

Two component editors do not use the space they are given when expanded to fullscreen. The text and game editors leave a band of empty page between the writing area and the footer. The editor for blocks without a dedicated editor — anything advanced, reached from a direct editor link — shows the block in the top 70% of the modal with empty space beneath it, and a block taller than the modal cannot be reached at all.

Both now fill the modal in fullscreen: the writing area grows with the page, and a block taller than the modal scrolls inside its frame. Neither editor changes at its normal size.

Implementation notes

• Two independent causes, hence two commits.
• LibraryBlock sizes its IFrame to the height the block reports, with a 70vh floor. In a fullscreen modal that is a fixed height inside a fixed-height flex column, so it neither grows into the space nor overflows into a scroll — flexbox shrinks it instead and the modal itself does not scroll. The new fillContainer prop swaps that for a growing flex item, and AdvancedEditor sets it only in fullscreen. It is opt-in because outside a flex parent the item would collapse to the IFrame default of 150px.
• The text editor stack holds two heights of its own: .editor-body carries an h-75 utility, and TinyMCE resolves its height: '100%' once when it is built and keeps that pixel value in an inline style. A definite flex-basis outranks both, which is why the stylesheet needs no !important.
• EditorContainer/index.scss existed but was never imported; it is imported now, and the modal carries an editor-modal class so the rules do not reach every fullscreen Paragon modal in the app.
• .pgn__modal-body-content gets overflow-y: auto because bounding it takes scrolling away from the modal body, and the problem editor is routinely taller than the modal.

Screenshot/Video

#	View	What to check	Before	After
1	Text editor, fullscreen (an HTML component)	The writing area reaches the footer instead of stopping short of it
2	Advanced editor, fullscreen (a poll component)	The block fills the modal instead of leaving a band of empty space below it

Testing

Preconditions: a course with an HTML component, a problem, and any advanced component such as a poll.

1. Open a unit, edit the HTML component, and click the expand icon.
2. Expected: the writing area runs from the toolbar down to the footer, with no empty band above the buttons.
3. Type enough to overflow the area.
4. Expected: it scrolls inside the editor; the footer stays put.
5. Leave fullscreen.
6. Expected: the editor is the size it always was.
7. Edit the problem component and expand it.
8. Expected: the editor still scrolls as a whole and the footer stays visible.
9. Open an advanced component through its editor link, e.g. /authoring/course/<courseId>/editor/poll/<blockId>, and expand it.
10. Expected: the block fills the modal; a block taller than the modal scrolls inside its frame.

Verified locally

Check	Result
Advanced editor, fullscreen	frame grew from 604px to the full 791px available on all four block types from the ticket — scorm, feedback, poll and survey; the gap below it went from 187px to 0
Advanced editor, tall block	at a 450px viewport the frame takes the whole 378px available and the block scrolls inside it; before, flexbox shrank the frame and the modal did not scroll
Text editor, fullscreen	writing area 500px → 697px, empty space below it 206px → 9px, which is the body's own padding
Text editor, normal size	500px, unchanged
Problem editor, fullscreen	content bounded by the body and scrolling inside it, 1954px of content in 697px; footer visible
jest on the editor suites	8 suites, 51 tests
Red/green	reverting the fillContainer line fails exactly the new test
tsc, dprint, oxlint, stylelint	clean
Not verified	One browser at 1440×863. The stylesheet has no test coverage; only the prop is covered by a test.

[openedx-webhooks]

Thanks for the pull request, @ihor-romaniuk!

This repository is currently maintained by @bradenmacdonald.

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.

Details

---

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.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.92%. Comparing base (16e19f1) to head (cc218f8).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3211   +/-   ##
=======================================
  Coverage   95.92%   95.92%           
=======================================
  Files        1397     1397           
  Lines       33581    33587    +6     
  Branches     7947     7951    +4     
=======================================
+ Hits        32214    32220    +6     
  Misses       1308     1308           
  Partials       59       59           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.