Update related dialogs unexpectedly get focus #2847
Comments
|
@LeonarddeR Wow, that's an old one. Just tried the exact steps I described. While the downloading dialog was displayed, nothing special happened. However, when the message that the download was succesfull and the update will be installed is displayed, the find dialog seems to react strangely. Tabbing no longer works properly and pressing enter doesn't activate the OK button anymore. I can't cancel out of it either. Easier way to reproduce this: Open find dialog, search for text that isn't there, leave the not found message box open, open a second find dialog. You should see the behavior I described. Note: earlier I posted multiple comments, deleted those and merged them into 1 comment for clarity. |
|
If I'm reading this right, the originally reported behaviour (an update dialog gaining focus after dismissing the Find dialog) no longer occurs. The weird issue with the Find dialog not responding to key commands (tab, enter, escape, etc.) occurs because the update success dialog is a modal dialog, which seems to block messages from getting to modeless dialogs. #1451, #3361 and #5735 are other instances of the same behaviour (with the same cause). #1740 also has the same cause, though with different results. By definition according to wx, a modal dialog blocks input to all other windows, so I guess this makes sense. However, it surprises me that there doesn't seem to be a way to prevent this from affecting other top level windows in the same app in wx. For example, if you have two documents open in Word or two browser windows open in Chrome, a modal dialog in one window doesn't affect the other window at all. |
|
There are indeed some strange things that happen sometimes like this when
nvda is around. I put it all down to there only being one copy of nvda, so
to speak. Its a similar issue when you cannot get the main nvda menu up on a
running copy since its left some odd window open you cannot actually get at
to close. this one goes all the way back to early versions of nvda and seems
to occur when something in the machines boot up uses a lot of time and
delays nvda from starting fast. The only option is to reboot nvda, though it
still mostly works but no internal menus in nvda will work in this
condition.
I note you never hear nvda close when this condition is present as it has
to force it to close rather non elegantly, and a look at the log just shows
it stop recording at some point.
Not much one can do, thankfully its very rare, normally only if some
software has done an update and decides to hog the system to configure
itself during the next restart.
Brian
bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal email to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
|
|
According to @jcsteh's #2847 (comment), the original issue reported in this ticket no longer occurs, and the buggy behaviour described in @bramd's #2847 (comment) is unrelated to that and already covered by several other cited tickets. Time to close? @ehollig |
|
Closing, as it sounds as if the original issue does not happen anymore. |
Reported by bramd on 2012-12-04 18:29
Steps to reproduce:
Expected result:
After searching the focus should return to the website.
Actual result:
The search result is being read, but the focus is moved to the "Downloading update" or "Update is ready to install" dialog.
The text was updated successfully, but these errors were encountered: