Firefox support? about accessibility-insights-web

[digitarald]

Firefox DevTools team member here, who would be available for help. Accessibility audits are important to keep the web open and accessible to all; and developers struggle with understanding and addressing this topic. Your audit has some great ideas and can have a meaningful impact!

Having an product labeled "for Web" only available in Chrome would be an sad outcome for an announcement that promised:

Together we seek the best outcome for all people who use the web across many devices. […] Ultimately, we want to make the web experience better for many different audiences.

Many developer extensions are available for Chrome and Firefox, and you won't find many CSS or JS hacks. Once setup, the builds are not much overhead. What you will end up with is cross-browser compatible and more future-proof code.

We are happy to support the work to add support and the outreach necessary to get developers on pre-release channels for testing. Please re-consider and let me know how we can help.

[shawnthompson]

Why is this issue closed? I would love to use this amazing tool in Firefox.

[DaveTryon]

Unfortunately, this is out of scope given our current priorities.

Thanks for using Accessibility Insights!

[animania4ka]

Hey @digitarald thank you for reaching out and offering to help!
We are re-considering the possibility to support that effort and would be happy to engage in further conversations with you after we internally discuss the options.
Do you have a timeline in mind on your side?
I'd be happy to take this offline too!

[dbjorge]

A few more implementation notes:

• Firefox 77 (currently in beta, release date slated for 6/2/20) will start supporting the onAdded/onRemoved permissions events (yay!)
• As of 77, Firefox's windows.create() implementation will throw an error if you attempt to pass it the focused property; we need to diverge what we pass to this API between Chromium/Firefox.
• As of 77, Firefox doesn't support named capture groups in RegExps (see 1362154)

[ferBonnin]

After reviewing within our team and hearing the community feedback, we are reactivating this feature request. Our original concerns around the initial and ongoing cost of maintaining support for Firefox are still valid:

After long conversations with the team we have determined that for now, the costs to create an extension for Firefox would be too significant for the team.
From early explorations looks like we would have to do considerable changes, to mention some:
• Changes to the code to ensure that it works properly in Firefox.
• There are likely to be some special cases around visualizations, accessibility, storage, updating that we would have to develop for.
• To fully support this we would have to test regularly in Firefox and add it to our release cadence.
• We would have to publish this to the Firefox application store and ensure that we aren’t broken by Firefox updates.
• Our user base in the canary and insider builds would need to be sufficient robust to ensure that our roll through the tiers is stable.

but we would be happy to accept ongoing community contributions that enable the extension to work properly in Firefox with every release, and that update our E2E tests to cover Firefox scenarios.

[digitarald]

Great to hear @adrianaandreeva! Looking forward to hear the results of the internal conversations. If we know more about what is blocking your work, we can diagnose and come up with estimates on by when it should be fixed.

Feel free to reach out via {my nickname} [at] mozilla.com to discuss offline.

[kewisch]

Hi @dbjorge, I'm excited you are looking at Firefox support, even if your team has not prioritized it.

For the second item on your list, we're looking into a quick fix that would avoid window.create throwing with focused: false passed, though at the moment we're not supporting opening inactive windows. I hope this makes it easier for you and others. See bug 1253129 for more details. If all goes well this will make it into 78, along with named capture groups.

I hope this makes Firefox development easier, if you have any additional feedback please feel free to get in touch!

[rugk]

Please add Firefox support! With WebExtensions the APIs are very much the same and your maintenance cost will be very low. (actually the Firefox WebExtension APIs are often better and have more features.)

Also please re-open this issue, so we can see you are considering adding Firefox support.

[rugk]

Could you then at least reopen this issue for now to signal you are working on this issue?

---

As for the specific issues, I do understand the second one, but the first one is not clear to me: So you mean you are missing a "permission control site" for the user, you can link to?

Currently, Firefox can only show the permission and loads of the idea of requesting permissions to the extension itself.
So maybe https://bugzilla.mozilla.org/show_bug.cgi?id=1497075 is covering what you want?
If not, could you possibly open a new issue, please?

[flyingUnderTheRadar]

@mike-engel - Currently Accessibility Insights for Web only supports Chrome. We haven't explored Firefox support.

[mike-engel]

@flyingUnderTheRadar Are there any plans to support other browsers in the future?

[flyingUnderTheRadar]

@mike-engel - At this point of time there is no plan to support Firefox or any other browser in the near future.

[flyingUnderTheRadar]

Need to update docs to reflect this so leaving it open.

[ferBonnin]

Hey @mike-engel thanks for your interest in Accessibility Insights for Web!

After long conversations with the team we have determined that for now, the costs to create an extension for Firefox would be too significant for the team.
From early explorations looks like we would have to do considerable changes, to mention some:
• Changes to the code to ensure that it works properly in Firefox.
• There are likely to be some special cases around visualizations, accessibility, storage, updating that we would have to develop for.
• To fully support this we would have to test regularly in Firefox and add it to our release cadence.
• We would have to publish this to the Firefox application store and ensure that we aren’t broken by Firefox updates.
• Our user base in the canary and insider builds would need to be sufficient robust to ensure that our roll through the tiers is stable.

We agree that there is value in your suggestion however, for now, we want to focus on continuing providing a great experience in our current extension and improving the capabilities in it.

Thanks!

[dbjorge]

Looked into this a little during slack time last week. #1003 #1004 #1005 (and Firefox 1570849) came out of it, but only got as far as enabling the popup page to show up; the ad-hoc tools hang when being enabled and the fastpass/assessments links don't launch the desired pages, and the background page is full of console errors about unhandled errors in chrome.* callbacks. Definitely more work to be done here before we'll know how big of an onion-peeling exercise this would be.

Notes on P2 things so we don't forget about them if/when we revisit this:

• Firefox unilaterally returns false from chrome.extension.isAllowedFileSchemeAccess and doesn't support toggling allowing it like Chrome does, so we'd want to update our dialog to detect this and avoid suggesting the user go to their extension settings to look for a setting that doesn't exist.
• Firefox doesn't use the same format for extension settings pages and doesn't seem to support a URL that goes directly to the settings for a single extension, so we'd have to rethink the UI currently calling our BrowserAdapter.getManageExtensionUrl
• Firefox doesn't seem to support a direct URL to manage extension keyboard shortcuts like chrome://extensions/shortcuts, so the UI explaining how to set those will need to be rethought
• Audit all the points where the term "Edge" appears; probably all of them need a third case.

[rugk]

doesn't seem to support a URL that goes directly to the settings for a single extension,

It does: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/openOptionsPage

Firefox doesn't use the same format for extension settings pages

Huh? How so? It's still HTML.

[dbjorge]

@rugk, sorry for the late reply; the answer to both of your points is that the "settings page" we're talking about there is the browser page to "manage the extension", not the extension's options page (Accessibility Insights doesn't use an options page). In Chrome, we direct the user to that settings page when the user tries to use the extension against a file://* URL, since that's where you manage that permission toggle in Chrome.

[dbjorge]

One more point we'll need to deal with: Per https://bugzilla.mozilla.org/show_bug.cgi?id=1444294 , Firefox doesn't support the browser.permissions.onAdded/onRemoved events we're about to start using for Chrome, so we'll need some sort of workaround for that. There's a polyfill that adds partial support for the events but it only works for permissions requests that are initiated from the same page as the event handlers, which isn't sufficient for our needs (at minimum, we'd need different paths for chrome/firefox; chrome supports the user revoking the permissions we want to track from the manage extension page, and we would want to detect those events).

[dbjorge]

I apologize; I didn't mean to signal that we're working on this issue. I'm just keeping notes about what we'd want to consider were we to reopen this issue in the future. I do have a personal interest in this feature, but my understanding is that our team does not have any current plans to prioritize it.

On the "manage extension" page: in Chromium, when an extension tries to run a content script on a file:// URL, the request is blocked by default regardless of extension manifest permissions until the user explicitly opts in to allowing the extension to run on local files from Chromium's "manage extension" page at chrome://extensions/?id=${chrome.runtime.id}. When we detect the user is attempting to scan a file:// URL without this permission, we present the user with instructions and a link to that page.

Firefox doesn't seem to have an equivalent to the chrome://extensions/?id=${chrome.runtime.id} URL that we can point users to, but it also doesn't seem to support the file:// URL opt-in either (it appears to unilaterally return "false" for those permissions), so for our particular use case, it's more that we have to redo the dialog completely to just tell the user it isn't supported in Firefox and not present a link at all.

[rugk]

Okay, so the only drawback would be that file:// URLs are not supported.
I guess this is an acceptable trade-off, after all file:// URLs are going to be less useful anyway already, because Firefox (and AFAIK Chrome too), do enforce a strong same-origin policy on them and do not allow loading/reloading JS/CSS from file:// URLs via HTML tags or JS.

[dbjorge]

@kewisch Thanks for the update! We're actually the case where we pass focused: true, but I see that the same bug covers our case as well. Looking forward to the resolution!

For other feedback: the incompatibility that I spent today tracking down was the difference in behavior between how Firefox and Chromium interpret relative paths passed in the file option to the browser.tabs.insertCSS and browser.tabs.executeScript APIs. The behavior difference and a reasonable workaround is documented on MDN for those APIs already, but it was a little harder than it could have been to track down the issue because Firefox does not give a useful error message when you try to call those APIs using a file that does not exist; the error I got back in that case had the message Error: an unexpected error occurred. We use the webextension APIs via https://github.com/mozilla/webextension-polyfill, not sure if that's part of our issue.

I understand that there isn't a great way to fix the behavior difference without it being a breaking change, but it would be helpful if the error message could identify the issue more concretely (bonus points for specifically detecting a relative path as the file parameter and linking the documentation about that gotcha on MDN as part of the error message)

[kewisch]

Thank you for the feedback Dan. I've filed bug 1661125 on our end to improve the error messages. We'd love to increase compatibility between browsers and will see how to best approach this for the future. Let us know if you come across any other differences that were difficult to debug.

[ferBonnin]

Hey @shawnthompson thanks for your question and your interest in Accessibility Insights!

We revisited this issue internally and we still cannot prioritize this work. As we commented back when this issue was created, the cost to create and maintain this extension for Firefox would be too impactful for the team.

[shawnthompson]

Thanks @ferBonnin. What about having it completely open and let the community support this?

Mozilla has a great team of developers that who worked very hard to get Firefox to work with VoiceOver.

VoiceOver Preview for macOS Firefox

Maybe they have some bandwidth to work with you folks on this.

I'm actually demoing A11Y Insights to my team later this morning and will be speaking about it to a larger group within the Government of Canada.

Many departments within the "system" do not allow Chrome but they do allow Firefox within the department.

I'm sure I'm not alone in not wanting to start another browser war.

Side note: let's not forget about Safari!!!

[dbjorge]

Thanks Fer! To summarize from earlier comments, the known work that we'd love to see community contributions for includes (but isn't limited to):

• Update file:// URL handling such that for Firefox users, the extension presents a "this URL isn't supported" message (similar to chrome:///etc URLs), as opposed to the current Chromium behavior where the extension directs users to an extension settings page to allow file:// access for the extension (Firefox doesn't have such a setting)
• Update the "Keyboard Shortcuts" link in our popup hamburger menu somehow. In Chromium the menu item links directly to chrome://extensions/shortcuts, but Firefox doesn't seem to support a direct URL to manage extension keyboard shortcuts like that. The ideal would be to file a Firefox bug requesting support for such a URL, but the most expedient option would probably be to point to a documentation page describing how to set the shortcuts. https://support.mozilla.org/en-US/kb/manage-extension-shortcuts-firefox looks pretty promising, but I'm not sure how stable KB URLs like that are; it would be good to research that as part of this update.
• Update url-validator.ts to add all of the known Firefox-specific protected URLs that the extension sould skip scan attempts for
• Do a side-by-side audit of all user scenarios in firefox vs chromium to look for any UI/functionality differences; file and fix individual issues accordingly
• Do an audit of all user scenarios with firefox + {NVDA, JAWS, VoiceOver, Narrator} to look for any browser-specific screen reader issues; file and fix individual issues accordingly
• Enable Firefox end-to-end testing. These Playwright docs are a good starting point. There will be some challenges here related to the fact that Playwright doesn't have first-class support for extensions in Firefox (see microsoft/playwright#2874)