f5 crashes IE7 under certain conditions in windos update inXP

[nvaccessAuto]

Reported by briang1 on 2010-06-13 19:03 In IE7, with any snapshot of recent times, go to windows update, and select custom. After a while you should hear the tick of the script on the page which denotes the next page of updates is ready. It will not auto read it. You can then hit f5 to attempt a refresh, and IE apparently crashes. The Dwin problem originally on this ticket has been solved by an update. As IE does not crash in this scenario with Hal as the screenreader, it seems that nvda is interacting with IE7.

Note 2010.1 works fine.

[nvaccessAuto]

Attachment log file showing the way crashes are set to happen.log added by briang1 on 2010-07-22 19:01 Description: multiple runs of win update for xp f5 crash demo

[nvaccessAuto]

Comment 1 by briang1 on 2010-06-27 08:51 Having had several long sessions using the special snap test-main-3574-without3482 I have not had any serious ( ie non microsoft_ problem getting Windows updates in XP. IE7 now does not lock up, miss parts of frames or otherwise get confused, though there is not always auto triggering of the reading of the page, its comparable with 2010.1 behaviour. F5 refresh no longer crashes IE7. IE 8 seems much less prone to restart itself as well, which is a bonus.

Note, this is probably applicable to tickets 702 and 658

[nvaccessAuto]

Comment 2 by briang1 on 2010-07-22 16:02 In recent snapshots, unclear when this started, but certainly those in the latter part of July 10, one can get around the problems of windows update in xp IE7 and 8 by doing the following keypresses.

When the express/custom page has fully loaded, do an f5 at that point and wait till the page has reloaded, then follow the normal windows update routes, and it will work, and f5 will no longer crash the system, merely boot ie back to the start of windows update.

Although you will have to cursor about each page, all the info and checkboxes come up as they should and downloads can be done. Mysterious?

[nvaccessAuto]

Comment 3 by briang1 on 2010-07-22 18:50 Further information. I will attach a log generated by snap43 which shows that the crash is actually caused by a key movement or any change in the display in the express/custom part of windows update. Thus one has to do the f5 before any key has been pressed other than f5, or it will crash at that point. Note that the recent updates have meant that dwin can be safely left to run now as nvda itself still operates with it running. However ie still falls over. take a look at the log. first run, tab pressed then f5, second run, cursor moved one char then f5 pressed. Then I did the f5 first and everything went normally. The effect is not restricted to operations within ie, but even bringing up nvdas log and cancelling it will have the same result. Ponder on that one.

Brian Changes: Changed title from "crash of Ie7 in Windows update when F5 is pressed to refresh page, nvda goes non responsive" to "f5 crashes IE7 under certain conditions in windos update inXP"

[nvaccessAuto]

Comment 4 by briang1 on 2010-07-25 12:29 This problem appears to be fixed by the third special build based on snap 46. The reason for this occuring is still not totally clear, but seems to be to some extent at least affected in its severity by certain IE add ins, prime is simple ad block, but I since found the last flash, live sign in and a strange active x from Msoft also has some bearing on it, so it may well have some bearing on how nvda interprets otherwise invisible items on the screen thrown up by some add ons.

This ticket can be closed when the work around from this special version is in an official snap.

Brian

[nvaccessAuto]

Comment 5 by jteh on 2010-07-26 01:36 Fixed in d46345a7d4b6f18e643a1faeead95877ee6669e4. Changes: State: closed