It is there when we migrate Is{Set}SpokenFeedbackEnabled from AccessibilityManager, due to the reason that OnBrailleDisplayStateChanged we need different notification visibility type. However, |spoken_feedback_notification_| is not a reliable design.
Naively it seems like there should be a separate code path that explicitly shows a notification, rather than making it an optional side effect of turning on spoken feedback.
+estade just FYI since he's looked at notifications recently.
I dunno what your plan is to fix it, but this comment seems like it would necessitate changes that would encompass removing that member:
// TODO(crbug.com/594887): Fix for mash by moving pref into ash.
> [...] rather than making it an optional side effect of turning on spoken feedback
From my reading of the code it seems like it's done this way because it no-ops when the pref is unchanged.
In ash, the only one place that SetSpokenFeedbackEnabled call doesn't trigger notification is here: https://cs.chromium.org/chromium/src/ash/system/tray_accessibility.cc?sq=package:chromium&l=346
I wonder whether we can always make ChromeVox enabled showing notification, including above "clicked on system tray menu option" case. It doesn't look bad to me with notification bubble shown on top of system tray bubble after I clicked on the tray menu.
If we could do so, it would be pretty straightforward to remove spoken_feedback_notification_.
Comment 1 by warx@chromium.org
, Jan 9 2018