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

NVDA crashes Firefox Nightly when choosing label during filter creation in Gmail. #9402

Closed
lukaszgo1 opened this issue Mar 23, 2019 · 3 comments · Fixed by #10188
Closed

NVDA crashes Firefox Nightly when choosing label during filter creation in Gmail. #9402

lukaszgo1 opened this issue Mar 23, 2019 · 3 comments · Fixed by #10188

Comments

@lukaszgo1
Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Mar 23, 2019

Steps to reproduce:

  1. Open firefox Nightly, login to Gmail.
  2. Perform a search and then click advanced search options.
  3. Click create filter.
  4. Check Apply the label, move to button for selecting a label, press it with space, and try to navigate in the newly opened menu.

Actual behavior:

Firefox Nightly crashes, the following is written in the NVDA log
ERROR - eventHandler.executeEvent (19:12:48.443):
error executing event: gainFocus on <NVDAObjects.IAccessible.mozilla.BrokenFocusedState object at 0x0531EBF0> with extra args of {}
Traceback (most recent call last):
File "eventHandler.pyc", line 155, in executeEvent
File "eventHandler.pyc", line 92, in init
File "eventHandler.pyc", line 100, in next
File "C:\Users\Lukasz\AppData\Roaming\nvda\addons\remote\globalPlugins\remoteClient_init_.py", line 426, in event_gainFocus
File "eventHandler.pyc", line 100, in next
File "appModules\firefox.pyc", line 24, in event_stateChange
File "eventHandler.pyc", line 100, in next
File "browseMode.pyc", line 1448, in event_gainFocus
File "textInfos\offsets.pyc", line 458, in expand
File "virtualBuffers_init_.pyc", line 376, in _getUnitOffsets
File "textInfos\offsets.pyc", line 437, in _getUnitOffsets
File "textInfos\offsets.pyc", line 306, in getCharacterOffsets
File "virtualBuffers_init
.pyc", line 230, in _getTextRange
WindowsError: [Error 1726] remote invocation of a procedure failed.

the crash report from Nightly is here:
https://crash-stats.mozilla.org/report/index/7f8b7e21-9ef0-4e44-b758-8c0b30190323

Expected behavior:

The list of the labels should be navigable.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

NVDA version alpha-16941,e3b2e797

Windows version:

Windows 7 x64

Name and version of other software in use when reproducing the issue:

Firefox Nightly 68.0a1 (2019-03-23) (64-bit)

Other information about your system:

With JAWS Nightly doesn't crash in this situation.

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

No
cc @jcsteh @MarcoZehe

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Mar 24, 2019

This is not a crash in Firefox code. It seems the vbuf has a reference to an invalid child node here. The line we crash on is this (in VBufStorage_fieldNode_t::getTextInRange):

child->getTextInRange(max(startOffset,childStart)-childStart,min(endOffset-childStart,childLength),text,useMarkup,filter);

@michaelDCurran, any ideas?

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Mar 24, 2019

This seems to be similar to #8924. There are two lists: one which gets focus and one which does not. As with the menu causing trouble in that issue, all of the list items are in the tree, but not inside the focused list. However, the focused item is always moved beneath the focused button using aria-owns and focused using aria-activedescendant. That is, there is only ever one list item which is a child of the focused list. When you move the focus, the previously focused item returns to the full list and the newly focused item gets owned and made the active descendant of the focused list.
Note that the accessibles aren't re-generated in this case. The list items always have the same ids, but their parents change.

What I don't understand is why #8930 doesn't fix this.

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Apr 17, 2019

We've also had a report of a crash in markNodeAsNonreusableIfInAncestor. While a different crash and we don't have STR, it's likely that this is also due to an invalid child node and that this was caused by a node moving.

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

Successfully merging a pull request may close this issue.

5 participants