Skip to content

Restore auto-resizing of the code console input prompts #17819

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Restore auto-resizing of the code console input prompts #17819

wants to merge 6 commits into from

Conversation

jtpio
Copy link
Member

@jtpio jtpio commented Aug 26, 2025 •
edited
Loading

References

Fixes #17597

Also reported in:

This was reported as a regression in 4.4 by some users, so looking into fixing it for 4.5.

Code changes

Use a ResizeObserver to check changes in height for the input prompt cell to automatically set the split relative sizes.

This only applies when promptCellPosition is set to bottom or top.

User-facing changes

This PR now brings the following improvements:

  • Automatically resize the input prompt grows vertically (only applies to bottom and top)
  • If the user has not manually resized the split, clearing the code (or removing some lines) or executing it shrinks the input prompt down
  • The input prompt keeps its full size if the prompt cell position is changed
  • The manual resize flag is cleared when the prompt cell position changes
jupyterlab-code-console-prompt-resize.mp4

Backwards-incompatible changes

None

@jupyterlab-probot jupyterlab-probot
Copy link

Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link: Binder

@jtpio jtpio added this to the 4.5.0 milestone Aug 26, 2025
@jtpio jtpio added enhancement tag:Regression Behavior that had been broken, was fixed, and is broken again labels Aug 26, 2025
@jtpio jtpio changed the title Auto-resize the code console input prompts Restore auto-resizing of the code console input prompts Aug 26, 2025
@jtpio jtpio mentioned this pull request Aug 26, 2025
Open
@jtpio
Copy link
Member Author

jtpio commented Aug 26, 2025

Do people think this should be put behind a setting, so users can opt-out of the new behavior?

@jtpio
Copy link
Member Author

jtpio commented Aug 26, 2025

Do people think this should be put behind a setting, so users can opt-out of the new behavior?

Thinking more about this, it's probably fine without the setting, as the behavior in this PR feels a little bit more natural in the end.

@jtpio
Copy link
Member Author

jtpio commented Aug 27, 2025

Made a couple of tweaks to the UX. Overall this PR now brings the following improvements:

  • Automatically resize the input prompt grows vertically (only applies to bottom and top)
  • If the user has not manually resized the split, clearing the code (or removing some lines) or executing it shrinks the input prompt down
  • The input prompt keeps its full size if the prompt cell position is changed
  • The manual resize flag is cleared when the prompt cell position changes
jupyterlab-code-console-prompt-resize.mp4

@jtpio
Copy link
Member Author

jtpio commented Aug 27, 2025

The failing UI tests are tracked in #17820

image

Otherwise, marking as ready, so folks can try the UX (hopefully Binder will be back soon).

@jtpio jtpio marked this pull request as ready for review August 27, 2025 08:17
@jtpio jtpio mentioned this pull request Aug 27, 2025
Open
agriyakhetarpal
agriyakhetarpal approved these changes Aug 27, 2025
View reviewed changes
Copy link

@agriyakhetarpal agriyakhetarpal left a comment

Choose a reason for hiding this comment

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

Thanks, @jtpio! Confirming that this looks good and works well from my end 👍🏻 Besides the NumPy website PR, I also highlighted this issue in jupyterlite/jupyterlite-sphinx#290, where I had previously attempted to (incorrectly) fix the problem in the JupyterLite codebase.

Do people think this should be put behind a setting, so users can opt-out of the new behavior?

Thinking more about this, it's probably fine without the setting, as the behavior in this PR feels a little bit more natural in the end.

This was reported as a regression in 4.4 by some users, so looking into fixing it for 4.5.

I agree; this PR is definitely a nice restoration of the original behaviour and shouldn't need to be opted out of.

I've also added a few comments below, and I hope they are helpful somewhat:

packages/console/src/widget.ts
return;
}

const remainingHeight = totalHeight - inputHeight;
Copy link

Choose a reason for hiding this comment

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

Hmm, what would happen if inputHeight exceeds totalHeight, i.e., for very tall content? Should we have something like const maxInputHeight = Math.min(inputHeight, totalHeight * 0.8) here, or does SplitPanel clamp negative values to 0?

If yes, we could also consider if we want to refactor this math into a _calculateSizes function or similar, as I think _adjustSplitPanelForInputGrowth alone is doing quite a lot :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Normally it should not be possible for inputHeight to be greater than totalHeight, since totalHeight corresponds to the height of the SplitPanel and the input widget is one of the splits.

packages/console/src/widget.ts
Comment on lines +728 to +740
// Detect height changes
if (promptCell.node) {
this._promptResizeObserver = new ResizeObserver(() => {
if (!this._hasManualResize) {
this._resetInputSize();
}
requestAnimationFrame(() => {
this._adjustSplitPanelForInputGrowth();
});
});
this._promptResizeObserver.observe(promptCell.node);
}

Copy link

Choose a reason for hiding this comment

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

Not sure about any performance considerations or what the previous implementation was like, but would this cause a lot of redraws unless we debounce it?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think the previous implementation was just using flex, so it was offloaded to the browser, but otherwise, yeah, I was thinking about adding some debouncing to this.

The main idea is that we need to catch any change to the height of the prompt cell, which happens most of the time when a user adds a new line.

packages/console/src/widget.ts
@@ -999,6 +1116,8 @@ export class CodeConsole extends Widget {
private _focusedCell: Cell | null = null;
private _translator: ITranslator;
private _splitPanel: SplitPanel;
private _promptResizeObserver: ResizeObserver | null = null;
private _hasManualResize = false;
Copy link

Choose a reason for hiding this comment

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

Suggested change
private _hasManualResize = false;
private _hasManualResize: boolean = false;

Copy link
Member

Choose a reason for hiding this comment

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

^ this is not needed as typescript can infer this type

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@krassowski krassowski krassowski left review comments

+1 more reviewer

@agriyakhetarpal agriyakhetarpal agriyakhetarpal approved these changes

Reviewers whose approvals may not affect merge requirements
Assignees

@jtpio jtpio

Labels
enhancement pkg:console status:Needs Review tag:Regression Behavior that had been broken, was fixed, and is broken again tag:Testing
Projects
PR triage (experimental)
Status: No status
Milestone
4.5.0
Development

Successfully merging this pull request may close these issues.

Restore automatic resizing of the console prompt in Jupyterlab 4.4?
3 participants
@jtpio @krassowski @agriyakhetarpal