MacOS Dock is Visible when Switching to Fullscreen Renoise

When in fullscreen mode, Renoise for MacOS will sometimes draw the Dock on top of itself, obstructing everything underneath, including some controls.

This main symptom is either permanent, in that the dock never disappears on its own, or temporary, in that the Dock will automatically slide away after 1-2 seconds. What determines its persistence is whether and how the Renoise app is switched to from another app or space.

It’s important to note that showing the Dock in either sense is contrary to expected behavior of fullscreen MacOS apps, which is to not display the Dock after entering fullscreen mode at all except when summoning it deliberately by pulling the mouse cursor below the screen continuously for a period of time.

This is an issue I’ve previously reported in lesser detail and subsequently closed, but it seems to still be present in the current release and appears to derive from Renoise’s fullscreen mode having been implemented in a non-standard way.


  • The Dock is sometimes permanently displayed on top of Renoise when switching to fullscreen mode, making everything underneath the Dock inaccessible.

  • When not displayed permanently, the Dock will sometimes be displayed temporarily for 1-2 seconds before sliding away. In MacOS, it is standard behavior for the Dock to slide away immediately when switching to a fullscreen app, but Renoise sometimes leaves it visible for slightly longer.

  • The Dock is always permanently displayed when switching to fullscreen Renoise from another fullscreen app using the CMD+TAB keyboard combination.

  • The Dock is always permanently displayed when using the Dock itself to switch to Renoise by summoning and navigating the Dock from another fullscreen app, i.e., pulling the cursor below the screen to reveal the Dock and selecting the Renoise icon.

  • The Dock is displayed on an intermittent basis when using the three-fingered slide gesture on a trackpad to switch to fullscreen Renoise from another fullscreen app. This symptom may depend on clicks or focus before or during switching. This symptom is always either permanent or temporary; the Dock never slides away immediately as expected of MacOS apps with conventional fullscreen mode.

  • Using any other method for switching to Renoise from another fullscreen app than those described above will display the Dock temporarily. The Dock will not be displayed permanently, nor will it slide away immediately.

  • Switching to Renoise from a non-fullscreen app will cause the Dock to always slide away immediately. This will not display the Dock permanently or temporarily.

  • Accessing an open non-fullscreen app will draw the app’s window and the Dock on top of Renoise. The expected behavior is for any fullscreen apps to not be visible below a non-fullscreen window; only the desktop and any other open non-fullscreen apps inside the same desktop space should be visible underneath a non-fullscreen window.

  • When moving the cursor to the top of the screen, a fullscreen instance of Renoise will not display the red, yellow, and green close, minimize and maximize buttons in the title bar as is conventional, reducing the number of ways for the user to access those functions.

Mission Control labels the space occupied by Renoise “Desktop”. This, combined with the behavior surrounding non-fullscreen apps described above, seems to indicate that Renoise is not assigned its own space when put into fullscreen mode, but is instead drawn inside the default desktop space (Desktop) in a non-standard fullscreen mode which, while in focus, attempts to suppress the Dock.

The issue has been observed in Renoise version 4.3.1 and 3.3.2, but I have noticed symptoms as far back as version 3.3.0. I’m running MacOS Catalina 10.15.7 on a MacBook Pro.

Screen Shot 2021-10-03 at 8.26.39 PM

Screen Shot 2021-10-03 at 9.46.21 PM

system details

Dragging an instance of Renoise into its own space inside Mission Control will enter Renoise into fullscreen mode without the main symptom described at the top of this post, presenting a limited workaround.

An Apple support article explains this process:

The Spaces bar at the top of the Mission Control window contains thumbnails of each desktop space and each window that is in full screen or Split View.

If you drag a window onto an empty area of the Spaces bar, that window opens in full screen in its own new space

Using this workaround, Renoise does not have a working keyboard shortcut for toggling fullscreen mode. The existing shortcut (ALT+ENTER) is still tied to the non-standard fullscreen mode, which remains enabled when Renoise occupies its own space, but has only undesired effect:

  • Using the key combination to minimize Renoise within its own space reveals a black background around the now-windowed Renoise still inside its own space rather than transporting it to a desktop space.

  • Using the key combination to enter the non-standard fullscreen mode while Renoise occupies its own space (already in conventional fullscreen mode) will prevent the user from accessing the entire menu bar (in addition to the title bar and its three buttons).

Updated after replicating in Renoise 4.3.1.

So did you set your Dock to auto-hiding? I do not fully understand the steps to reproduce here. In my 10.14.6, I do not have that problem at all, my dock here is hiding as usual under any circmstances. This would indicate a bug in Catalina actually maybe? I would agree that Renoise is not using the “official” fullscreen mode, easily detectable by the annoying extra virtual desktop then (see Bitwig for comparison)…

1 Like

No, I have not set the Dock to automatically hide.

my dock here is hiding as usual

Does that mean it’s displayed at all? If so, it might at least partially be doing what I’m describing above. Have you tried using the CMD+TAB shortcut to switch between spaces?

This would indicate a bug in Catalina actually maybe?

If it’s Renoise that’s relying on non-standard behavior, then I wouldn’t say so, even if it isn’t an issue in Mojave. I have not run into this with any other apps, let alone ones with conventional full screen modes.

As far as I recall, this was also an issue when I ran Mojave. Maybe you can share your system details?

Ok, set the dock now to permanently staying. No matter whether I switch apps/screens via cmd-tab or by using the usual trackpad gesture, the dock fades in/out normally so far.

Same in Bitwig, only here the dock already is blending out while the transition animation, this might indicate that Renoise is doing the blending out action itself or so…? Then maybe an additional check for state could fix this?

I use the latest version of Mojave, 10.14.6. Nothing special here. I use a magic trackpad via bluetooth, it’s a workstation.

No matter whether I switch apps/screens via cmd-tab or by using the usual trackpad gesture, the dock fades in/out normally so far.

Are you switching to full screen Renoise from another full screen app?

I installed Bitwig. It’s using a standard full screen mode, so the Dock is hidden when switching to Bitwig in full screen mode from another full screen app as expected.

I use the latest version of Mojave, 10.14.6. Nothing special here. I use a magic trackpad via bluetooth, it’s a workstation.

What hardware are you using—an iMac, a Mac Mini, a Hackintosh?

What are you system specifications (About This Mac)?

Are you using one or more external monitors?

Good morning.

Sorry, should have read your post more accurately. Switching to fullscreen Renoise from fullscreen Bitwig using cmd-tab produces the problem like you described it (with Dock set to “stay permanently”). Same happens with desktop switching gesture, if the switching forth and back is faster than the switching-animation takes.
But here, I can at least fix this by switching one time to a Finder desktop for some seconds.

Not at all. I edited the post before I responded to you yesterday, so that’s on me if it wasn’t clear enough when I first described it.

Thank you for taking the time to replicate the bug.

Renoise has recently been updated, most recently to version 4.3.1. If anyone would like to replicate the bug, they’re more than welcome to report back here.