It takes more space than its contrainer

[tylerlong]

html,body {
  margin: 0;
  padding: 0;
  border: 0;
  height:100%;
}

#container {
  margin: 0;
  padding: 0;
  border: 0;
  width: 100%;
  height: 100%;
}

When I run a demo, I can see both horizontal and vertical scroll bars. Which means it takes more space than its container which is not ideal.

[alexdima]

@tylerlong

The editor uses container.clientWidth and container.clientHeight as the size. Here is the code for reference: https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/config/elementSizeObserver.ts#L66

As mentioned in #28 you can call editor.layout() to set the editor to the size you desire:

export interface IDimension {
    width:number;
    height:number;
}

export interface ICodeEditor {
    //...
    /**
     * Instructs the editor to remeasure its container. This method should
     * be called when the container of the editor gets resized.
     */
    layout(dimension?:IDimension): void;
    //...
}

This could also be a bug (maybe the assumption to use clientWidth and clientHeight is wrong?), in which case I would appreciate a full HTML example so I can try running it and checking what happens.

[tylerlong]

@alexandrudima Here is a full example: https://tylerlong.github.io/monaco-test/editor/ . Source code: https://github.com/tylerlong/monaco-test/tree/gh-pages/editor

I think it should contain no scrollbars out-of-box without I call editor.layout(). It is a bug if it can't layout itself properly during initialization.

I don't see any issues to use clientWidth and clientHeight. But maybe the editor has margins.

[ptyork]

@tylerlong, it's a bunch of hidden (but not quite invisible) stuff in their "overflowingContentWidgets" div. The actual editor is the correct height, though. Just set your #container to overflow: hidden and it fixes the problem (I think). I had the same issue with trying to do the 100% height bit with Ace, as well.

@alexandrudima, any reason for the overflow: visible in the .monaco-editor container? Changing that to hidden also fixes the issue, but I'm not sure what other repercussions that might entail.

[MatthewOverall]

I ran into this problem and it decided to see how VSCode handles it and found the following style

.monaco-workbench>.editor>.content .editor-container {
  height: calc(100% - 35px);
}

So, try adding this to your container, it resolved my problem. You can obviously drop the leading selectors...

.editor-container {
  height: calc(100% - 35px);
}

or 

#container {
  margin: 0;
  padding: 0;
  border: 0;
  width: 100%;
  height: calc(100% - 35px);
}

[boljen]

I've come across a similar bug. The first step was to hide overflow on the editor, as suggested in this thread (.monaco-editor { overflow: hidden; }) There was another issue though; the vertical scroll-bar handle was misaligned.

For some reason the misalignment disappeared after I excluded the foundation-sites css library. It didn't matter in which order this library was loaded, only that it was. (I'm using the most recent one, 6.1.4.)

I also tried including normalize (version shipped with foundation) but that didn't cause any misalignment.

Edit: I narrowed it down to these two rules applied to the global .slider class; https://github.com/zurb/foundation-sites/blob/develop/scss/components/_slider.scss#L24-L25

If you are using foundation-sites, then simply exclude foundation-slider or manually overwrite the slider class for monaco-editor;

.monaco-editor .slider { margin: 0; }

[jannisch]

It seems like the height: calc(100% - 35px) trick from @MatthewOverall doesn't even work any more (I tested it both in Firefox and Chromium).

Numerous elements in .overflowingContentWidgets are causing the issue, deleting the whole node from dom proves this but breaks all dialogs.

I inspected all elements which have any height and found these rules to resize them/ position them diffently so that the gap is removed:

.monaco-editor .parameter-hints-widget {
  border: 0px;
}
.monaco-editor .parameter-hints-widget .signature {
  padding: 0px;
}
.monaco-editor .suggest-widget {
  border: 0px;
}
.monaco-editor.vs-dark .suggest-widget {
  border: 0px;
}
.monaco-editor .rename-box {
  top: 0;
}

With those applied, everything seems to work except that obviously some borders are missing in dialogs. Unfortunately I don't know monacos internals (how the whole positioning works) and can't find a connection between the rules at this point to fix the issue.

[jonnermut]

I couldn't get rid of superflous internal scrolling with any of these workarounds - is this ever likely to be fixed?

[tomdale]

@jonnermut Is the issue with superfluous internal scrolling caused by the (on-by-default) scrollBeyondLastLine option? I was also confused about why I couldn't get rid of the scrollbar but I just had to disable this option and I got the auto-expanding-no-scroll behavior I wanted.

    let editor = this.editor = monaco.editor.create(this.element as HTMLElement, {
      model,
      scrollBeyondLastLine: false
    });

[andreujuanc]

scrollBeyondLastLine: false fixed it. But Should it do that?

EDIT: NOPE, did't fix it. Had to overflow: hidden;

[jonnermut]

@tomdale that fixed it for me, thank you very much.

[cloverich]

I think most people here have issue with the vertical scrolling, but my issue was mostly with horizontal scrolling. No matter what size I made the container, it always had a horizontal scrollbar (and was wider than its container). Turned out it was incorrect font-size measurements. This is known and tracked in #392

Using a default font fixed the issue for me. I imagine pre-loading the font would similarly fix the issue but have not tested yet.

[joshmenden]

This is happening for me too on the vertical scroll when in readonly mode -- when I try to type in the editor, the Cannot edit in Readonly mode dialog pops up adding this additional space at the bottom.

[Micka33]

Is the issue with superfluous internal scrolling caused by the (on-by-default) scrollBeyondLastLine option?
For me, scrollBeyondLastLine: false didn't fix anything. Monaco is still taller than its container.

I applied overflow: hidden; to the target container in order to get rid of this scroll.
No idea of the repercussion, It must be a difficult bug as it hasn't been fixed since 2016...

[alelevinas]

+1

[zraineri]

@jannisch Life saver, thanks!

[cyberbeast]

Any fixes for this? I am running into a similar issue with a Flexbox container and the monaco editor takes up more width than the container.

[troy351]

Works for me.

.monaco-editor.rename-box,
.monaco-hover {
  top: 0;
}

[ghost]

The following solution avoids modifying the editor using its class names (which aren't guaranteed to be stable) while respecting the contract that the editor will completely fill the node it mounts on,

<div class="editorContainer">
    <div id="editorMountNode" class="editorMountNode" />
</div>

<style>
  .editorContainer {
    overflow: hidden;
    /* add any necessary sizing, like height/width/flex */
  }
  .editorMountNode {
    height: 100%;
  }
</style>

[hediet]

Closing due to inactivity.

If this bug still applies, please create a new issue. Make sure to select the form for bugs and include a minimal reproducible example. Thanks!