1229763 - Create a localized support page for accessibility and e10s

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Jim Mathies [:jimm]]

In bug 1198459 we're going to disable accessibility if it starts up while the browser is running with process per tab running. The chrome notification will have an accessible doorhanger, which will have a learn more link. This currently points to a non-existent support page. Before we roll this feature out to beta or release, this support page will need to be created.

https://support.mozilla.org/kb/accessibility-and-ppt

Comment 1

[Jim Mathies [:jimm]]

Erin, fyi. This needs to get done before e10s hits (in a non-experimental way) beta and release. I'm not sure who we go to to get a support page written and localized, can you help track that process down? I'm also not sure if it needs to be localized, we might avoid users on beta and release that aren't english speaking. Not sure if this has come up in our discussions, but should before we roll out.

Comment 2

[Joni Chan]

+Mark Schmidt

Hi Jim,

I've created a placeholder page for this SUMO article. If it's not a hassle though, I recommend using this in-product link instead, so the page won't break if the link gets changed on SUMO: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/accessibility-ppt

The link will redirect to the same page.

Do you have already have content in mind? If not, I can draft an article, but I'll need more info. From what I understand, the article needs to communicate the following:

1. If e10s is enabled (does this happen automatically or is this a setting?) accessibility features will be turned off. Does this mean users can't use zoom or find shortcuts, or is this more about assistive technologies not working with Firefox?

2. What workarounds, if any, do users have?

3. Which version of Firefox does this apply to?

Comment 4

[Jim Mathies [:jimm]]

Attachment: MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

Review commit: https://reviewboard.mozilla.org/r/32621/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32621/

Comment 5

[Jim Mathies [:jimm]]

David, mind giving this a once over?

Support blurb:

Electrolysis (<- described in laymen’s terms?) is currently not compatible with Firefox accessibility features. When 3rd party software running on a user’s system requests access to accessibility features, Firefox limits accessibility features access to web content to prevent stability issues within the browser. After a browser restart, accessibility features will automatically be enabled and electrolysis will be disabled.

Work arounds:
1)	To fully enable accessibility features after receiving this notification, restart Firefox.
2)	To force enable electrolysis for testing purposes, set the ‘browser.tabs.remote.force-enable’ to true.
3)	To avoid this issue, avoid running 3rd party software that request accessibility features within Firefox.

Comment 6

[Jim Mathies [:jimm]]

For localizations, we are rolling out to all languages except ar, fa, he, ur.

See bug 1234673, bug 1033488 tracks the fix.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks for doing this. I think this requires SUMO/Ux approval if there is such a thing.

(In reply to Jim Mathies [:jimm] from comment #5)
> David, mind giving this a once over?
> 
> Support blurb:
> 
> Electrolysis (<- described in laymen’s terms?) is currently not compatible
> with Firefox accessibility features. When 3rd party software running on a
> user’s system requests access to accessibility features, Firefox limits
> accessibility features access to web content to prevent stability issues
> within the browser. After a browser restart, accessibility features will
> automatically be enabled and electrolysis will be disabled.

Another approach:
You have some software* that is requesting Firefox accessibility support. Accessibility features for multi-process Firefox are not yet fully supported. After a browser restart Firefox will default back to single process mode so that accessibility is not broken.

* examples: screen readers, windows touchscreen software, anti-spyware etc.

> 
> Work arounds:
> 1)	To fully enable accessibility features after receiving this notification,
> restart Firefox.
> 2)	To force enable electrolysis for testing purposes, set the
> ‘browser.tabs.remote.force-enable’ to true.
> 3)	To avoid this issue, avoid running 3rd party software that request
> accessibility features within Firefox.

Seems good to me. Probably need links for further info on changing config settings. Number 3 might be the right place to expand on examples.

Comment 8

[Erin Lancaster [:elan]]

Thanks guys. I'll engage with SUMO and with Moz.org team on this.

Comment 9

[Jim Mathies [:jimm]]

Joni is on the SUMO team and was active here earlier so ni'ing here.

Joni do you have enough here to put a basic support page together?

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8712686 [details]
MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

https://reviewboard.mozilla.org/r/32621/#review29399

Thanks jimm! This looks good, but I think we can make use of the built in URL formatter toolkit code to take care of a lot of the boilerplate. See below.

::: browser/components/nsBrowserGlue.js:3212
(Diff revision 1)
> +    let supportUrl = "https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/accessibility-ppt";

There aren't too many cases of us hard-coding these URL templates into browser code, and it gets harder to mess with these sorts of things if we happen to get the URL wrong in a release. If we store the value in a pref, it's easier to manipulate the URL after we've shipped the browser. At least, I think that's one of the reasons why we store the support URLs there.

So would you mind adding this instead to https://dxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js ? I know we haven't really been doing that in the past with e10s, but that's before we were shipping localized support pages, so I think we should be consistent.

::: browser/components/nsBrowserGlue.js:3213
(Diff revision 1)
> +    let locale = "";
> +    try {
> +      locale = gPrefService.getComplexValue("intl.accept_languages",
> +                                            Ci.nsIPrefLocalizedString).data;
> +    }
> +    catch (e) { }
> +    supportUrl = supportUrl.replace(/%LOCALE%/, escape(locale))
> +                           .replace(/%VERSION%/, Services.appinfo.version)
> +                           .replace(/%OS%/, Services.appinfo.OS);

I believe Services.urlFormatter.formatURLPref will do all of the magic here for you.

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIURLFormatter#formatURLPref%28%29

Known interpolations: https://dxr.mozilla.org/mozilla-central/rev/aa90f482e16db77cdb7dea84564ea1cbd8f7f6b3/toolkit/components/urlformatter/nsURLFormatter.js#91

Comment 11

[Jim Mathies [:jimm]]

> I believe Services.urlFormatter.formatURLPref will do all of the magic here
> for you.

Thanks, I was looking for this on #developers today, should have just asked you. :)

Comment 12

[Jim Mathies [:jimm]]

Attachment: MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

Review commit: https://reviewboard.mozilla.org/r/32661/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32661/

Comment 13

[Jim Mathies [:jimm]]

Comment on attachment 8712812 [details]
MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/32661/diff/1-2/

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8712812 [details]
MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

https://reviewboard.mozilla.org/r/32661/#review29415

Looks great, thanks!

::: browser/app/profile/firefox.js:1154
(Diff revision 1)
> +// a11y conflicts with e10s support page
> +pref("app.support.e10sAccessibilityUrl", "https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/accessibility-ppt");

Mind tossing this up on line 1121 where the other app.support pref is?

Comment 15

[Jim Mathies [:jimm]]

Comment on attachment 8712812 [details]
MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/32661/diff/2-3/

Comment 16

[Mike Conley (:mconley) (:⚙️)]

https://reviewboard.mozilla.org/r/32661/#review29417

r=me still stands. :)

Comment 17

[Jim Mathies [:jimm]]

Comment on attachment 8712812 [details]
MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/32661/diff/3-4/

Comment 18

[Jim Mathies [:jimm]]

thanks!

Comment 19

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/72f6605f0809

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/72f6605f0809

Comment 21

[Jim Mathies [:jimm]]

Comment on attachment 8712812 [details]
MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

Approval Request Comment
[Feature/regressing bug #]:
no bug, update to a support url.
[User impact if declined]:
busted support link
[Describe test coverage new/current, TreeHerder]:
on mc
[Risks and why]: low to none
[String/UUID change made/needed]:
none

Comment 22

[Erin Lancaster [:elan]]

I'm engaging with Moz.org team as of this morning.

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8712812 [details]
MozReview Request: Bug 1229763 - Update a11y + e10s support url. r?mconley

Adds e10s support page link in prefs for 46. OK to uplift to aurora.

Comment 24

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking since this is necessary work on a feature aimed at 46. (And marking affected so the sheriffs will see this in their uplift queries)

Comment 25

[Joni Chan]

Jim and David, thanks, we got a page together based on your draft. Please take a look at the link (https://support.mozilla.org/en-US/kb/accessibility-and-ppt) or if you have any other suggestions, please add them to the Google Doc:

https://docs.google.com/a/mozilla.com/document/d/1lBVDAvL3XsTHUJu1KUgePM_88VIYmV8agx_m1zz8DjI/edit?usp=sharing

Comment 26

[Jim Mathies [:jimm]]

LGTM, thanks!

Comment 27

[Liz Henry (:lizzard) (relman/hg->git project)]

Did this change land in aurora? Looks like this is partly "page exists somewhere" and "fix the pref to point to it" and the latter depends on this patch uplifting.

Comment 28

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/52efa2247afa

Comment 29

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

It did not. It has now. :)

Comment 30

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

I believe this is already in 47, comment 20. 47 was in Nightly phase on 1/28

Comment 31

[Alice Wyman]

(To Joni) Is the article at https://support.mozilla.org/en-US/kb/accessibility-and-ppt ready to localize?

Related discussion:
https://support.mozilla.org/en-US/kb/accessibility-and-ppt/discuss/6922 New article: Ready to localize?

Comment 32

[Alice Wyman]

(In reply to Alice Wyman from comment #31)
> (To Joni) Is the article at
> https://support.mozilla.org/en-US/kb/accessibility-and-ppt ready to localize?
> 
> Related discussion:
> https://support.mozilla.org/en-US/kb/accessibility-and-ppt/discuss/6922 New
> article: Ready to localize?

I marked the article ready for localization on Dec 13, 2016 so I'll clear the Need-Info.

Comment 33

[Firefox Bug Husbandry Bot]

Removing leave-open keyword from resolved bugs, per :sylvestre.