Bug 347421 has the reasons why we would like to do this. adding javier, I am not sure who else from xforms would need to be added.
Created attachment 261298 [details] [diff] [review] Turn off Xforms on the Mac Not setting review request until Javier comments. Both Linux and Windows currently have XForms enabled, but I'm not aware of any packaging problem for them.
The xforms hack has stopped working on the trunk on windows as well due to mixed up paths (cygwin versus native), and we don't want to support this configuration in the future. xforms should be built in its own tree, using (for example) --with-libxul-sdk .
Summary: [mac] Turn XForms off on the trunk → Turn XForms off on the trunk
Created attachment 261493 [details] [diff] [review] Disable xforms on all platforms, rev. 1 got r=preed verbally on this change
Assignee: build → benjamin
Status: NEW → ASSIGNED
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Attachment #261298 - Attachment is obsolete: true
I fixed the nagios nags too. Checking in Firefox_trunk.txt; /cvsroot/mozilla/tools/tinderbox-configs/monitoring/Firefox_trunk.txt,v <-- Firefox_trunk.txt new revision: 1.8; previous revision: 1.7 done
OS: Mac OS X → All
Hardware: Macintosh → All
(In reply to comment #2) > The xforms hack has stopped working on the trunk on windows as well due to > mixed up paths (cygwin versus native), and we don't want to support this > configuration in the future. xforms should be built in its own tree, using (for > example) --with-libxul-sdk . So are there plans for that?
If you mean, do preed or I have plans to do that, no.
(In reply to comment #2) > The xforms hack has stopped working on the trunk on windows as well due to > mixed up paths (cygwin versus native), and we don't want to support this > configuration in the future. xforms should be built in its own tree, using (for > example) --with-libxul-sdk . > So you are saying you want XForms out of the extensions directory, too, in addition to no longer being built by the tinderboxes? Or are you saying that we just need to find our own tinderboxes?
verified with mac trunk build from 2007041604. the xforms extension is no loger there.
Status: RESOLVED → VERIFIED
Where the code lives is irrelevant. It needs to be built as its own "product". Perhaps we can find community build resources to build it at some point, but the main Firefox tinderboxes are not the right place.
Can XForms at least stay on the 1.8 and 1.8.0 tinderboxes? Or is the with-libxul-sdk stuff working there? I think that xforms needs to build nightly again via community build, hopefully in the near future and I'll help toward that goal in any way that I can. It is quite useful for the accessibility and the XBL guys to have the xforms nightlies to help track down regressions if nothing else. For XBL we can often create a standalone testcase, but that is not always possible. cc'ing surkov and aaronL since building xforms as its own product will affect XForms accessibility.
(In reply to comment #12) > Can XForms at least stay on the 1.8 and 1.8.0 tinderboxes? Or is the > with-libxul-sdk stuff working there? I'll defer to QA on that; they were running into testing difficulties on the trunk because of XForms (packaging) issues on the Mac. If they are having the same problems when trying to do 1.8 tests, then we'll have to turn them off there. Juan? Jay? Marcia?
I'd vote to build xforms in firefox tinderboxes from point of view XForms accessibility at least until xforms have not own tinderbox. Often general accessibility changes affect on XForms accessibility or XForms accessibility changes affect on XForms extension and vice versa therefore it's comfortable to have xforms in firefox tinderboxes otherwise it's imposible to know whether patch is successfully builded on platforms I have not.
(In reply to comment #8) > If you mean, do preed or I have plans to do that, no. Sad. (In reply to comment #11) > Where the code lives is irrelevant. It needs to be built as its own "product". > Perhaps we can find community build resources to build it at some point, but > the main Firefox tinderboxes are not the right place. That is probably correct, but it used to live there and now it does not. So just disabling it is a bit harsh, when there is no plan at all to get it to work again.
We really need nightly xforms builds. Not all our testers build xforms themselves and to find regressions nightly builds are must-have. If we can fix Bug 377424 and Bug 347421 in some other way, could we back out this change and build xforms on the trunk for now.
How is my tester supposed to test XForms anymore? Can we reverse this change?
Somebody will need to provide contributed builds of xforms. MoCo is not planning on doing any xforms builds at this point, unless somebody can write a build system that doesn't interfere with Firefox at all.
My vote is for fixing this.
I would also recommend that the problem with the Apple XForms build process be resolved rather than removing the XForms plugin from the build tree. I have a number of enterprise clients, including standards organizations in Canada and Harvard Business School, that are quite favorably disposed towards the FF XForms plugin, and believe it should be an essential part of Firefox moving forward.
My vote is for fixing this. I would also recommend that the problem with the Apple XForms build process be resolved rather than removing the XForms plugin from the build tree. Xforms is a w3c reccomendation and one of the most interesting innovations for a future semantic web, not a simple upgrade. I have clients interested in this standard and we believe that integrated support of xforms is essential for the future of Firefox and of the Web.
Yes, please just fix the bug in the Apple build. I agree with the comments above, XForms is a great innovation from the w3c. It is a great leap in one of the most commonly overlooked problems in web development -- mapping the view to the model. It's so overlooked because people take the pain of mapping form data to their model for granted. Please leave XForms in the build!
The XForms plugin code is undergoing some significant changes (particularly towards supporting XForms 1.1, which is very exciting), and the community really needs timely access to fixes and new features in order to be able to provide useful input to the development process. I echo Dustin, above: please leave XForms in the build!
In the software cooperative I work for we have been developing during more than a year now an Xforms open source product for rapid web application programming and the firefox extension has been an essential part since the begining. My oppinion is that Mozilla should do what Microsoft isn't doing regarding XForms: support its widespread adoption. It's a wonderful technology and will be the standard forms functionality in XHTML 2.0. How can Mozilla not support it? I think this decision has been made without paying attention to the real importance of this piece of software that Aaron and the rest have been working on so hard for so long. It would be wise not only to review this decision but to increase support from mozilla to the adoption of Xforms technology inside it's products; the open source community will very much appreciate it and the web experience for the end user will greatly improve too.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.