Closed Bug 369710 Opened 17 years ago Closed 12 years ago

No talking alerts

Categories

(Core :: Disability Access APIs, enhancement)

PowerPC
macOS
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: mozilla, Assigned: hub)

References

Details

(Keywords: access)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/125.4 (KHTML, like Gecko, Safari) OmniWeb/v563.66
Build Identifier: 1.5.0.9, 2.0.0.1

Alert text not spoken

Reproducible: Always

Steps to Reproduce:
Set-up: System Prefs/Speech/Text to Speech: talking alerts enabled, reasonably short delay

A scenario to display an alert; expecting talking alert

1 Launch app
2 New window
3 Open webpage
4 New tab
5 Open webpage
6 Click window close button
Actual Results:  
"Confirm close" sheet appears, but text not spoken

Expected Results:  
First line of alert text spoken. Can use Script Editor for reference (new, make change, close)

Observed:
2.0.0.1, 10.4.9 8P2122, iMac Core Duo/1.83G
1.5.0.9, 10.4.6 8I127, iBook G3/900
Component: General → Disability Access
QA Contact: general → disability.access
Assignee: nobody → aaronleventhal
Blocks: osxa11y
Component: Disability Access → Disability Access APIs
Keywords: access
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Version: unspecified → Trunk
Confirming lack of text to speech in alert dialogs.
Severity: trivial → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Do we have component for text-to-speech support since it appears right people aren't cc'ed here?
This is a platform integration bug rather than accessibility. It is about supporting the default speech alerting system in Mac OS X. Setting to Widget: Cocoa for now in hopes this can be triaged to platform integration.
Component: Disability Access APIs → Widget: Cocoa
QA Contact: accessibility-apis → cocoa
I have observed this too. The alert for checking whether Firefox is the default or not isn't really spoken out loud.

Taking it.
Assignee: nobody → hub
With attachment 590095 [details] [diff] [review] it works, but this is not gonna be the patch that land for it associated bug. 

(just for reference)
Attachment #591193 - Attachment is obsolete: true
Comment on attachment 591198 [details] [diff] [review]
Alerts are now usable with VoiceOver. r=

This is extracted from a previous patch as it was irrelevant there, but is relevant to this bug.
Attachment #591198 - Flags: review?(trev.saunders)
Reviewed over IRC

https://hg.mozilla.org/integration/mozilla-inbound/rev/3e9d7409a091
Target Milestone: --- → mozilla12
Attachment #591198 - Flags: review?(trev.saunders) → review+
Comment on attachment 591198 [details] [diff] [review]
Alerts are now usable with VoiceOver. r=

just making it r+ by the right person :) sorry I didn't have time to fiddle with bugzilla earlier
https://hg.mozilla.org/mozilla-central/rev/3e9d7409a091
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Setting component to what the fix actually is in: Disability Access APIs rather than Cocoa widgets.
Component: Widget: Cocoa → Disability Access APIs
QA Contact: cocoa → accessibility-apis
>   return [self selectedText] ? : [self text];

Is this actually a legal statement?
(In reply to Josh Matthews [:jdm] from comment #15)
> >   return [self selectedText] ? : [self text];
> 
> Is this actually a legal statement?

It is 

http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Conditionals.html#Conditionals

(given the code is Mac specific, gcc and clang support are all that matter)
You need to log in before you can comment on or make changes to this bug.