Closed
Bug 393289
Opened 17 years ago
Closed 13 years ago
mac nightly builds of FF 3.0a should be, at some time, built with --enable-accessibility
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: ray, Unassigned)
Details
(Keywords: access)
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.
Comment 1•17 years ago
|
||
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.
Comment 2•17 years ago
|
||
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•17 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•17 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.
Comment 5•17 years ago
|
||
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•17 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.
Comment 7•17 years ago
|
||
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
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.
Comment 9•16 years ago
|
||
(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 :)
Comment 10•16 years ago
|
||
(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?
Comment 11•13 years ago
|
||
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
Closed: 13 years ago
Resolution: --- → INVALID
Comment 12•13 years ago
|
||
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?
Assignee | ||
Updated•5 years ago
|
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•