search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.11k stars 637 forks source link

Some edit fields in firefox don't show their contents in a consistant manner. #4381

Closed nvaccessAuto closed 8 years ago

nvaccessAuto commented 10 years ago

Reported by driemer.riemer@... on 2014-08-11 21:41 A good website to test this with is w3schools.com. On this site, if you click any of the examples, and try moving around in the editor with your html code, you hear unexpected results. This also happens in the editor window for tickets, which makes me think this happens in any multiline edit field. Take this line for an example. <!DOCTYPE html> Sounds random when moved through with the arrows. It one time may sound like <DDDTPMLL And another time may sound like !OCTYYEhtml

This happens when moving by words as well. This behavior is noticeable with regular English as well and is very prevalent on my machine on most websites.

It also happens when moving by line, and makes using multiline edit fields with nvda very hard if not impossibl with firefoxe. Blocking #4412

nvaccessAuto commented 10 years ago

Comment 1 by jteh on 2014-08-12 10:03 I can't reproduce this. It sounds like the cursor is moving too slowly and NVDA is timing out before it actually moves. It shouldn't be moving anywhere near that slowly.

Has this always happened for you? If not, when did it start happening?

nvaccessAuto commented 10 years ago

Comment 2 by driemer.riemer@... on 2014-08-12 18:08 It has happened for a while now. I could provide a snippit from the log, but it also doesn't announce when I delete letters as well, leading me to believe something bigger is going on.. Sometimes things speak correctly and sometimes not. For example, when I deleted the word bigger, I heard " nothing, nothing, nothing, g nothing". Maybe I need to reinstall ff? Now that I think about it, I haven't been able to reproduce it on a lab machine at CU.

nvaccessAuto commented 10 years ago

Comment 3 by driemer.riemer@... on 2014-08-14 08:14 So I uninstalled and reinstalled firefox, and all the issues are fixed. The only issue I still have is that firefox doesn't announce when I am pressing backspace on things. backspace announces better when i am editing with a portible version of nvda, but doesn't announce when I am backspacing with my installed copy of nvda. I know it isn't due to addons in nvda, because when I rename my addons folder in the nvda directory, (in this case I renamed nvda/addons to baddons, when I restart nvda an empty addons folder is created, and the issue still occurs.

nvaccessAuto commented 10 years ago

Comment 5 by jteh on 2014-08-24 08:52 I still can't reproduce this here. It'd be great if anyone experiencing this can try older versions of NVDA and/or Firefox to see where the issue starts occurring.

nvaccessAuto commented 10 years ago

Comment 6 by driemer.riemer@... on 2014-08-29 08:48 How can I provide more specific data for this. Is there a way to get nvda to send debug stuff? I guess I would have to connect nvda to a debugger, but this machine isn't setup with the appropriate stuff, as I do nvda development in a vm. I would have to figure out how to attach an exe to a debugger in the first place. (well, maybe I could use gdb with the debug symbols nvda creates with scons if provided).

nvaccessAuto commented 10 years ago

Comment 7 by driemer.riemer@... on 2014-08-29 08:51 I can try running nvda older versions this week (assuming calc 2 lets me have a break from integration and that systems or discrete math don't have large assignments come up). :)

nvaccessAuto commented 10 years ago

Comment 8 by James Teh <jamie@... on 2014-09-12 04:04 In [50cd8e6be853c1dc0f32274dfd857b5c0ee96da4]:

editableText: Increase the caret movement timeout to 50 ms (from 30 ms).

It seems that caret movement has slowed down in Firefox 32. This might also improve cursor tracking in command consoles for some users.
Re #4381.
nvaccessAuto commented 10 years ago

Comment 9 by jteh on 2014-09-12 04:50 Can users experiencing this please try this try build and report whether it fixes the issue? Thanks. Changes: Milestone changed from None to next

nvaccessAuto commented 10 years ago

Comment 11 by driemer.riemer@... on 2014-09-12 05:33 Much better in consoles and firefox.

nvaccessAuto commented 10 years ago

Comment 12 by jteh (in reply to comment 11) on 2014-09-12 05:47 Replying to driemer.riemer@…:

Much better in consoles and firefox.

By much better, do you mean the problem is gone or it still happens occasionally but much less than it did?

nvaccessAuto commented 10 years ago

Comment 13 by driemer.riemer@... on 2014-09-12 06:56 From any case I can produce, gone. If I find anymore, I will let you know.

nvaccessAuto commented 10 years ago

Comment 14 by vgjh2005 on 2014-09-13 13:31 Hi James: I have downloaded version next-11117,332af99. I cannot browse the character correctly by pressing arror left or arror right in editBox(for example address editBox, google search editBox). Thanks!

nvaccessAuto commented 10 years ago

Comment 15 by jteh (in reply to comment 14) on 2014-09-13 21:10 Replying to vgjh2005:

I have downloaded version next-11117,332af99. I cannot browse the character correctly

The fix isn't in next yet. As noted in comment:9, I'm asking for feedback on a specific try build which I linked.

nvaccessAuto commented 10 years ago

Comment 16 by vgjh2005 on 2014-09-14 05:14 Hi: I have tried the build from comment 9. It work correctly. But its echo is slow a little. Thanks!

nvaccessAuto commented 10 years ago

Comment 17 by lpintes (in reply to comment 9) on 2014-09-14 10:57 Replying to jteh: I didn't try the provided try-build. I however tried the freshly compiled master branch. And guess what? The state is better. So I believe the fix here, the increased timeout is masking something else. The very same firefox of course.

nvaccessAuto commented 10 years ago

Comment 18 by jteh (in reply to comment 16) on 2014-09-14 11:02 Replying to vgjh2005:

I have tried the build from comment 9. It work correctly. But its echo is slow a little. Thanks!

The whole reason for this bug is that caret movement in Firefox 32 seems to have slowed down a little (perhaps because of MozillaBug:949518).

nvaccessAuto commented 10 years ago

Comment 19 by jteh (in reply to comment 17) on 2014-09-14 11:03 Replying to lpintes:

I didn't try the provided try-build. I however tried the freshly compiled master branch.

The fix isn't in master or next. It's in a separate branch (t4381). If you're seeing improvement in master, it's very likely placebo.

nvaccessAuto commented 10 years ago

Comment 20 by lpintes (in reply to comment 19) on 2014-09-14 11:48 I wanted to say that I tried the master branch, and the problem almost disappeared. And I tried it seriously, for example when editing / writing the ticket comment. The next in its current state is unusable. The master works very well, not perfectly, but is good enough to be usable. So it is certainly not a placebo :) I am talking about source-master-4e78e51

nvaccessAuto commented 10 years ago

Comment 21 by jteh on 2014-09-14 21:09 If master is fine for you, NVDA 2014.3 should also be fine. Several users were reporting problems in NVDA 2014.3.

As to why master works for you when next doesn't, I can't think of any changes in next that should affect this. One possibility is that we actually wait longer for the caret to move in master because we handle unnecessary events (which we just drop in next), but that would suggest that some background app on your system is firing a lot of unnecessary events.

nvaccessAuto commented 10 years ago

Comment 22 by jteh (in reply to comment 21) on 2014-09-15 07:36 Replying to jteh:

As to why master works for you when next doesn't, I can't think of any changes in next that should affect this. One possibility is that we actually wait longer for the caret to move in master because we handle unnecessary events (which we just drop in next), but that would suggest that some background app on your system is firing a lot of unnecessary events.

Actually, on further reflection, this doesn't make sense. Anecdotally, it does seem that next misbehaves more in this regard than master, but none of the currently incubating branches seem to suffer from this, so I have no idea why next might behave differently in this regard.

nvaccessAuto commented 10 years ago

Comment 23 by James Teh <jamie@... on 2014-09-16 03:10 In [c3f28d96bb4d841189515cb12e94839095e482cb]:

Back out t4294.

This is at least a partial cause of #4381. I think this is due to the removal of wx.Yield in KeyboardInputGesture.send. If there is pending stuff in the queue, this would make the first wx.Yield indirectly called by EditableText._hasCaretMoved take longer, so waiting for caret movement would time out sooner than it did before. Technically, this isn't a bug in #4294.
However, we have no current need for #4294 any more and we've had reports that suggest it might be causing modifiers to stick. Therefore, until we have time to debug this or until there is a specific need for it, it's simpler to just back it out.
This reverts commits 6fb9c104..45bb5962.
Re #4294, #4381.
nvaccessAuto commented 10 years ago

Comment 24 by jteh on 2014-09-16 03:16 Okay. I figured out why this is different in next; see comment:23. Please give it a try. It'll be in the 16 Sep next snapshot.

Lubos, thanks for the suggestion. You're most definitely right: it wasn't placebo, though it was quite tricky to figure out what was going on.

I was under the impression that users had reported this with master or NVDA 2014.3, but I'm starting to think I was wrong. Has anyone experienced this with NVDA 2014.3 or master?

nvaccessAuto commented 10 years ago

Comment 25 by driemer.riemer@... on 2014-09-16 04:45 It seems worse in recent nexts as to nexts from a week ago or so.

jcsteh commented 8 years ago

There may still be some rare instances of this, but the regression that caused this to be filed has been fixed.