In the most recent development version of Python 3.9, when opening the file selection menu through File > Open (or Ctrl-o) in the IDLE, the file names are hidden. Clicking once on each of the icons or the areas in front of them can make the names visible again, but this can be quite cumbersome to users. I'm not certain if this issue is specific to KWin (window manager, component of the Plasma DE), but I've never ran into this problem when using any other applications. 

If it would be helpful, I can attempt to see if this issue occurs when using other window managers.  I attached two screenshots below, the first one is the initial view of "Open" menu and the second one is what it looks like after clicking once on a few of the icons.

Tested on...
OS: Arch Linux 5.2.3
DE: Plasma
WM: KWin

Was unable to attach both files to the first comment, here's the second one of the "Open" menu after clicking a few icons.

Since the names are still there in the screenshots but slightly grayed out, it may have to do with my local font settings. If so, an easy solution to this would be using an override for the IDLE instead of relying the local themes. I can't what practical purpose it would provide to have the icon names grayed out, and then darkened after clicking on them once. If anything, the default coloring upon opening the window should probably be the darker color changed to after the icon is clicked.

Corrections:
"I can't what practical" => "I can't imagine what practical..."

(PS: Definitely looking forward to the full move from bpo to github. Being able to copy-paste temporary image files and edit comments is quite convenient.)

This is definitely not an IDLE issue. To open files, IDLE calls tkinter.filedialog.Open(parent, filetypes).show(initial_dir, initial_file).  Open is a subclass of filedialog._Dialog(commondialog.Dialog).  It sets command = "tk_getOpenFile".  Dialog.show calls the command with root.tk.call after fixing passed in options.  It then fixes the result and returns it.  I believe this command calls the native file dialog.  Since tkinter's option processing, converting python object to strings suitable for tk.call, is OS independent, I presume the problem is in tk_getOpenFile.  I suspect tcl/tk developers have trouble keeping up with the parade linuxes and window managers.  (What is a 'DE?)

If so, this should be closed as 3rd party.  If you want to test first, bypass IDLE and most of tkinter with the following, run directly in Python.

>>> import tkinter as tk
>>> r = tk.Tk()
>>> r.tk.call("tk_getOpenFile")  # select codecontext.py, hit 'Open'
'C:/Programs/Python38/Lib/idlelib/codecontext.py'
>>> r.tk.call("tk_getOpenFile")  # hit 'Cancel'
''

> What is a 'DE'?

DE stands for Desktop Environment, usually they come with a number of packages (mainly GUI) such as window managers, login managers, toolbars, theming, etc. Some of the popular ones include Gnome, Plasma, Mate and LXDE. Usually anything related to appearance and GUI behavior is more closely tied to the DE than the Linux distro itself. Optionally, users can also create their own cocktail of a desktop environment, but in my experience that usually leads to more compatibility issues.

> If so, this should be closed as 3rd party.  If you want to test first, bypass IDLE and most of 
> tkinter with the following, run directly in Python.

Hmm, it looks like setting the path object to codecontext.py didn't fix the issue, but either way, it looks like the issue is directly tied with tk_getOpenFile as you suspected and not the IDLE. I'm not overly familiar with tk in general since most of my experience with Python has not involving building GUIs. I'll probably spend some time messing around with tk to see if I can fix the issue.

Thanks for looking into it. Should I leave it open to get feedback from the tkinter devs since the bypass didn't fix the issue? I'll add gpolo to the nosy list since he's listed as a tkinter expert and remove IDLE from the title.

gpolo should be removed or marked inactive as he has not responded in several years.  I'm closing for now.  Serhiy can say something if he wants, but has other issues to attend to.

Running from IDLE, the dialog opened in idlelib.  codecontext.py was a randon selection to verify return of a proper filename, suitable for open().

Are all Linux DE still based on X-Windows?  Or are there divergent forks to contend with?  If the problem is limited to just the one, consider reporting it.

> gpolo should be removed or marked inactive as he has not responded in several years.

Oh okay, good to know. I'm currently working on an issue to add github usernames to the experts list, so I'll see if I can mark him as inactive as well.

> Are all Linux DE still based on X-Windows?  Or are there divergent forks to contend with? 

The one I'm currently using (KWin) is based on X, but I believe some of the other ones may have diverged a bit.