Close NVDA with open IE -> "IE has stopped working"

[nvaccessAuto]

Reported by mherrmann.at on 2013-08-02 15:53
OS: 64 bit Windows 7
NVDA version: 2013.1.1

Steps to reproduce the problem:

1. Start NVDA.
2. Start Internet Explorer.
3. Exit NVDA by right-clicking on the tray icon and selecting "Exit".
4. Confirm the dialog "Are you sure you want to quit NVDA" with "Yes".

What happens?
A second or two after NVDA was closed, the standard Windows dialog "Internet Explorer has stopped working" pops up. IE becomes unresponsive. After some time, the Windows dialog offers to "Debug" or "Close program". Clicking on "Close program" restarts IE on the page it was on when NVDA was closed.

[nvaccessAuto]

Comment 1 by jteh on 2013-08-02 21:43
I've been able to reproduce this once, but it happens rarely for me, which will make it tricky to debug.

What version of Internet Explorer is installed on your system?

[nvaccessAuto]

Comment 2 by briang1 on 2013-08-03 07:21
Hi I noted this as a possible happening in my ticket 95 a few back from this one using XP and IE 8. It is intermittent, but it has been happening for some versions now. It is indeed hard to pin down as it all happens when nvda is not logging things it seems.
Thus solving this might also have an effect on the main issues in the 95 ticket, maybe as oe is using resources from IE
.

[nvaccessAuto]

Comment 4 by mherrmann.at on 2013-08-03 10:52
My IE version is 10.0.9200.16635. Update Versions: 10.0.7 (KB2846071). Product ID: 00150-20000-00003-AA459. I will update the original ticket description with those details.

As I said, I can reproduce this problem 100% of the time. If you want, I can give you remote access to my computer to debug remotely. Alternatively, if you want me to perform some steps to give you debug information, let me know. Also, we could talk on Skype with you giving me instructions what to do and me telling you what happens, if you want. I know from experience how much of a pain bugs that aren't reproducible are to fix...

Thanks!
Michael

[nvaccessAuto]

Comment 5 by mherrmann.at on 2013-08-03 10:54
I cannot edit the original description of the ticket. Either way, details on my IE version are in my previous comment.

[nvaccessAuto]

Comment 7 by mdcurran on 2013-08-07 00:53
I can't quite reproduce this myself, not unless I start a different copy of NVDA after closing the last one. Then it crashes for me.
However, I have been working on a completely different way of listening for events in Internet Explorer using IConnectionPoint rather than attachEvent / detachEvent. Most recent commit of this is in mshtmlWithIConnectionPoint changeset ae463ca28d054268af3caf5237ca5f6e3566891d.
I also made a try build: http://community.nvda-project.org/try/mshtmlWithIConnectionPoint/nvda_snapshot_try-mshtmlWithIConnectionPoint-9376,ae463ca.exe

Please try this build of NVDA and see if the problem stops for you. However, when trying, its necessary to completely close any opened IE (best to just log out or reboot) then start this NVDA, then start IE. Otherwize an older NVDa may be the cause of the crash.

[nvaccessAuto]

Comment 8 by briang1 on 2013-08-07 09:17
Well, the main issue now seems to be sluggish typing into fields. However in the 95 ticket, after running IE from links in Outlook Express emails, the html view of emails stopped working and I had to restart Outlook Express again to get them back

I did not try IE to see if that was doing the same, as it was hard to read links after this happened.

[nvaccessAuto]

Comment 9 by briang1 on 2013-08-07 21:16
Further to this, BBC I player TV was almost unusable with the try snap unfortunately, it kept glitching about avery three to four seconds on my single core 2.6 gig pentium 4 machine.
Obviously there is some kind of processing overhead in the new system.

[nvaccessAuto]

Comment 10 by briang1 on 2013-08-09 19:50
If this problem of processor glitching and slow down could be sorted I think its more stable, but its really hard to use it online as it stands on slower machines.
I'll watch for another trial snap.

[nvaccessAuto]

Comment 11 by mherrmann.at on 2013-08-13 08:02
The try build fixes the problem for me, however it seems to be a bit slower in IE than release 2013.1.1. Also, the first time I tried to start the try build from within total commander, it did not start and after a while I got "total commander has stopped working".

Thanks for looking into this Mick!

[nvaccessAuto]

Comment 12 by mdcurran on 2013-08-13 08:06
Thanks. Sounds like the new way is indeed more stable. However, I will now work on only listening to the absolutely necessary events to pass our tests, which should speed things back up again some what hopefully. For the test build, I just had it processing all events for a node, which is way over kill.

[nvaccessAuto]

Comment 13 by mdcurran on 2013-08-15 05:09
A new try build: http://community.nvda-project.org/try/mshtmlWithIConnectionPoint/nvda_snapshot_try-mshtmlWithIConnectionPoint-9388,8a2d66d.exe
This time listening to only necessary events. Should be a performance improvement.

[nvaccessAuto]

Comment 14 by briang1 on 2013-08-16 06:37
Hi folks, Brian here. Unfortunately, I've been in hospital, so have not tried this yet, but hope to in the next couple of days.

[nvaccessAuto]

Comment 15 by briang1 (in reply to comment 14) on 2013-08-17 08:18
Hi, yes this is better, Hard to be sure if its as fast as the old way, but its tolerable on slower machines, at least on this form it is.

On BBC I player its much better too, there can be the odd glitch, but not enough to trigger stream loss or weird noises like the last one did.

Replying to briang1:

Hi folks, Brian here. Unfortunately, I've been in hospital, so have not tried this yet, but hope to in the next couple of days.

[nvaccessAuto]

Comment 16 by mdcurran (in reply to comment 11) on 2013-08-28 02:25
Replying to mherrmann.at:

The try build fixes the problem for me, however it seems to be a bit slower in IE than release 2013.1.1.

mherrmann.at: is the newer try build (comment 13) faster for you? If so I'll look at getting this into 'next' to get wider testing.

[nvaccessAuto]

Comment 17 by mherrmann.at (in reply to comment 16) on 2013-08-28 08:00
Replying to mdcurran:

mherrmann.at: is the newer try build (comment 13) faster for you? If so I'll look at getting this into 'next' to get wider testing.

Hi Mick, yes the new build seems to be much better and fixes the "IE has stopped working" issue. Thanks! :)

[nvaccessAuto]

Comment 18 by briang1 on 2013-08-30 10:59
It will be interesting to test a version for a longer time while its in the next branch to see if it affecs the Outlook Express issues or not.

[nvaccessAuto]

Comment 19 by Michael Curran <mick@... on 2013-09-01 23:10
In [c1adf89]:

Merge branch 't3397' into next. Incubates #3397.

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 20 by mdcurran on 2013-09-01 23:12
Changes:
Milestone changed from None to next

[nvaccessAuto]

Comment 21 by Michael Curran <mick@... on 2013-09-16 01:13
In [bcb2228]:

Merge branch 't3397'. Fixes #3397

Changes:
Removed labels: incubating
State: closed

[nvaccessAuto]

Comment 22 by mdcurran on 2013-09-16 01:14
Changes:
Milestone changed from next to 2013.3

[nvaccessAuto]

Comment 23 by leonarddr on 2013-09-17 06:35
Comparing IE with Firefox, IE indeed feels a bit more sluggish when up and down arrowing through the contents of a webpage. I however should investigate IE performance with the master branch to compare this behavior with the old IE behavior.

[nvaccessAuto]

Comment 24 by mdcurran on 2013-09-17 06:39
This has already been merged in to master. Therefore you'll have to compare with either an older master or perhaps 2013.2.