Closed Bug 954593 Opened 10 years ago Closed 10 years ago

Update XUL from 7.0.1 to 9.0

Categories

(Chat Core :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

Attachments

(5 files, 6 obsolete files)

*** Original post on bio 1161 at 2011-11-12 11:29:00 UTC ***

*** Due to BzAPI limitations, the initial description is in comment 1 ***
Attached patch XUL 7.0.1 => XULL 8.0 (obsolete) — Splinter Review
*** Original post on bio 1161 as attmnt 987 at 2011-11-12 11:29:00 UTC ***

First step, 8.0. I believe this is a correct way to do this since, right now, 8.0 has been released. We can think about the 9.0 later on. Here is a patch for 8.0 that seems OK (tested on my Linux).

The major change (as seen with flo) for Instantbird is the class nsIDOMWindowInternal that was renamed nsIDOMWindow. The  patch reflect this to make it easy to understand.

I'll see if I can provide a patch for Mozilla 9.0 after this one.
Attachment #8352729 - Flags: review?(florian)
*** Original post on bio 1161 at 2011-11-12 17:15:59 UTC ***

Changing bug title to be more explicit. I tend to say "mozilla" because of the repository name. But "XUL" is a lot easier to understand.
Summary: Update mozilla from 7.0.1 to 9.0 → Update XUL from 7.0.1 to 9.0
Attached patch XUL 8.0 => 9.0b1 (obsolete) — Splinter Review
*** Original post on bio 1161 as attmnt 988 at 2011-11-12 17:18:00 UTC ***

This patch is a first try to get this done. It's still very early stage.  I put it there to prevent any loss and allow everyone to earn some time. I have an Ib using it so it at least works.
*** Original post on bio 1161 at 2011-11-12 18:02:50 UTC ***

Just to help understand what has been done. I merged configure.in, build.mk and config/* from comm central to our trunk. There are still some issues there with paths I suppose. In some changes I see there are paths that change from mozilla/ to root. I believe this should be reversed.

I also made some little corrections in idl files to change "[readonly]" to "readonly" since it seems it is appropriate with the new python idl parser. I also had to change aclocal.m4 to remove the IDL include.

I also changed a minTRayR implementation accordingly to the changes made on the parser (it was more a change on the printer for this but... whatever).

I compiled my version without the changes in configure.in and build.mk. I don't know what this implies right now.
Attached patch XUL 8.0 => 9.0b1 (obsolete) — Splinter Review
*** Original post on bio 1161 as attmnt 989 at 2011-11-12 18:03:00 UTC ***

Correct some path issues in client.mk. That should work a lot better now.
Comment on attachment 8352730 [details] [diff] [review]
XUL 8.0 => 9.0b1

*** Original change on bio 1161 attmnt 988 at 2011-11-12 18:03:43 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352730 - Attachment is obsolete: true
*** Original post on bio 1161 as attmnt 990 at 2011-11-12 18:06:00 UTC ***

Still another path issue remaining in client.mk. I'm really tired...
Comment on attachment 8352731 [details] [diff] [review]
XUL 8.0 => 9.0b1

*** Original change on bio 1161 attmnt 989 at 2011-11-12 18:06:27 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352731 - Attachment is obsolete: true
Attached patch use --with-ccache (obsolete) — Splinter Review
*** Original post on bio 1161 as attmnt 991 at 2011-11-12 18:14:00 UTC ***

This little patch is only to improve the mozconfig file of the linux buildbot. It need to be tested properly and is away because it is not really the immediate purpose of this bug.
*** Original post on bio 1161 at 2011-11-12 19:18:53 UTC ***

(In reply to comment #0)
> Created an attachment (id=987) [details]
> Firefox 7.0.1 => Firefox 8.0

First thing I noticed is that Mozilla 8.0 requires ANGLE on Windows so we'll need to install the DirectX SDK. The actual error message is:
> configure: error: Couldn't find the DirectX SDK, needed for ANGLE. Please
> install it (June 2010 or newer). To explicitly build without ANGLE, reconfigure
> with --disable-angle.

I'm lazy and am choosing the disable-angle path, this is mostly just a heads up for anyone wanting to compile on their own machine without installing more stuff, Even said (on IRC) that there is some version of the DirectX SDK installed on the buildbot slave already.
*** Original post on bio 1161 at 2011-11-12 19:31:43 UTC ***

This looks more complicated than that in fact. We do have an issue with the win32 buildbot. It has the Frebruary 2010 SDK while ANGLE requires at least the June 2010 DirectX SDK.

The June 2010 DirectX SDK is not compatible with VS 2005 and requires 2008 or 2010. I do have a 2010 installer somewhere though. I'll prepare a new win7 VM with a recent Direct X SDK and VS 2010 to replace the actual one.

I opened bug #954595 (bio 1163) about this.

I suppose we can use --disable-angle too on the win32 buildbot for the time being.
Depends on: 954595
Comment on attachment 8352729 [details] [diff] [review]
XUL 7.0.1 => XULL 8.0

*** Original change on bio 1161 attmnt 987 at 2011-11-12 20:31:07 UTC ***

I just renamed the patch and corrected the description to follow the title changes.
Attachment #8352729 - Attachment description: Firefox 7.0.1 => Firefox 8.0 → XUL 7.0.1 => XULL 8.0
Attachment #8352729 - Attachment filename: firefox_8_0.patch → xul_8_0.patch
*** Original post on bio 1161 at 2011-11-12 21:00:12 UTC ***

For those interested in testing, I recall the proper steps to to this without making something wrong.

First, checkout the last Ib codebase (or update your current tree). Then, apply my patch(es).

Then, to update the xul codebase, execute
python client.py --skip-instantbird -C checkout

You can compile without breaking anything using:
MOZCONFIG=/absolute/path/to/your/mozconfig make -f client.mk build

You have a default mozconfig file in tools/buildbot-config/<YOU_OS>/mozconfig. It will compile using the nightlies options. You can use the mozconfig-release version to get the release default options.
Attached patch use --with-ccache (v2) (obsolete) — Splinter Review
*** Original post on bio 1161 as attmnt 993 at 2011-11-12 21:02:00 UTC ***

I forgot to fix the release mozconfig related to this. Here is a completed patch.
Comment on attachment 8352733 [details] [diff] [review]
use --with-ccache

*** Original change on bio 1161 attmnt 991 at 2011-11-12 21:02:55 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352733 - Attachment is obsolete: true
*** Original post on bio 1161 as attmnt 994 at 2011-11-12 21:04:00 UTC ***

I forgot a . when generating the previous patch... Silly me.
Comment on attachment 8352735 [details] [diff] [review]
use --with-ccache (v2)

*** Original change on bio 1161 attmnt 993 at 2011-11-12 21:04:22 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352735 - Attachment is obsolete: true
Attached patch XUL 7.0.1 => XUL 8.0 (v2) (obsolete) — Splinter Review
*** Original post on bio 1161 as attmnt 996 at 2011-11-15 10:22:00 UTC ***

Replace remaining occurences of "nsIDOMWindowInternal" by "nsIDOMWindow".
Attachment #8352738 - Flags: review?(florian)
Comment on attachment 8352729 [details] [diff] [review]
XUL 7.0.1 => XULL 8.0

*** Original change on bio 1161 attmnt 987 at 2011-11-15 10:22:56 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352729 - Attachment is obsolete: true
Attachment #8352729 - Flags: review?(florian)
*** Original post on bio 1161 as attmnt 997 at 2011-11-15 10:53:00 UTC ***

I forgot to re-add the modifications of client.py to the new patch. Here is a corrected version... Sorry, I'm always making a mess. I really should be more careful.
Attachment #8352739 - Flags: review?(florian)
Comment on attachment 8352738 [details] [diff] [review]
XUL 7.0.1 => XUL 8.0 (v2)

*** Original change on bio 1161 attmnt 996 at 2011-11-15 10:53:35 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352738 - Attachment is obsolete: true
Attachment #8352738 - Flags: review?(florian)
*** Original post on bio 1161 at 2011-11-15 13:39:57 UTC ***

Comment on attachment 8352732 [details] [diff] [review] (bio-attmnt 990)
XUL 8.0 => 9.0b1 (v3)

I had a private discussion about this patch with Quentin this morning, here are the interesting points to remember:

* This addition doesn't seem wanted: $(wildcard $(TOPSRCDIR)/ldap/sdks/c-sdk/configure)

* The removal of the rule check-valgrind: doesn't seem wanted (I think it was added to start and valgrind libpurple without starting the UI).

* These patches are now part of the mozilla code, so we no longer need them:
tools/patches/Bug-665819-build-fix-for-ENABLE_YARR_JIT-0-r-dmandel.patch
tools/patches/Bug-670719-Only-add-DENABLE_JIT-1-to-CXXFLAGS-if-any.patch
tools/patches/fix-ppc-universal-builds-backout-600433.patch

* Unwanted additions:
SUNBIRD_VERSION=`cat $topsrcdir/calendar/sunbird/config/version.txt`
SEAMONKEY_VERSION=`cat $topsrcdir/suite/config/version.txt`

* This should be adapted:
"echo "Building Thunderbird by default. Set --enable-application to build a different application."
MOZ_BUILD_APP=mail

* The removal of --enable-debugger-info-modules breaks one of our wince mozconfig. I don't think we care.

* This part doesn't seem useful: if test -z "$MOZ_MAIL_NEWS"; then
(but the whole if test "$MOZ_LDAP_XPCOM"; then part immediately after it which was already there doesn't seem any more useful)

* The indent in instantbird/components/mintrayr/trayIToolkit.idl is bad. Fixing the [readonly] attributes may be an opportunity to also fix it.

* The reason why Quentin added relativesrcdir = purple/purplexpcom/src in that folder's Makefile is that setting this variable now seems to be required when XPCSHELL_TESTS is set. We should check that the tests can still be found after applying this patch, as Quentin hasn't tested this at all.

* Updating configure.in without also updating autoconf.mk.in at the same time seems very dangerous to me.

Other changes look good :) (and thanks for working on this!)
OS: Linux → All
Hardware: x86 → All
Comment on attachment 8352736 [details] [diff] [review]
use --with-ccache (v2)

*** Original change on bio 1161 attmnt 994 at 2011-11-20 02:14:16 UTC ***

I don't think you intended to remove the -j4 flag.
Attachment #8352736 - Flags: review-
Comment on attachment 8352739 [details] [diff] [review]
XUL 7.0.1 => XUL 8.0 (v3)

*** Original change on bio 1161 attmnt 997 at 2011-11-20 02:19:39 UTC ***

Looks good, thanks!

I've just pushed this as https://hg.instantbird.org/instantbird/rev/535bf71528c9 with tools/patches/Bug-665819-build-fix-for-ENABLE_YARR_JIT-0-r-dmandel.patch removed and an update of the other patches.
Attachment #8352739 - Flags: review?(florian) → review+
*** Original post on bio 1161 at 2011-11-20 11:08:23 UTC ***

(In reply to comment #15)

> * The removal of the rule check-valgrind: doesn't seem wanted (I think it was
> added to start and valgrind libpurple without starting the UI).

Actually, this is OK as an $(EXTRA_TEST_ARGS) variable was added to the check-one rule.

> * These patches are now part of the mozilla code, so we no longer need them:
> tools/patches/Bug-665819-build-fix-for-ENABLE_YARR_JIT-0-r-dmandel.patch
This patch was already included in Mozilla8, so I removed it in my previous push.

> tools/patches/Bug-670719-Only-add-DENABLE_JIT-1-to-CXXFLAGS-if-any.patch
This patch is included in Mozilla9, so it should be removed when updating to moz9.

> tools/patches/fix-ppc-universal-builds-backout-600433.patch
This patch isn't and won't be in mozilla-central.
*** Original post on bio 1161 at 2011-11-20 12:46:01 UTC ***

(In reply to comment #18)

> > tools/patches/fix-ppc-universal-builds-backout-600433.patch
> This patch isn't and won't be in mozilla-central.

Actually, we no longer need this hack because that whole area of the code was cleaned-up in bio 683441.
*** Original post on bio 1161 as attmnt 1010 at 2011-11-20 12:56:00 UTC ***

I pushed the update to Mozilla9 as http://hg.instantbird.org/instantbird/rev/6fcc43e5956c

This changeset is based on attachment 8352732 [details] [diff] [review] (bio-attmnt 990) (+994), I addressed the issues listed in comment 15 and comment 16, updated the patches, and cleaned up a bit more configure.in and config/autoconf.mk.in.

I'm attaching the interdiff between attachment 8352732 [details] [diff] [review] (bio-attmnt 990) and what I pushed.
*** Original post on bio 1161 at 2011-11-20 22:34:17 UTC ***

Follow-ups:
https://hg.instantbird.org/instantbird/rev/b61ab282a10b - fix xpcshell tests (debug builds only)
https://hg.instantbird.org/instantbird/rev/1aec50008efb - Use 9.0b2 instead of 9.0b1
https://hg.instantbird.org/instantbird/rev/0e6f1f47bce9 - fix compilation of the JS engine on PPC.
https://hg.instantbird.org/instantbird/rev/6a56836b8d98 - fix twitter / the initLogModule function of imXPCOMUtils.jsm for compatibility with Mozilla 8+.

Resolving as FIXED as we have had at least one green onCommit build on each OS since the push of the update to Mozilla 9.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.2
*** Original post on bio 1161 at 2011-11-21 09:33:33 UTC ***

I reopen this bug because I believe there is a new problem related. Since I updated Ib this morning, I can't start it on win32. I get an error saying basially that "mozutils.dll" is not found. I tried to use the installer to correct the problem, thinkiong it might have been an update issue. The problem persisted. I think there is a small packaging issue at hand here. We tested everything but the packaging process...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Original post on bio 1161 as attmnt 1011 at 2011-11-21 09:56:00 UTC ***

On the 20111120062539 build (Gecko 8.0) a new bug appeared with the bubble rendering. When talking to someone, after a reply it is sometime broken as seen on the screenshot, sometimes it looks normal. Seems the bug disappear / appear only when the bubble alternates between different colors. I'm not sure though. I believe this is a regression between XUL 7 to XUL 8. Might have been corrected on XUL 9. It would be better to test a new functional build on XUL 9 before looking to hard on this. I wanted to report the issue though.
*** Original post on bio 1161 at 2011-11-21 10:47:41 UTC ***

Another new issue: Opening the add-on manager produces

Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch2.getBoolPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: resource://gre/modules/AddonManager.jsm :: <TOP_LEVEL> :: line 1041"  data: no]

Once for each installed add-on I believe.
*** Original post on bio 1161 at 2011-11-21 11:52:01 UTC ***

(In reply to comment #22)
> [...] "mozutils.dll" is not found.

Bug 954611 (bio 1179) has been filed on this issue.
Depends on: 954611
*** Original post on bio 1161 at 2011-11-21 11:59:19 UTC ***

(In reply to comment #23)
> Created attachment 8352754 [details] (bio-attmnt 1011) [details]
> Bug o, bubbles (at least on Win32)
> 
> On the 20111120062539 build (Gecko 8.0) a new bug appeared with the bubble
> rendering.

Mic has talked about this issue too yesterday in IRC. Someone should file a separate bug to track this issue, then investigate: does it also happens with graphic acceleration disabled? Is it possible to write a reduced testcase that also shows the bug on Firefox? Is it fixed in current Firefox nightlies? If so, can we find by which patch, and add it to the patches we apply in our builds? If not, file a Mozilla bug and attach the reduced testcase. If possible, try to find a regression range...
*** Original post on bio 1161 at 2011-11-21 12:00:24 UTC ***

(In reply to comment #24)
> Another new issue: Opening the add-on manager produces
> 
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch2.getBoolPref]"  nsresult:
> "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
> resource://gre/modules/AddonManager.jsm :: <TOP_LEVEL> :: line 1041"  data: no]
> 
> Once for each installed add-on I believe.

I can't reproduce. Is this significantly breaking the UI? Anyway, please file a new bug to track this (and mark as blocking this one if you feel it's related).
Depends on: 954612
Depends on: 954614
Depends on: 954615
Depends on: 954616
*** Original post on bio 1161 at 2012-01-27 10:43:34 UTC ***

Seems that this was fixed with a later XUL update. I'm closing this one. Please fill free to open a separate bug if this still happens to you.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Assignee: nobody → bugzilla
You need to log in before you can comment on or make changes to this bug.