Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deleting characters in ie8 editfields (regression) #1605

Closed
nvaccessAuto opened this issue Jun 25, 2011 · 18 comments
Closed

Deleting characters in ie8 editfields (regression) #1605

nvaccessAuto opened this issue Jun 25, 2011 · 18 comments

Comments

@nvaccessAuto
Copy link

Reported by briang1 on 2011-06-25 14:43
You asked me to keep an eye on what was going on on these fields At the moment in Ie 8 I have found the following. When for example writing in this field, cursors tell me what is there, but delete is silent. Not sure quite why.

Also when coming into a ticket, a great heap of the possible inputs for an item seem to be being read instead of the focus mode one might expect.

I trust this is of use.

@nvaccessAuto
Copy link
Author

Comment 1 by briang1 on 2011-06-25 15:36
I am planning on attaching commented logs to this ticket showing the things I get in this combination.First the verbosity then the no echo delete.

@nvaccessAuto
Copy link
Author

Attachment verbosity in a ticket.log added by briang1 on 2011-06-25 15:50
Description:
Commented log about the verbosity issue

@nvaccessAuto
Copy link
Author

Attachment no delete echo in ie.log added by briang1 on 2011-06-25 15:53
Description:
The no delete echo issue

@nvaccessAuto
Copy link
Author

Comment 2 by briang1 on 2011-06-25 15:56
These could be different issues, so you might want to split this ticket. As one is quite plainly very new, ie the delete echo, and the other not so new, ie in the beta.

@nvaccessAuto
Copy link
Author

Comment 3 by briang1 on 2011-06-26 06:28

This breaks between
nvda_snapshot_main-4487_installer.exe
Which works and
nvda_snapshot_main-4495_installer.exe
Which has no spoken text when deleting with backspace.
Further to this, delete by word seems to work still, and perversely, when coing in to re edit this comment I noted delete worked a while near the start of the edit field, then stopped again

@nvaccessAuto
Copy link
Author

Comment 4 by mdcurran on 2011-06-28 02:34
So far I can not reproduce this in IE9 or IE8 on win7, nor IE6 on XP. True I have not tried IE8 on XP yet.

@nvaccessAuto
Copy link
Author

Comment 5 by briang1 on 2011-06-28 07:23
I have no machine here with IE6, but IE7 does it on XP.
Is there perhaps some configuration choice somewhere that might affect this aspect that I might have set. I don't want to go upsetting my config, but I suppose I could set up some portable versions with 'out of the box' settings to test it.
Either way though, it is something new as stated earlier The intersting thing is that coming out of edit area, and coming back in can make it work for a time at least, as if this forces something to recalculate the positions. I am getting it to work now after doing just that. The interesting part to me is that when it came back in, it kind of got confused and started reading all over the place, untill I cursored down, then it was working with delete and still is.
Curiouser and curiouser.. Its doing it as I type this,

@nvaccessAuto
Copy link
Author

Comment 6 by briang1 on 2011-07-01 16:29
Further to this problem. In other multi line edit fields even stranger effects can be seen. Have a look at this page
http://www.filehippo.com/info/contact/
This page seems to have two single line fields followed by a multi line one. However rather than delet just being silent, this one seems to reproduce the first character in the first line every time delet or backspace as you say in the log, is pressed.

As on this field in the ticket, though Firefox is fine.
Its only IE that is affected

@nvaccessAuto
Copy link
Author

Comment 7 by briang1 on 2011-07-01 16:55
The log fragment is pretty short...
IO - inputCore.InputManager.executeGesture (17:42:51):
Input: kb(desktop):tab
IO - speech.speak (17:42:52):
Speaking multi line'
IO - speech.speak (17:42:52):
Speaking [u'blank']
IO - inputCore.InputManager.executeGesture (17:42:56):
Input: kb(desktop):shift+z
IO - speech._speakSpellingGen (17:42:56):
Speaking character u'Z'
IO - inputCore.InputManager.executeGesture (17:42:57):
Input: kb(desktop):u
IO - speech._speakSpellingGen (17:42:57):
Speaking character u'u'
IO - inputCore.InputManager.executeGesture (17:42:58):
Input: kb(desktop):l
IO - speech._speakSpellingGen (17:42:58):
Speaking character u'l'
IO - inputCore.InputManager.executeGesture (17:42:58):
Input: kb(desktop):u
IO - speech._speakSpellingGen (17:42:58):
Speaking character u'u'
IO - inputCore.InputManager.executeGesture (17:42:59):
Input: kb(desktop):.
IO - speech.speakTypedCharacters (17:42:59):
typed word: Zulu
IO - speech._speakSpellingGen (17:42:59):
Speaking character u'dot'
IO - inputCore.InputManager.executeGesture (17:43:01):
Input: kb(desktop):space
IO - speech._speakSpellingGen (17:43:01):
Speaking character u'space'
IO - inputCore.InputManager.executeGesture (17:43:04):
Input: kb(desktop):backspace
IO - speech._speakSpellingGen (17:43:05):
Speaking character u'Z'
IO - inputCore.InputManager.executeGesture (17:43:06):
Input: kb(desktop):backspace
IO - speech._speakSpellingGen (17:43:06):
Speaking character u'Z'
IO - inputCore.InputManager.executeGesture (17:43:07):
Input: kb(desktop):backspace
IO - speech._speakSpellingGen (17:43:07):
Speaking character u'Z'
IO - inputCore.InputManager.executeGesture (17:43:11):
Input: kb(desktop):leftArrow
IO - speech._speakSpellingGen (17:43:12):
Speaking character u'l'
IO - inputCore.InputManager.executeGesture (17:43:12):
Input: kb(desktop):leftArrow
IO - speech._speakSpellingGen (17:43:12):
Speaking character u'u'
IO - inputCore.InputManager.executeGesture (17:43:13):
Input: kb(desktop):leftArrow
IO - speech._speakSpellingGen (17:43:13):
Speaking character u'Z'
IO - inputCore.InputManager.executeGesture (17:43:15):
Input: kb(desktop):rightArrow
IO - speech._speakSpellingGen (17:43:15):
Speaking character u'u'

@nvaccessAuto
Copy link
Author

Comment 8 by briang1 on 2011-07-04 07:56
So, my question is, how cantwo multi line edits, ie the one above and the one on this ticket show differing effects on the backspace/delet when cursors do not?

@nvaccessAuto
Copy link
Author

Comment 9 by briang1 on 2011-07-09 16:19
Can you reproduce this in IE 8 yet. Every machine I've tried so far exhibits the same behaviour of either nothing on delete or the first character in a field.
It was fine in 2011.1.1. I just checked this with a portable version on that release. Further to this, if you cursor back into the text one character, then use delete it mostly works correctly. Its as if its deleting before its reading. IE one char ahead of where it actually is.

@nvaccessAuto
Copy link
Author

Comment 10 by orcauser on 2011-07-09 17:50
Yes, reprodusable, probably due to commit 4489.

Changes:
Changed title from "Strange behaviour in online edit fields" to "Deleting characters in ie8 editfields (regression)"

@nvaccessAuto
Copy link
Author

Comment 11 by jteh on 2011-07-09 23:33
Actually, this isn't specific to browse mode.

Mick was unable to reproduce this and I haven't tried myself yet. nevertheless, we have some idea of what might be happening. The problem is that the fix for this bug was breaking quite a bit of other stuff; see for example #1590. We figure that this is the lesser of two evils. The real bug is in Microsoft's code and once again we need to try to find a work around.

@nvaccessAuto
Copy link
Author

Comment 12 by briang1 on 2011-07-10 08:26
The only place I can get it is in multi line edits, it seems single line edits are OK.
The reason I tend to use IE8 is because FF seems sluggish in online edit fields to me.

I suppose if one knows its multi line edits in IE8, and that its only when deleting from end of line then maybe there is some way the code of cursor left can be drafted in to give the character needed when deleting. Of course if you are right and the effect could occur elsewhere, I can see it would be easy to break something else accidentally.
Obviously in XP we have no opportunity to use IE9. IE 7 seems to do the same thing on the one machine I have with it on. Very strange that it does not happen for some people and that is why I wonder if there might be another factor in it I've not thought of.

@nvaccessAuto
Copy link
Author

Comment 13 by briang1 (in reply to comment 10) on 2011-07-10 09:06
Replying to orcauser:

Yes, reprodusable, probably due to commit 4489. Note that the other effect mentioned in this ticket could well be related. I only get this in multi line fields though. Single line ones are fine

@nvaccessAuto
Copy link
Author

Comment 14 by briang1 on 2011-07-19 17:40
I have found by going to several sites responce pages that the multi line fields mostly report the first character in the filed. So far the nvda ticket field, ie this one is the only one which gives blank when deleting from the end of a line.
Futher, if you add a character to the line, then delete from the last but one character, the delete will always work correctly. so it seems its that something thinks its in a different place to where the caret or cursor is.

@nvaccessAuto
Copy link
Author

Comment 15 by jteh on 2011-07-28 01:51
We found a work around. :) Committed in 4ca9f36.
Changes:
Milestone changed from None to 2011.2
State: closed

@nvaccessAuto
Copy link
Author

Comment 16 by briang1 on 2011-07-28 21:00
Yes its working on this ticket field. As I'll be visiting a lot of these I'll keep you posted if there are any issues.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant