After changing the contents of a file in an Editor Window and closing without saving the "Save on Close" window pops up. On both MacOS and Linux the user can't do anything on the Editor Window anymore, but on Windows, not only can the user continue to write it is possible to try to close the window again. Each time the user attempts to close the editor the "Save on Close" window appears one more time.

Also, when you have 2 such windows if you say 'no' then,no matter what the answer to the second window is, IDLE crashes.

I'm not sure but this seems to me to be a Tk problem. Attached is a simple script that works completely different on different systems showing that this is probably a Tkinter or Tk bug.

I tested this on Mac with Python 2.7, 3.3, 3.4 and Tk 8.5.13. On Linux I tested with Python 3.2 and Tk 8.5.11 and on Windows with Python 3.3 and Tk 8.5.11.

What behavior on which system to you consider to be buggy? On 3.3.1, Win 7, all seems fine. By selecting Windows as a component, you imply that something is wrong on Windows.

"on Windows, not only can the user continue to write[(if the user Cancels),] it is possible to try to close the window again. Each time the user attempts to close the editor the "Save on Close" window appears one more time."

This is what should happen.

"Also, when you have 2 such windows if you say 'no' then,no matter what the answer to the second window is, IDLE crashes."

I do not see this.

'with Python 3.3': 3.3 is a version of the language. 3.3.0 and 3.3.1 are two different patch releases. Did you use the latter, which has several Idle improvements? When discussing bugs, we need to be specific as to releases used.

Interesting that you consider Windows working as expected, Terry. I thought save/close dialogs were generally modal; but, then, I avoid GUIs whenever possible so I could easily be wrong :)

Because model is normal (as far as I know) I did not understand that 'continue to write' meant doing so without hitting [Cancel] ;-). I might consider being able to do so a feature *if* the dialog were the only one ever created and if subsequent attempts to close merely shifted focus back to the dialog.

However, after shifting focus back to the edit window without hitting [Cancel] and hitting [X] again, I get a *duplicate* "Save on Close" dialog. This is a bug somewhere. I get this duplication on 2.7.4a1 and 3.4a0 also. Only the last dialog created works to close the window.

On 3.3, after closing the edit window with the last dialog [No], I can duplicate the unexpected Idle exit by selecting any of the 3 choices in the previous dialog. This is a second and more serious bug. I do not see this with 2.7.

When I run 3.3 Idle from the console interpreter with 'import idlelib.idle', the Shell window does not close, mimicking 2.7.
The console displays '''
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1475, in __call__
    return self.func(*args)
  File "C:\Python33\lib\idlelib\EditorWindow.py", line 996, in close
    reply = self.maybesave()
  File "C:\Python33\lib\idlelib\EditorWindow.py", line 993, in maybesave
    return self.io.maybesave()
  File "C:\Python33\lib\idlelib\IOBinding.py", line 331, in maybesave
    self.text.focus_set()
AttributeError: 'NoneType' object has no attribute 'focus_set'
'''
Running 2.7 shows the same message. So this AttributeError seems not to be the exception causing Idle 3.3 to quit when run otherwise.

If I open Command Prompt, and start Idle with
C:\Python\Python33>python -m idlelib
I get the same attribute error without the Shell window closing. Perhaps not having a console to write the traceback to closes 3.3 but not 2.7. Peculiar.

A different console message, Shell window not closed

Python 3.4.0a0 (default:bcfb6888fb8d, Apr 18 2013, 19:47:33) 
>>> import idlelib.idle
Exception in Tkinter callback
Traceback (most recent call last):
  File "\cpython\lib\tkinter\__init__.py", line 1475, in __call__
    return self.func(*args)
  File "\cpython\lib\idlelib\EditorWindow.py", line 1002, in close
    reply = self.maybesave()
  File "\cpython\lib\idlelib\EditorWindow.py", line 999, in maybesa
ve
    return self.io.maybesave()
  File "\cpython\lib\idlelib\IOBinding.py", line 324, in maybesave
    self.save(None)
  File "\cpython\lib\idlelib\IOBinding.py", line 338, in save
    if self.writefile(self.filename):
  File "\cpython\lib\idlelib\IOBinding.py", line 370, in writefile
    self.fixlastline()
  File \cpython\lib\idlelib\IOBinding.py", line 426, in fixlastlin
e
    c = self.text.get("end-2c")
AttributeError: 'NoneType' object has no attribute 'get'

There is, of course, no 3.4 installation icon for starting Idle without a console. However
D:\Python\dev\cpython\PCbuild>pythonw_d -m idlelib

No message, Shell closes.

D:\Python\dev\cpython\PCbuild>python_d -m idlelib
...
AttributeError: 'NoneType' object has no attribute 'focus_set'

Message (different from other method of starting), Shell does not close.

From what I could see the problem is that in MacOS askyesnocancel stops the user from interacting with all windows and in Windows it stops the interaction only in the root window (even when the parameter 'master' is used, as is the case in IDLE). Since the root window in IDLE is hidden askyesnocancel doesn't do anything.

IDLE crashing is due to bpo-13582. We should maybe focus on that issue in the near future as it has become a common theme in many bug reports.

I clicked submit too soon. The attached patch inhibits closing of the Editor when the dialog box appears. It also sets the parent argument so that Tkinter on Windows actually presents a modal dialog box.

What's happening is the the dialog box enters a nested Tk eventloop which allows the editor window to be closed by the window manager via clicking "X". That re-enters the maybesave dialog. The first one unwinds and closes the editor window, setting its internal references to None. The initial maybesave resumes execution with the rug pulled out from beneath its feet and raises errors.

I didn't test Roger's patch because I have limited access to Windows, but I think it should solve this specific issue.

But the problem is actually more general. For example, the same odd behavior happens when you try to run a module without saving. On MacOS one modal dialog pops up, but in Windows you can open as many dialogs as you want.

Using 3.4.1 on Windows I can't reproduce the AttributErrors given in msg187674

When writing the human-verified tests in idle_test.htest.py, we discovered that there is a different between Windows and Linux in focus shifting when opening an editor window from a visible root window. On Widows, I have to click on the editor window to enter anything. Saimadhav reports that on Linux, the editor already has the focus and is live.

Similarly, when I open Idle from console interpreter with
import idlelib.idle
the focus stay with the console and I have to click on the shell to enter code there. I suspect that this is also different on *nix. Can someone check?

Using 3.4.1 and 3.5.0 on Windows 7 I always get the focus set to the edit window or shell as appropriate.

I am on Windows 7 also. Did you open the shell from the console interpreter with import? Run
python -m idlelib.idle_test.htest
and for me the tests that open a separate editor window show the same problem of no cursor or focus in the editor. Perhaps you ran the tcl/tk compilation after the recent change in compile flags.

My 3.4.1 is the released version, 3.5.0 built from source that was synchronised earlier today as in :-

c:\cpython\PCbuild\python_d.exe
Python 3.5.0a0 (default:b1e99b4ec374, Jun 8 2014, 18:29:24) [MSC v.1600 32 bit (Intel)] on win32

Running the console interpreter then import idlelib.idle works fine for both versions. python -m idlelib.idle_test.htest doesn't work for either version, on numerous occasions for different windows there was no focus or cursor.

On Linux I believe that what happens to the keyboard focus depends on the window manager in use and how that window manager is configured to behave. For instance, some window managers have a 'focus follows mouse' setting, but I always hated that so I would disable it, meaning I'd have to click in a window for it to acquire focus. (Or, in my case, use the keyboard to select the window to focus). I believe many window managers also allow you to control what happens to keyboard focus when a new window is opened and you aren't using 'focus follows mouse', but it's been a while since I've played with a window manager that uses floating windows, so I could be misremembering.

It seems that I have been over-optimistic about uniformity of behavior. With the focus issue different for opening Idle and opening subwindows in htest, I added it to the issue about refining htest bpo-21624.

Given Mark's report, I must rebuild tcl/tk and make sure I am running with new .dlls before retesting.

AttributeErrors on closing were a separate issue. They are now caught on closing. bpo-35379.

Save on Close is now modal on Windows also, in that one cannot do anything with the Window being closed.

One can try to close a second dirty window. Saying 'no' in either dialog no longer crashes. The only oddity is that if one switched from the 2nd dialog to the 1st and say 'no' on the first first, it does not immediately close until one answers on the second. It seems normal to me that the 2nd call that raises the 2nd dialog blocks the 1st from receiving and responding to the 1st click until the 2nd call returns.

Thus the bugs reported here have been otherwise fixed.