Closed Bug 1456991 Opened 6 years ago Closed 6 years ago

A11y is broken in latest ff61

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
61 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla61
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 blocking verified

People

(Reporter: j.lancett, Assigned: Jamie)

References

Details

(Keywords: nightly-community, regression) 

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180301022608

Steps to reproduce:

After ff updated today my screen reader stopped being able to read out what is on the screen. I am running the 64 bit build of ff 61 and windows 10 64 bit. My screen reader is NonVisual Desktop Access (NVDA)
Version: next-15060,4709bfa7
URL: http://www.nvaccess.org/
[Tracking Requested - why for this release]: Accessibility no longer working just before Nightly Soft Freeze
Severity: normal → critical
status-firefox59: --- → unaffected
status-firefox60: --- → unaffected
status-firefox61: --- → affected
status-firefox-esr52: --- → unaffected
status-firefox-esr60: --- → unaffected
tracking-firefox61: --- → ?
Keywords: nightly-community, regression, regressionwindow-wanted
Component: Untriaged → Disability Access APIs
Flags: needinfo?(jteh)
Product: Firefox → Core
The ff build from the 24th worked fine.
I see this too, but for me, a lot more than just a11y is broken. For example, if I tab away from the address bar and press alt+d or control+l, Firefox doesn't move back to the address bar. If I do enter an address and press enter, nothing happens.
Flags: needinfo?(jteh)
It looks like this breakage only occurs if AccessibleHandler.dll is registered and in the right place; i.e. if you rename it even when registered, everything works, but obviously a11y is slow. If AccessibleHandler.dll is registered and located correctly, a11y completely breaks, plus the other weirdness I mentioned in comment 3.

Unfortunately, mozregression choked on a merge commit, so that's not so helpful. Here's the pushlog anyway, just in case:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7a9b9ce05f857f8a96595ccd90d556d032654a1a&tochange=290da68a04a4fb67a28ca690a9b185a7fed8a3a2
Assignee: nobody → jteh
Status: UNCONFIRMED → NEW
Ever confirmed: true
This was caused by bug 1364624, which was backed out  a few hours ago. So, this should work in the next nightly.
Following the STR from description on Windows 10 x64 using the latest Nightly 61.0a1( Build ID:20180426100055), Firefox crashes:
https://crash-stats.mozilla.com/report/index/8e4dea2e-01ed-4737-9235-6472d0180426
(In reply to roxana.leitan@softvision.ro from comment #6)
> Following the STR from description on Windows 10 x64 using the latest
> Nightly 61.0a1( Build ID:20180426100055), Firefox crashes:
> https://crash-stats.mozilla.com/report/index/8e4dea2e-01ed-4737-9235-
> 6472d0180426

These are separate bugs: see bug 1457148
Closing, since this now works. We'll possibly need to investigate further if there's a desire to re-land bug 1364624.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Blocks: 1364624
Status: RESOLVED → VERIFIED
status-firefox61: affected → verified
tracking-firefox61: ? → blocking
Keywords: regressionwindow-wanted
Target Milestone: --- → mozilla61
See Also: → 1472137
You need to log in before you can comment on or make changes to this bug.