377198 - Turn XForms off on the trunk

Status: VERIFIED FIXED

(Release Engineering :: General, defect)

Description

[Marcia Knous [:marcia]]

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.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: 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.

Comment 2

[Benjamin Smedberg]

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 .

Comment 3

[Benjamin Smedberg]

Attachment: Disable xforms on all platforms, rev. 1

got r=preed verbally on this change

Comment 4

[Benjamin Smedberg]

Fixed on trunk.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 7

[Allan Beaufour]

(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?

Comment 8

[Benjamin Smedberg]

If you mean, do preed or I have plans to do that, no.

Comment 9

[aaronr]

(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?

Comment 10

[Tracy Walker [:tracy]]

verified with mac trunk build from 2007041604. the xforms extension is no loger there.

Comment 11

[Benjamin Smedberg]

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.

Comment 12

[aaronr]

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.

Comment 13

[J. Paul Reed [:preed]]

(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?

Comment 14

[alexander :surkov (:asurkov)]

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.

Comment 15

[Allan Beaufour]

(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.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 17

[Aaron Leventhal]

How is my tester supposed to test XForms anymore?

Can we reverse this change?

Comment 18

[Benjamin Smedberg]

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.

Comment 19

[Leigh L. Klotz, Jr.]

My vote is for fixing this.

Comment 20

[Kurt Cagle]

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. 

Comment 21

[Lorenzo De Tomasi]

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.

Comment 22

[Dustin Whitney]

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!

Comment 23

[John L. Clark]

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!

Comment 24

[Nicolás Echániz]

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.

Comment 25

[Stefano Debenedetti]

My vote for getting XForms into all builds by default.

It took me years since its first versions until I was able to install a recent version of Firefox with a recent version of the XForms extension.

And when I finally managed to install it, less than a year ago, thanks to the gentoo "xforms" USE flag, oh joy, so much I had desired it, so much I had heard people say great things of it: it was there, no more need of implementing XForms in javascript myself. Thank you mozilla!

After a few happy months of XForms development and advising people to install it in mass, I start getting feedback about installation problems again: it only works with old Firefox versions. Again.

After a few more research, I find out it is because of this bug. It should really be linked from the project home page.