Eclipse crashes using content assist with libcairo2 1.8.10

Bug #531719 reported by Tristan Tarrant on 2010-03-04
146
This bug affects 27 people
Affects Status Importance Assigned to Milestone
XULRunner
Fix Released
Medium
eclipse (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned
xulrunner-1.9.1 (Ubuntu)
Low
Unassigned
Lucid
Undecided
Unassigned
xulrunner-1.9.2 (Ubuntu)
High
Unassigned
Lucid
Undecided
Unassigned

Bug Description

Binary package hint: xulrunner

The recent upgrade to libcairo2-1.8.10-2ubuntu1 exposes a bug in xulrunner 1.9.1 (the upstream bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=522635).
In the case of Eclipse, this causes a crash when the extra documentation popup disappears from the right of the content-assist popup menu (i.e. when an item is selected and the menu is no longer needed).
If I set the environment variable GRE_HOME to some nonsense path, Eclipse works fine (it uses a simpler rendering technique for the documentation window).
Installing xulrunner 1.9.2 (I used the mozilla-daily ppa) fixes the problem. Since several packages depend on xulrunner (yelp, couchdb-bin, eclipse-platform, miro, libgjs0, gnome-shell, etc) it would be advisable to upgrade xulrunner to prevent the bug from appearing in the LTS.

ProblemType: Bug
Architecture: amd64
Date: Thu Mar 4 05:26:48 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release Candidate amd64 (20091020.3)
NonfreeKernelModules: nvidia
Package: xulrunner (not installed)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-15.22-generic
SourcePackage: xulrunner
Uname: Linux 2.6.32-15-generic x86_64

Download full text (6.8 KiB)

The cairo surface being destroyed is using the window for the drawable, and is
releasing the dst_picture

http://hg.mozilla.org/mozilla-central/annotate/4046f3843bdb/gfx/cairo/cairo/src/cairo-xlib-surface.c#l296

(gdb) f 6
#6 0x00007f8fc6d8a2c2 in _cairo_xlib_surface_finish (
    abstract_surface=0x7f8f8ee56400)
    at /home/karl/moz/dev/gfx/cairo/cairo/src/cairo-xlib-surface.c:341
(gdb) p *surface
$376 = {base = {backend = 0x7f8fc70987e0, type = CAIRO_SURFACE_TYPE_XLIB,
    content = CAIRO_CONTENT_COLOR, ref_count = {ref_count = 0},
    status = CAIRO_STATUS_SUCCESS, finished = 0, user_data = {size = 1,
      num_elements = 1, element_size = 24, elements = 0x7f8f8eee7438,
      is_snapshot = 0}, mime_data = {size = 0, num_elements = 0,
      element_size = 24, elements = 0x0, is_snapshot = 0},
    device_transform = {xx = 1, yx = 0, xy = 0, yy = 1, x0 = 0, y0 = 0},
    device_transform_inverse = {xx = 1, yx = 0, xy = 0, yy = 1, x0 = -0,
      y0 = -0}, x_resolution = 72, y_resolution = 72,
    x_fallback_resolution = 300, y_fallback_resolution = 300,
    clip = 0x7f8f8f0d9260, next_clip_serial = 1, current_clip_serial = 1,
    is_snapshot = 0, has_font_options = 0, font_options = {
      antialias = 2779096485, subpixel_order = 2779096485,
      hint_style = 2779096485, hint_metrics = 2779096485}},
  dpy = 0x7f8fcd151000, display = 0x7f8fac641c10,
  screen_info = 0x7f8fac6163d0, close_display_hook = {prev = 0x7f8f9bfdb520,
    next = 0x7f8f8ed5cd20,
    func = 0x7f8fc6d8f5f2 <_cairo_xlib_surface_detach_display>},
  gc = 0x7f8f8ef0ea60, drawable = 44044608, screen = 0x7f8fcd139180,
  owns_pixmap = 0, visual = 0x7f8fcd11f470, use_pixmap = 0, render_major = 0,
  render_minor = 10, buggy_repeat = 0, width = 1069, height = 619,
  depth = 24, dst_picture = 44045647, src_picture = 0, clip_dirty = 0,
  have_clip_rects = 0, gc_has_clip_rects = 0, embedded_clip_rects = {{x = 0,
      y = 0, width = 1069, height = 619}, {x = -23131, y = -23131,
      width = 42405, height = 42405}, {x = -23131, y = -23131, width = 42405,
      height = 42405}, {x = -23131, y = -23131, width = 42405,
      height = 42405}, {x = -23131, y = -23131, width = 42405,
      height = 42405}, {x = -23131, y = -23131, width = 42405,
      height = 42405}, {x = -23131, y = -23131, width = 42405,
      height = 42405}, {x = -23131, y = -23131, width = 42405,
      height = 42405}}, clip_rects = 0x7f8f8ee5659c, num_clip_rects = 0,
  xrender_format = 0x7f8fcd0fc940, filter = CAIRO_FILTER_NEAREST, repeat = 0,
  xtransform = {matrix = {{65536, 0, 0}, {0, 65536, 0}, {0, 0, 65536}}},
  a_mask = 0, r_mask = 16711680, g_mask = 65280, b_mask = 255}

The drawable of that surface is the Window of the nsIWidget being destroyed
but that Window has already been destroyed, probably when a parent nsIWidget
was destroyed:

http://hg.mozilla.org/mozilla-central/annotate/4046f3843bdb/widget/src/gtk2/nsWindow.cpp#l760

(gdb) f 13
#13 0x00007f8fc6311441 in nsWindow::Destroy (this=0x7f8fa9cd2ba0)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:790
(gdb) p *(GdkWindowObject*)mGdkWindow
$386 = {parent_instance = {parent_instance = {g_type_instance = {
        g_cla...

Read more...

Also affects
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b1pre) Gecko/20091014 Namoroka/3.6b1pre

I can consistently trigger this bug using the steps in this bug in:
Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.1.3) Gecko/20090928 Iceweasel/3.5.3
using cairo 1.9.4 but I can not trigger it using cairo 1.8.8
What cairo version are you using?

See this bug:
http://bugs.freedesktop.org/show_bug.cgi?id=21583

This looks like a Cairo bug. Jeff, can you take responsibility for rolling in the fix to the fd.o bug Roberto posted above?

(In reply to comment #4)
> This looks like a Cairo bug. Jeff, can you take responsibility for rolling in
> the fix to the fd.o bug Roberto posted above?

Yes.

Doesn't crash for me using the steps in comment #1.

Linux x64, namoroka nightly 20091029061700

Still happens for me x86_64 nightly built from
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/61e9a14a8819

(In reply to comment #4)
> This looks like a Cairo bug. Jeff, can you take responsibility for rolling in
> the fix to the fd.o bug Roberto posted above?

The fd.o bug is for bug 263160, which is unrelated to this bug, but that report contains a number of comments about this bug.

This bug is a bug in Gecko. Gecko is creating a cairo xlib surface wrapper around a Window, but destroying the Window before destroying the wrapper.

Evidence suggests that the crash has been triggered (or at least made more likely) by a change in cairo. However, even if we back out that change in our cairo, this bug will resurface when distros update their cairos.

(In reply to comment #3)
> I can consistently trigger this bug using the steps in this bug in:
> Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.1.3) Gecko/20090928
> Iceweasel/3.5.3
> using cairo 1.9.4 but I can not trigger it using cairo 1.8.8
> What cairo version are you using?

Mozilla 1.9.2 uses a cairo based on b71b019fe50a9188ddbecd1945606da8ba3bad53

http://hg.mozilla.org/releases/mozilla-1.9.2/file/61e9a14a8819/gfx/cairo/cairo/src/cairo-features.h.in
claims this is 1.7.4 but that must be wrong.

Created an attachment (id=409402)
destroy child nsWindows when destroying the parent

This seems to fix the problem. It makes sense to me to destroy descendant
nsWindows when their native Windows are getting destroyed, and I think this
behavior might resemble the OnDestroy behavior of windows\nsWindow.cpp.

Though the question is begged:
Why hold a reference mThebesSurface to the surface if it will be recreated
each time it is used anyway?

The "we should fix this at some point" comment was removed here:
http://hg.mozilla.org/mozilla-central/rev/ef0221c2a188#l12.606

The fix with the smallest change looks like it is to just remove
mThebesSurface. (But ensuring child nsWindows are Destroy()ed might enable us to reuse mThebesSurface at some point.)

(From update of attachment 409402)
This seems sensible to me for m-c, at least.

(In reply to comment #10)
> Though the question is begged:

Sorry to be pedantic, but this is an incorrect use of the phrase "begging the question" :-)

"Arguments over whether such usage should be considered incorrect are an example of debate over linguistic prescription and description."
http://en.wikipedia.org/wiki/Begging_the_question#Modern_usage

I should be able to come up with a (browser?) crashtest-mochitest for this I expect.

Please either land with that crashtest or file a follow up to get the tests done.

FWIW, this fix (+ bug 506433) is not enough to stop 1.9.1 "crashing" with system cairo 1.8.10, though it "crashes" less often. I'm currently trying to build 1.9.2 to see if I can reproduce there in which case I may need to backport more, or if that still happens.

Seems bug 528386 is what I was missing.

*** Bug 542173 has been marked as a duplicate of this bug. ***

Created an attachment (id=429069)
(Big) patch for 1.9.1

FWIW, this is what I apply on 1.9.1, which is a combination of (backported) bug 506433, bug 522635 and bug 528386. (I thought reducing the number of gdkwindows was a worthwhile change)

Binary package hint: xulrunner

The recent upgrade to libcairo2-1.8.10-2ubuntu1 exposes a bug in xulrunner 1.9.1 (the upstream bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=522635).
In the case of Eclipse, this causes a crash when the extra documentation popup disappears from the right of the content-assist popup menu (i.e. when an item is selected and the menu is no longer needed).
If I set the environment variable GRE_HOME to some nonsense path, Eclipse works fine (it uses a simpler rendering technique for the documentation window).
Installing xulrunner 1.9.2 (I used the mozilla-daily ppa) fixes the problem. Since several packages depend on xulrunner (yelp, couchdb-bin, eclipse-platform, miro, libgjs0, gnome-shell, etc) it would be advisable to upgrade xulrunner to prevent the bug from appearing in the LTS.

ProblemType: Bug
Architecture: amd64
Date: Thu Mar 4 05:26:48 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release Candidate amd64 (20091020.3)
NonfreeKernelModules: nvidia
Package: xulrunner (not installed)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-15.22-generic
SourcePackage: xulrunner
Uname: Linux 2.6.32-15-generic x86_64

Micah Gersten (micahg) wrote :

Thank you for reporting this. We will be releasing xulrunner-1.9.2 into Lucid before the release. Please report any other bugs you may find.

affects: xulrunner (Ubuntu) → xulrunner-1.9.1 (Ubuntu)
Changed in xulrunner-1.9.1 (Ubuntu):
assignee: nobody → Micah Gersten (micahg)
importance: Undecided → Medium
milestone: none → ubuntu-10.04-beta-1
status: New → Triaged
importance: Medium → High
Kristian Rink (kawazu) wrote :

Are there any workarounds known for that so far?

Aren't the two methods I explained in my first comment working for you ?

gronbaek (gronbaek) wrote :

I have followed Tristan's advice and have added the mozilla.daily ppa to my repositories and installed xul-runner 1.9.3. This works for me. If you experience the same problems, try to make sure that Eclipse is using xul-runner 1.9.3, and not your default version, by running Eclipse with the xul-runner path specified: "eclipse -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/bin/xulrunner-1.9.3"

Micah Gersten (micahg) on 2010-03-07
summary: - Eclipse crashes on content assist
+ Eclipse crashes with xulrunner-1.9.1
summary: - Eclipse crashes with xulrunner-1.9.1
+ Eclipse crashes using content assist
summary: - Eclipse crashes using content assist
+ Eclipse crashes using content assist with libcairo2 1.8.10
Changed in xulrunner:
status: Unknown → Fix Released
Andrea Chiavazza (andrea-c7a) wrote :

Setting GRE_HOME=. works for me.

dl.zerocool (dl.zerocool) wrote :

Followed this : https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/531719/comments/26
and it worked, but very annoying... Hope it will be soon solved.

Now that xulrunner -1.9.2 replaces 1.9.1 everything is fine again, thanks!
https://launchpad.net/ubuntu/lucid/+source/xulrunner-1.9.2/1.9.2+nobinonly-0ubuntu1

Fixed for me.

I have followed Tristan's advice also and it works fine with xulrunner 1.9.3. It does not work with the xulrunner that was shipped today (i.e. xulrunner-1.9.1.9pre)

Andrea Chiavazza (andrea-c7a) wrote :

The 1.9.2 update fixed it for me too.

Olaf Krische (public-ecopatz) wrote :

Update today fixed it for me too.

Micah Gersten (micahg) wrote :

We'll be rebuilding eclipse against xulrunner-1.9.2 soon which should fix this for everyone in Lucid.

Changed in xulrunner-1.9.2 (Ubuntu):
importance: Undecided → High
status: New → Fix Released
Changed in xulrunner-1.9.1 (Ubuntu):
assignee: Micah Gersten (micahg) → nobody
milestone: ubuntu-10.04-beta-1 → none
Andrea Chiavazza (andrea-c7a) wrote :

if the patch released fixes the bug for me should I set the bug as "not affecting me" ?
Does it make any difference to people keeping track of bugs ?

Shouldn't make a difference in this case as xulrunner-1.9.1 most likely
will not be patched for this.

On 03/11/2010 06:50 PM, Andrea Chiavazza wrote:
> if the patch released fixes the bug for me should I set the bug as "not affecting me" ?
> Does it make any difference to people keeping track of bugs ?
>
>

fejes (anthony-fejes) wrote :

I seem to have had both 1.9 and 1.9.2 installed: (Tested with "dpkg -l xulrunner*")

ii xulrunner-1.9 1.9.0.14+build2+nobinonly-0ubuntu1 XUL + XPCOM application runner
ii xulrunner-1.9-gnome-support 1.9.0.14+build2+nobinonly-0ubuntu1 Support for Gnome in xulrunner-1.9 applications
rc xulrunner-1.9.1 1.9.1.8+build1+nobinonly-0ubuntu1 XUL + XPCOM application runner
un xulrunner-1.9.1-gnome-support <none> (no description available)
ii xulrunner-1.9.2 1.9.2+nobinonly-0ubuntu1 XUL + XPCOM application runner

Removing 1.9 fixed the problem for me:

 sudo apt-get remove xulrunner-1.9

Andrew Cowie (afcowie) wrote :

Removing xulrunner-1.9.1 along the lines as suggested in comment #36 fixed the problem here. Upgrading to eclipse 3.5.2-2 did *not*.

AfC

(From update of attachment 429069)
Would it be possible to get this on 1.9.1? We have this issue with Seamonkey in Lucid.

(In reply to comment #22)
> (From update of attachment 429069 [details])
> Would it be possible to get this on 1.9.1? We have this issue with Seamonkey
> in Lucid.

This will probably impact Fedora 13 which is due out in May too.

Micah Gersten (micahg) wrote :

No longer high since xulrunner-1.9.1 was dropped from Lucid and < Lucid has cairo2 < 1.8.10

Changed in xulrunner-1.9.1 (Ubuntu):
importance: High → Low

(From update of attachment 429069)
This is a really big patch, and a backport of all of those other bugs would require them to be nominated to land on mozilla-1.9.1 as well.

Is there a way to get a more minimal fix? Right now I think the risk outweighs the potential reward, here.

If this regressed after 1.9.1.3, can we figure out what regressed it and maybe back that out?

(In reply to comment #25)
> If this regressed after 1.9.1.3, can we figure out what regressed it and maybe
> back that out?

I think the change was in the system cairo.

(In reply to comment #24)
> Is there a way to get a more minimal fix?

Removing mThebesSurface would be a safe minimal fix for branch (Comment 10).

If someone knows a reliable way to reproduce, please let me know.
I've had trouble writing a test for this because the site changed and I haven't come up with another way to reproduce.

*** Bug 510867 has been marked as a duplicate of this bug. ***

Can we get the minimal fix from comment 10 applied to 1.9.1? This is affecting Seamonkey on Fedora 13 and other recent distributions. See bug 557785.

Can someone point me at the patch? I need to backport it to Fedora 11 for OLPC.

Yes, we ship really old stuff :-(

(In reply to comment #30)
> Can someone point me at the patch? I need to backport it to Fedora 11 for OLPC.
>
> Yes, we ship really old stuff :-(

As far as I am aware Fedora 11 doesn't ship with a system cairo 1.8.10+ (I believe it is 1.8.8 which is not affected).

(In reply to comment #31)

> As far as I am aware Fedora 11 doesn't ship with a system cairo 1.8.10+ (I
> believe it is 1.8.8 which is notnot affected).

You're right, F-11 is not affected. We're seeing the issue only on Fedora 13.

Benjamin Drung (bdrung) wrote :

Having xulrunner-1.9.1 installed breaks eclipse. Letting eclipse conflict with xulrunner-1.9.1 is a workaround (patch attached).

Changed in eclipse (Ubuntu Lucid):
status: New → Fix Committed
Benjamin Drung (bdrung) wrote :

xulrunner-1.9.2 should remove xulrunner-1.9.1, which isn't part of lucid any more.

Martin Pitt (pitti) wrote :

What's left to do for SRU here? Comment 50 should not apply any more, since xulrunner 1.9.1 is not in lucid. I'll close that task.

Changed in xulrunner-1.9.1 (Ubuntu):
status: Triaged → Invalid
Changed in xulrunner-1.9.1 (Ubuntu Lucid):
status: New → Invalid
Changed in xulrunner-1.9.2 (Ubuntu Lucid):
status: New → Fix Released
Martin Pitt (pitti) wrote :

eclipse was rebuilt in maverick, so I take it this is not an issue in maverick?

What remains to be done for the "fix committed" lucid eclipse task?

Changed in eclipse (Ubuntu):
status: New → Fix Released
Martin Pitt (pitti) wrote :

Ah, I just saw the eclipse upload to lucid-proposed. However, this seems wrong to me, since it's not really eclipse's fault (and also we should avoid such a huge download which essentially changes nothing for most users).

So if the problem is that some people still have the old 1.9.1 installed, then I'd rather see the conflict being added to xulrunner-1.9.2 for proper cleanup. This will benefit more people, and it's a "more correct" place than eclipse IMHO.

Changed in eclipse (Ubuntu):
status: Fix Released → Triaged
Benjamin Drung (bdrung) wrote :

OK. xulrunner-1.9.2 should conflict with xulrunner-1.9.1 to get it removed.

Jonathan Riddell (jr) wrote :

rejecting eclipse upload from lucid-proposed Unapproved queue

As far as I can tell, this bug is responsible for 30-50 Seamonkey 2.0.x crash reports in Fedora 13 (seamonkey-2.0.6-1.fc13, cairo-1.8.10-1.fc13).

Seamonkey crashes often
https://bugzilla.redhat.com/show_bug.cgi?id=602437

This bug is marked RESOLVED. If I understand correctly, it was fixed in Gecko 1.9.2, but was not fixed in Gecko 1.9.1, and Seamonkey 2.0.x is built on the older Gecko? Is that correct?

Is this the appropriate place to discuss the problem, or should I file a new bug for Seamonkey, pointing to this bug?

That sounds correct and this is the right place to discuss.
IIRC, a patch that removed mThebesSurface from nsWindow would fix this.

While I agree with comment 24, I'd just like to point out that tens of thousands of Debian users have been using the mentioned patch for six months without any bad feedback.

I have opened bug 591503 in which I describe two methods that crash Seamonkey consistently for me. I can provide stack traces of the other running threads if necessary.

*** Bug 591503 has been marked as a duplicate of this bug. ***

(In reply to comment #37)
> *** Bug 591503 has been marked as a duplicate of this bug. ***

Karl,

The back trace you provide in your original report is different from the one I attached in bug 591503. Are you confident it is the same bug?

AFAIU, bug 522635 was RESOLVED FIXED on the gecko trunk, which means gecko 1.9.2.x contains the fix, but the 1.9.1 branch still has the flaw. Should this bug be REOPENED with Version set to "1.9.1 branch" or should bug 591503 be used to track the progress of fixing the 1.9.1 branch?

(In reply to comment #38)
> The back trace you provide in your original report is different from the one I
> attached in bug 591503. Are you confident it is the same bug?

The one attached to bug 591503 is not from running the app with --sync and doesn't have enough information to confirm it is the same bug.

But I'm confident that Gecko 1.9.1 with system-cairo > 1.8.8 will display this bug.

> Should this
> bug be REOPENED with Version set to "1.9.1 branch" or should bug 591503 be used
> to track the progress of fixing the 1.9.1 branch?

Neither. This bug will track the status on 1.9.1 branch until the status-1.9.1 flag changes.

(In reply to comment #39)
> The one attached to bug 591503 is not from running the app with --sync and
> doesn't have enough information to confirm it is the same bug.

I've attached a new back trace to bug 591503 running with --sync

(I don't know if it's relevant) In your back trace, the nsView destructor is called by nsIView::Destroy (frames #14 - #15), whereas in mine, the nsView destructor is called by the nsScrollPortView destructor (frames #21 - #22).

> Neither. This bug will track the status on 1.9.1 branch until the
> status-1.9.1 flag changes.

If I understand correctly, "status1.9.2: beta3-fixed" means this bug was fixed for gecko 1.9.2 in version beta-3. Is that correct?

And when (one can dream, right?) it is fixed for gecko 1.9.1, the status will be changed to something like "status1.9.1: 13-fixed" ?

RESOLVED FIXED only means the bug is fixed on the trunk?

(In reply to comment #40)
> And when (one can dream, right?) it is fixed for gecko 1.9.1, the status will
> be changed to something like "status1.9.1: 13-fixed" ?
>
> RESOLVED FIXED only means the bug is fixed on the trunk?

Yes, that's right.

Karl,

Is fixing this bug (on the 1.9.1 branch) an item on one of your TODO lists for the coming weeks?

No. I'll review a patch if someone puts one up.
Or distros can apply Mike's patch if they are using system cairo.

Changed in xulrunner:
importance: Unknown → Medium

I'm confused: I downloaded the Linux/x86_64 version of Seamonkey 2.0.7 from the project's page. (Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100825 SeaMonkey/2.0.7)

I ran ldd on Fedora's seamonkey-bin and on Mozilla's seamonkey-bin; they link exactly to the same dynamic libraries (only the addresses changes).

For example, the three relevant (I think) libraries:

Fedora:
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f46a58b0000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f46a5665000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f46a53ec000)

Mozilla:
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f91d1364000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f91d1119000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f91d0ea0000)

/usr/lib64/libcairo.so.2 is system cairo, right?

Both versions seem to link the same cairo library, yet Fedora's version crashes, while Mozilla's version does not. How would one explain this?

Yes, both versions are linked to cairo as a consequence of linking to GTK. However, the Mozilla build is still using it's internal tree cairo.

Created attachment 481492
minimal branch patch

Karl,

Will Martin's proposed fix now land on the gecko 1.9.1 branch?
Or does it still need super-review?
(If so, from who? roc? vladimir? someone else?)

I must be missing something. Martin's proposed fix is tiny compared to Mike Hommey's patch. Do they both fix the problem in gecko 1.9.1?

What does Mike's patch do that Martin's patch doesn't?

(In reply to comment #48)
> I must be missing something. Martin's proposed fix is tiny compared to Mike
> Hommey's patch. Do they both fix the problem in gecko 1.9.1?
>
> What does Mike's patch do that Martin's patch doesn't?

See comment 21 and comment 26.

Comment on attachment 481492
minimal branch patch

Requesting approval for 1.9.1, mostly for SeaMonkey on distributions that build with system cairo.

It's a small patch, but changes semantics a little.

With XPCOM's ref-counting system, objects typically need to be AddRefed and Released to be deleted. Without this patch nsWindow would do this and so the object would get deleted even if the caller did not. With this patch callers must AddRef and Release.

The change actually makes the behavior consistent with cocoa and winnt's GetThebesSurface().

I checked that existing callers (in 1.9.1 mozilla-central) AddRef and Release.

nsBaseWidget::GetRenderingContext()
  > nsThebesRenderingContext::Init(nsIDeviceContext*, gfxASurface*)
    > gfxContext

nsThebesDeviceContext::CreateRenderingContext()

nsThebesRenderingContext::Init(nsIDeviceContext*, nsIWidget*)
  > gfxContext

According to the bug's history, Karl added "status1.9.1: .15-fixed" five
days ago : https://bugzilla.mozilla.org/show_activity.cgi?id=522635

However, in my browser, I see "status1.9.1: .16-fixed"

How did the "status" field change without the bug's history being updated?

(In reply to comment #52)
> How did the "status" field change without the bug's history being updated?

Sometimes labels get renamed when an extra release is squeezed in.
Looks like Firefox 3.5.15 is one of them.
https://wiki.mozilla.org/Platform/2010-10-26#Notices_.2F_Schedule

*** Bug 557785 has been marked as a duplicate of this bug. ***

Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in eclipse (Ubuntu Lucid):
status: Fix Committed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.