Turn XForms off on the trunk

VERIFIED FIXED

Status

Release Engineering
General
VERIFIED FIXED
11 years ago
5 years ago

People

(Reporter: marcia, Assigned: Benjamin Smedberg)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

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

Comment 2

11 years ago
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
(Assignee)

Comment 3

11 years ago
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
(Assignee)

Comment 4

11 years ago
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Duplicate of this bug: 377424
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

Comment 7

11 years ago
(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?
(Assignee)

Comment 8

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

Comment 9

11 years ago
(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
(Assignee)

Comment 11

11 years ago
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

11 years ago
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?

Comment 14

11 years ago
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

11 years ago
(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

11 years ago
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

11 years ago
How is my tester supposed to test XForms anymore?

Can we reverse this change?
(Assignee)

Comment 18

11 years ago
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

11 years ago
My vote is for fixing this.

Comment 20

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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.

Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.