Closed
Bug 485734
Opened 16 years ago
Closed 16 years ago
Make XForms build with Firefox 3.5
Categories
(Core Graveyard :: XForms, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: imphil, Assigned: imphil)
References
Details
Attachments
(1 file, 1 obsolete file)
|
3.97 KB,
patch
|
aaronr
:
review+
doronr
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-1.1.6 Firefox/3.0.7
Build Identifier:
There were some changes to the Mozilla codebase that requires changes to XForms in order to compile correctly.
Reproducible: Always
| Assignee | ||
Comment 1•16 years ago
|
||
Attachment #369843 -
Flags: review?(aaronr)
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → 1.9.1 Branch
Attachment #369843 -
Flags: review?(aaronr) → review+
| Assignee | ||
Updated•16 years ago
|
Attachment #369843 -
Flags: review?(doronr)
Comment 2•16 years ago
|
||
Why can't we support seamonkey?
| Assignee | ||
Comment 3•16 years ago
|
||
I guess we could, but @SEAMONKEY_VERSION@ is gone and I didn't find a replacement right away. Should we hardcode it? Does anybody test XForms with Seamonkey? (or even use seamonkey?)
I used Seamonkey almost exclusively until FF3 came out. Seamonkey, AFAIK, hasn't made available a release based on that code base so I quit using it (except for monitoring newsgroups and IRC). More info here: http://www.seamonkey-project.org/
Comment 5•16 years ago
|
||
Comment on attachment 369843 [details] [diff] [review]
Fix the XForms build for FF 3.5
I use it, but if SEAMONKEY_VERSION is gone, fine with me.
Attachment #369843 -
Flags: review?(doronr) → review+
Comment 6•16 years ago
|
||
I would say it's preferable to hardcode seamonkey's version instead of removing seamonkey support completely. We could bump version each time when new stable seamoneky and xforms versions are available.
| Assignee | ||
Comment 7•16 years ago
|
||
Would it make sense to hardcode all versions (at least minVersion)? That requires that we remember to bump the version if we use a new feature of a particular version, but I guess that's easier to remember than looking through all relevant changes when writing the release notes.
Just make sure that if you hard code Firefox version that it works with any checked out tree. I'd rather not change it by hand every time I check out code to build.
| Assignee | ||
Comment 9•16 years ago
|
||
I looked closer at the issue and we actually can remove the Firefox/Seamonkey/Mozilla parts entirely as the toolkit entry covers them all -- at least for the "get forms working" part. I don't know how much the XUL overlays for the config settings are different for Seamonkey/Firefox, but that would require different versions anyways, so no gain by using separate targetApplication entries.
While being at it I also incorporated the changes I already made at bug #340728 (was somehow forgotten). It mainly removes the install.js file (not used any more) and sets the BUILD_ID variable which is empty right now. Lastly it moves the version number out of Makefile.in into a version.txt file for easier changes.
Attachment #369843 -
Attachment is obsolete: true
| Assignee | ||
Updated•16 years ago
|
Attachment #370740 -
Flags: review?(aaronr)
Attachment #370740 -
Flags: review?(aaronr) → review+
| Assignee | ||
Comment 10•16 years ago
|
||
I meant bug #437491, no idea how the other one sneaked in here...
| Assignee | ||
Updated•16 years ago
|
Attachment #370740 -
Flags: review?(doronr)
Updated•16 years ago
|
Attachment #370740 -
Flags: review?(doronr) → review+
Comment 11•16 years ago
|
||
Should this patch be landed on hg repository only?
Updated•16 years ago
|
Assignee: nobody → mail
| Assignee | ||
Comment 12•16 years ago
|
||
yes, hg only.
Comment 13•16 years ago
|
||
Just to ensure, Philipp, does xforms with your patch work both on Firefox and Seamonkey, right?
| Assignee | ||
Comment 14•16 years ago
|
||
To quote https://developer.mozilla.org/en/Install_Manifests:
New in Firefox 3 Gecko 1.9 based applications allow you to use the special targetApplication id toolkit@mozilla.org to say that the add-on is compatible with any toolkit app with a toolkit version matching the minVersion and maxVersion.
That's what I've seen in my testing, too.
| Assignee | ||
Comment 15•16 years ago
|
||
While at it, I forgot in the patch to delete the files
install.js
install.jst
and .cvsignore needs to be converted/renamed to .hgignore
Comment 16•16 years ago
|
||
(In reply to comment #15)
> While at it, I forgot in the patch to delete the files
> install.js
> install.jst
>
> and .cvsignore needs to be converted/renamed to .hgignore
Would be nice if you'll upload new patch then ;)
| Assignee | ||
Comment 17•16 years ago
|
||
*gg* ok, but this will not happen until I'm home tonight.
Comment 18•16 years ago
|
||
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•