IE8: NVDA does not read the current line in some multi-line edit fields when arrowing up and down

[vtsaran]

When using up and down arrows to read the current line inside multi-line edit fields, NVDA produces an error ding (if using snapshots) or no speech output (when using official versions).
Some examples are:

1. The "description" field of the "new ticket" screen.

2. "compose message" screen in the Yahoo! Mail Clasic.
3. And probably others (these are the ones) I tried.

This behavior is observed using the latest release of Internet Explorer 8.

[pvagner]

I can reproduce it with the following output in the nvda.log:
ERROR - scriptHandler.executeScript (08:48:19):
error executing script: <bound method MSHTML.script_moveByLine of <NVDAObjects.IAccessible.MSHTML.MSHTML object at 0x026B2F10>> with key (None, 'extendedup')
Traceback (most recent call last):

File "scriptHandler.py", line 100, in executeScript

script(keyPress)

File "NVDAObjects\init.py", line 657, in script_moveByLine

info.expand(textInfos.UNIT_LINE)

File "NVDAObjects\IAccessible\MSHTML.py", line 180, in expand

self._expandToLine(self._rangeObj)

File "NVDAObjects\IAccessible\MSHTML.py", line 114, in _expandToLine

tempRange.moveToPoint(lineLeft,lineTop)

File "C:\Python26\lib\site-packages\comtypes\client\lazybind.py", line 160, in caller

return self._comobj._invoke(descr.memid, descr.invkind, 0, *args)

File "C:\Python26\lib\site-packages\comtypes\automation.py", line 649, in _invoke

dp, var, None, argerr)

COMError: (-2147467259, 'Unknown error', (None, None, None, 0, None))

[aleksey_s]

I can't reproduce this on windows XP with IE8 and manually created page with textarea in it.
NVDA reads the text field correctly all the time.
Tested with 2009.1rc1 and the main branch

[jteh]

Unfortunately, it seems that this bug only occurs on *some* multiline edit fields, not all. Mick did mention to me that he was able to reproduce it using Vic's examples, however. We *suspect* this might relate to the multiline edit field being floated using CSS. Unfortunately, all attempts to fix this so far have failed, so we may have ot defer to a later release.

[jteh]

We are not going to be able to fix this for 2009.1.

[jteh]

Not likely to find a fix before the release.

[mdcurran]

Fixed in changeset:main,3637.
If moveToPoint fails, we fall back to using the older slower and less accurate approach of moving the physical selection with key presses.