mac nightly builds of FF 3.0a should be, at some time, built with --enable-accessibility

RESOLVED INVALID

Status

()

RESOLVED INVALID
11 years ago
7 years ago

People

(Reporter: ray, Unassigned)

Tracking

({access})

Trunk
x86
Mac OS X
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
I do not know why I am filing this bug, but I do not see this recorded anywhere else. Which seems odd.

FF 3.0 will become final at some time X. I assume that --enable-accessibility will have to be turned on at some time Y, with Y hopefully before X.

So, what should (X - Y) be? Well, if everyone is completely sure there will be no problems with turning it on, then (X-Y) can be a day. Is this what people think?

I keep looking in the about:buildconfig pages of the nightlies. For example, I just checked:

- Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081205 Minefield/3.0a8pre
- Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007081204 Minefield/3.0a8pre

Neither one is using the flag.

So, do people know when the time Y will occur? If it is in the plan, I can stop checking for it manually. Thanks.
I hope it's much more than a day, if it's not already a default (and wouldn't appear in about:buildconfig). CC'ing accessibility people.
Looks like

 157 ac_help="$ac_help
 158   --disable-accessibility Disable accessibility support (off by default on OS X)"
 (http://mxr.mozilla.org/seamonkey/source/configure#157)

is correct, by way of 

 12527 case "$target_os" in
 12528 darwin*)
 12529     ACCESSIBILITY=
 12530     ;;
 12531 *)
 12532     ACCESSIBILITY=1
 12533     ;;
 12534 esac
(http://mxr.mozilla.org/seamonkey/source/configure#12527)

So --enable-accessibility wouldn't appear in about:buildconfig but support would be automatically compiled into Windows & Linux. Aaron (or someone else working on this code) would have to comment on the Mac situation.
Priority: -- → P3
Summary: nightly builds of FF 3.0a should be, at some time, built with --enable-accessibility → mac nightly builds of FF 3.0 should be, at some time, built with --enable-accessibility

Comment 3

11 years ago
I'm not sure what's involved in turning this on, but if it won't break anything, it should be  a no-brainer.  We made the decision, though, that OSX accessibility isn't to the point that we could support it for Firefox 3.  For this release we're shooting for Linux and Windows.  Mac is next in line.
Priority: P3 → --
Summary: mac nightly builds of FF 3.0 should be, at some time, built with --enable-accessibility → nightly builds of FF 3.0a should be, at some time, built with --enable-accessibility

Comment 4

11 years ago
Windows and Linux should already have a11y turned on in the nightlies -- we use them for testing all the time. Unless something has changed, and a11y has been turned off.

For Mac a11y should stay turned off for the forseeable future, until we can circle back with serious development effort there again.
But from time to time we break ally on mac build. Woudn't be it better to turn on it to react upon burning the tree?

Comment 6

11 years ago
I think we should turn it on in one of the Mac tinderboxes, but not in the one that creates the nightly builds.
There is the nightly box, a debug box and a unit test box - each is special in it's own way (nightlies & perf tests, leaks & assertions, test suites) and we currently don't have capacity to bring another build on line. It seems all or nothing to me, so it's up to you to decide if you have time to deal with any bustage.
Summary: nightly builds of FF 3.0a should be, at some time, built with --enable-accessibility → mac nightly builds of FF 3.0a should be, at some time, built with --enable-accessibility
(Reporter)

Comment 8

11 years ago
I would suggest that the accessibility flag should be turned on for all three of the builds. We can look at this in terms of risks and benefits.

risk: One or more of these builds may fail. Are the tinderbox trees so stable that this would be shocking or problematic?

benefit: Someone making a change with an unintended side-effect on the Mac would know it sooner rather than later. This would make it easier to fix the problem.

benefit: Firefox, with accessibility enabled, would be tested for longer. This would give the organization more time to deal with whatever problems occur.

Are there other risks to take into account? I can probably list other benefits if needed.
(In reply to comment #8)
> I would suggest that the accessibility flag should be turned on for all three
> of the builds. We can look at this in terms of risks and benefits.
> 
> risk: One or more of these builds may fail. Are the tinderbox trees so stable
> that this would be shocking or problematic?

they shouldn't be fail. I regularly build mozilla with enabled accessibility on mac, at least I can say it's compiled :)
(In reply to comment #6)
> I think we should turn it on in one of the Mac tinderboxes, but not in the one
> that creates the nightly builds.
> 

Do you think of possible craches because partial support we have is better than nothing?

Updated

9 years ago
Keywords: access
wE'RE SEVERAL MAJOR VERSIONS PAST 3.0 NOW.  MAKING MAC ACCESSIBILITY WORK AND TURNING IT ON IS A PROJECT WE INTEND TO WORK ON BUT i DON'T THINK WE NEED THIS BUG FOR THAT.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
I don't think invalid status is right here. 

David, what's the status of mac running on tinderbox? Are we going to start a1y nightlies for mac?
You need to log in before you can comment on or make changes to this bug.