Closed Bug 1229763 Opened 5 years ago Closed 5 years ago

Create a localized support page for accessibility and e10s

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
e10s m8+ ---
firefox46 + fixed
firefox47 + fixed

People

(Reporter: jimm, Assigned: elan)

References

Details

Attachments

(1 file, 1 obsolete file)

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
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.
Depends on: 1159326
Flags: needinfo?(elancaster)
No longer blocks: e10s-miscblockers
Blocks: e10s-beta
Flags: needinfo?(jsavage)
+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?
Flags: needinfo?(jsavage) → needinfo?(jmathies)
Duplicate of this bug: 1236538
tracking-e10s: --- → m8+
Flags: needinfo?(jmathies)
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.
Flags: needinfo?(elancaster) → needinfo?(dbolter)
For localizations, we are rolling out to all languages except ar, fa, he, ur.

See bug 1234673, bug 1033488 tracks the fix.
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.
Flags: needinfo?(dbolter)
Thanks guys. I'll engage with SUMO and with Moz.org team on this.
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?
Flags: needinfo?(jsavage)
Attachment #8712686 - Flags: review?(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
> 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. :)
Attachment #8712686 - Attachment is obsolete: true
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/
Attachment #8712812 - Flags: review?(mconley) → review+
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 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 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/
thanks!
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
Attachment #8712812 - Flags: approval-mozilla-aurora?
Assignee: nobody → elancaster
I'm engaging with Moz.org team as of this morning.
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.
Attachment #8712812 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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)
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
Flags: needinfo?(jsavage)
LGTM, thanks!
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
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.
Flags: needinfo?(wkocher)
It did not. It has now. :)
Flags: needinfo?(wkocher)
I believe this is already in 47, comment 20. 47 was in Nightly phase on 1/28
(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?
Flags: needinfo?(jsavage)
(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.
Flags: needinfo?(jsavage)
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.