table borders in Firefox do not display with Intel X driver

[nandhp]

Binary package hint: firefox-3.5

After upgrading to Karmic, table borders of some sizes do not display in Firefox (for example, the outer table borders on http://packages.ubuntu.com/karmic/hello ). This affects both Ubuntu Firefox 3.5.3 and mozilla.org Firefox 3.5.0, even on a clean profile. The bug did not occur in Jaunty with the same version of Firefox.

I have attached a minimal test case, which uses borders of increasing width. The first two tables have outside borders of 1px and 2px, but the remaining borders with widths up to 8px do not display properly, if at all.

ProblemType: Bug
Architecture: i386
Date: Sun Oct 11 09:02:13 2009
DistroRelease: Ubuntu 9.10
Package: firefox 3.5.3+build1+nobinonly-0ubuntu3
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-13.43-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.31-13-generic i686

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b1pre) Gecko/20091010 Ubuntu/9.10 (karmic) Namoroka/3.6b1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b1pre) Gecko/20091010 Ubuntu/9.10 (karmic) Namoroka/3.6b1pre

This seems to work in Konqueror, Arora, and Epiphany.
This does not work in Firefox 3.0, 3.5, 3.6preb1, 3.7prea1

Reproducible: Always

Actual Results:
Borders do not render in test case

Expected Results:
Borders should render in test case

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Created an attachment (id=405826)
Borders do not render

I forgot, this was from Launchpad:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/448686

[Ria-klaassen (ria-klaassen)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b1pre) Gecko/20091009 Namoroka/3.6b1pre

This works fine for me on Windows. Does it also fail with the latest official nightly? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:
https://bugzilla.mozilla.org/show_bug.cgi?id=521746

Please report any other issues you may find.

[Daniel Holbert (dholbert)]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091011 Minefield/3.7a1pre

Works fine for me, using Ubuntu Karmic on an x86 box... Maybe this is 64-bit-dependent for some reason? (comment 0 includes a 64-bit user agent)

Micah: Can you attach a screenshot of how the testcase renders?
(Alt + PrintScreen will snapshot the currently-focused window, in Ubuntu)

[Daniel Holbert (dholbert)]

(In reply to comment #3)
> Maybe this is
> 64-bit-dependent for some reason? (comment 0 includes a 64-bit user agent)

Nevermind -- this can't 64-bit dependent, because the launchpad bug was filed by someone on an i386 box.

[nandhp (nandhp)]

Yes, I (the original reporter) use x86. I am attaching a screenshot.

[nandhp (nandhp)]

Created an attachment (id=405869)
Testcase Screenshot

[Daniel Holbert (dholbert)]

nandhp: I see from the launchpad bug that you still see this issue on a clean profile. (And I've just confirmed that I *don't* see the issue, even with a clean profile.)

So, we need to narrow down what's different about our Karmic boxes that's causing the problem on your system but not on mine.

Could you try the following:
 (a) switch to Ubuntu's default Gnome theme ("Human"), reboot (to make sure all old-theme stuff gets cleared), and then see if you can reproduce?
 (b) boot from the official Karmic Beta LiveCD[1], and see if you can reproduce this in the LiveCD environment?

[1] http://releases.ubuntu.com/releases/9.10/ubuntu-9.10-beta-alternate-i386.iso

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Confirmed on Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091011 Minefield/3.7a1pre

I have an Intel graphics chipset based on the 965 chipset. if that makes a difference. I have not had a chance to confirm on live CD yet.

[nandhp (nandhp)]

I have not yet been able to reproduce the problem on a Live CD. However, I have only been able to test the Live CD in VMware, since I don't have any blank CDs available at the moment and I can't figure out how to boot the Live image using my hard disk. I'll keep trying to figure that out.

I have been able to reproduce the problem in both my user session with the default theme (after a reboot) and in a fresh guest session. On a whim, I tried some older versions of Firefox, and found that the problem also occurs in Firefox 3.0.14 (But not in 2.0.20) and in Seamonkey 2.0RC1. I proceeded to examine nightly trunk builds of Firefox until I found this pair:

2007-02-23-04-trunk works, 2007-02-24-04-trunk does not.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/02/2007-02-23-04-trunk/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/02/2007-02-24-04-trunk/

I checked here for the changes:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&date=explicit&mindate=2007-02-23+04:00&maxdate=2007-02-24+04:00

and found that there was at least one change to the behavior of beveled collapsed borders, bug #371182. The test case for #371182 shows a solid black border with faint diagonal lines at the corners (as described by the reporter of 371182) in 2007-02-23-04-trunk, but no border at all in 2007-02-24-04-trunk (as described in this bug).

I have no idea if this information is useful, but I'll keep trying to reproduce the problem on a Live CD.

Here is the complete list of User-Agents I tested:

NO PROBLEM:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070101 Minefield/3.0a2pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070201 Minefield/3.0a2pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070220 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070222 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070223 Minefield/3.0a3pre
PROBLEM:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091007 SeaMonkey/2.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008010104 Minefield/3.0b3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070601 Minefield/3.0a5pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070301 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070225 Minefield/3.0a3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070224 Minefield/3.0a3pre

[nandhp (nandhp)]

I cannot reproduce the problem using

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090924 Ubuntu/9.10 (karmic) Firefox/3.5.3

on the Karmic Live CD on my actual computer.

My graphics card is also Intel, but an i915, not a 965. Here's my lspci -vnn:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
 Subsystem: Lenovo Device [17aa:20e4]
 Flags: bus master, fast devsel, latency 0, IRQ 30
 Memory at f4400000 (64-bit, non-prefetchable) [size=4M]
 Memory at d0000000 (64-bit, prefetchable) [size=256M]
 I/O ports at 1800 [size=8]
 Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
 Capabilities: [d0] Power Management version 3
 Kernel driver in use: i915
 Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
 Subsystem: Lenovo Device [17aa:20e4]
 Flags: bus master, fast devsel, latency 0
 Memory at f4200000 (64-bit, non-prefetchable) [size=1M]
 Capabilities: [d0] Power Management version 3

At this point, the only odd thing I can think of about my system is that I had been running Shiretoko (Firefox) 3.5 on Jaunty using packages from the Ubuntu Mozilla Security PPA:
https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa
So there might have been some kind of error in the upgrade to Karmic (I did not have the problem in Jaunty). However, I did try reinstalling the Firefox packages, and that didn't fix the problem.

[Daniel Holbert (dholbert)]

Thanks for the regression-range in comment 9 -- that's super-helpful.

So, bug 371182 modified Cairo-specific code. It's possible that the root cause here is that your system's "libcairo2" version is buggy, if your broken Firefox versions are built with "--enable-system-cairo." (Though I'm not 100% sure whether "enable-system-cairo" refers to the system version at build-time or run-time.)

Just to test this theory -- what version of libcairo2 do you have? (apt-cache show libcairo2 | grep Version ) I have Version 1.8.8-2ubuntu1.

[Daniel Holbert (dholbert)]

Have you tested the latest official nightly, too?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009-10-13-03-mozilla-central/

If the --enable-system-cairo theory in comment 11 is correct, I predict that the latest mozilla-central version should *not* be broken for you, because it doesn't use --enable-system-cairo.

(mozilla-central nightlies haven't used --enable-system-cairo for some time now, though it's possible that the older versions (i.e. the ones you tested) did. You can check a particular version's build configuration by visiting "about:buildconfig" in the build.)

[nandhp (nandhp)]

I have the same version of libcairo2: 1.8.8-2ubuntu1. Reinstalling cairo did not help. Downgrading cairo to the version in Jaunty did not seem to help either. The Ubuntu version's buildconfig does include "--enable-system-cairo".

The mozilla-central nightly you linked to unfortunately *does* exhibit the problem, even though it does not have "--enable-system-cairo". The builds I tested did not have "--enable-system-cairo" either -- or at least not the ones from the 23rd and 24th.

[nandhp (nandhp)]

It just occurred to me try running Firefox on my computer using a remote X display on another computer (running Ubuntu Hardy). This does *not* exhibit the problem. I also tried the reverse, running the Ubuntu Hardy Firefox on my X display, and this does have the problem.

[Nicolas Briche (nbriche)]

I upgraded my main computer to Karmic today, and I'm affected (Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3). I tried and also failed with the current official release, with a fresh profile, and all plugins and add-ons disabled.

No problem however, on a pre-release VirtualBox Karmic with libcairo2 1.8.8-2ubuntu1 (Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.3) Gecko/20091007 Ubuntu/9.10 (karmic) Firefox/3.5.3), running on the same computer.

My computer uses an Intel chip (82G33/G31 Express Integrated).

[L. David Baron (dbaron)]

Does this happen using only the Ubuntu builds, or does it also happen using a build you download from https://www.mozilla.com/ ?

[L. David Baron (dbaron)]

Er, sorry, comment 13 seems to answer that, although it would be good to know that other people observe the same thing.

[Nicolas Briche (nbriche)]

(In reply to comment #17)
> Er, sorry, comment 13 seems to answer that, although it would be good to know
> that other people observe the same thing.

Sorry, by "current official release", I meant FF 3.5.4 available from mozilla.org as of today (Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4).

I just tried on my eeepc 901, also running an up-to-date Karmic, Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3. It also shows the problem.

Does anyone _not_ using an intel X driver shows the problem?

[Nicolas Briche (nbriche)]

The latest Karmic build still show the problem on eeepc901.

Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4

I'm preparing a karmic livecd that I'll test on an NVidia-based box and on the eeepc.

[Nicolas Briche (nbriche)]

Well, with a livecd on the same eeepc901, vesa X driver, the bug doesn't show.

LiveCD's user agent is Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3, same as my comment #18.

It seems to be a bug specific to intel X drivers, limited to table borders.

I wonder if other elements redefined as tables by CSS properties are also affected?

[Daniel Holbert (dholbert)]

(In reply to comment #20)
> Well, with a livecd on the same eeepc901, vesa X driver, the bug doesn't show.
[SNIP]
> It seems to be a bug specific to intel X drivers, limited to table borders.

Interesting. This would explain comment 14 as well -- presumably the remote (working) X display from that comment was using non-Intel drivers, and so it didn't hit the bug.

> I wonder if other elements redefined as tables by CSS properties are also
> affected?

Yeah, they should be. In fact, a <table> element is essentially just implemented as a generic element "redefined as tables by CSS properties" -- see
http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#180

[Nicolas Briche (nbriche)]

(In reply to comment #21)

> > I wonder if other elements redefined as tables by CSS properties are also
> > affected?
>
> Yeah, they should be. In fact, a <table> element is essentially just
> implemented as a generic element "redefined as tables by CSS properties" -- see
> http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#180

We may be back to the border-collapse trail mentioned in comment #9, then. I only found this bug because I've just been hit by it, and my "border: 2px solid black" tables were suddenly borderless. But only the tables; I've got plenty of other "border: 2px solid #xxx" elements with correct rendering (mostly div and p). The only difference I can see between those elements is the border-collapse. Just now, using Firebug to disable only this property, the borders came back.

[nandhp (nandhp)]

Actually the remote machine from comment #14 _does_ have Intel graphics:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c) (prog-if 00 [VGA controller])
        Subsystem: Dell Unknown device [1028:0275]
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f8000000 (64-bit, non-prefetchable) [size=1M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 1800 [size=8]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
        Capabilities: [d0] Power Management version 3

00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c)
        Subsystem: Dell Unknown device [1028:0275]
        Flags: bus master, fast devsel, latency 0
        Memory at f8100000 (64-bit, non-prefetchable) [size=1M]
        Capabilities: [d0] Power Management version 3

But it runs Ubuntu Hardy, and this problem only started appearing with Ubuntu Karmic (at least for me). It should be noted that there were several changes to the Intel graphics support in Karmic, e.g. from the release notes:

The Intel video driver has switched from the "EXA" acceleration method to the new "UXA", solving major performance problems of Ubuntu 9.04. Ubuntu 9.10 Beta also features kernel mode setting by default on Intel hardware, which reduces boot-time flickering and dramatically speeds up suspend/resume.
( http://www.ubuntu.com/testing/karmic/beta )

[Flemming Frandsen (dren-dk)]

I have an additional data point, the same version of Firefox (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4) that fails for me on 2 different Intel chipsets works fine with nvidia.

[Nicolas Briche (nbriche)]

That would tend to confirm nandhp's comment about UXA, then. Is there anything about border-collapse's implementation that would trigger a reaction specifically with UXA?

[nandhp (nandhp)]

I'm pretty sure now that this relates to the Intel driver. I tried adding 'Driver "vesa"' to my xorg.conf:

 Section "Device"
  Identifier "Configured Video Device"
+ Driver "vesa"
 EndSection

and restarting X. This fixes the problem, although I'm not sure how to confirm that I'm really using VESA (Xv video overlay is unavailable, so I guess that's a good sign).

[Nicolas Briche (nbriche)]

(In reply to comment #26)

> and restarting X. This fixes the problem, although I'm not sure how to confirm
> that I'm really using VESA

Checking /var/log/Xorg.0.log, you should find a bunch of lines beginning with

(II) VESA(0):

Basically the bottom half (or more) of the file should begin with this. IIRC.

[nandhp (nandhp)]

(In reply to comment #27)
> Checking /var/log/Xorg.0.log, you should find a bunch of lines beginning with
>
> (II) VESA(0):
>
> Basically the bottom half (or more) of the file should begin with this. IIRC.

It does -- it is the only recent Xorg log file to mention VESA at all.

[Nicolas Briche (nbriche)]

Okay, new weirdness:

With a table long enough (5 pg-down worth in my case), scrolling makes the _right_ border re-appear as the table scrolls down. Scrolling up again makes it appear too. That was in my intranet, with a 2-col layout, table on the right.

So I modified the test case, by copy/pasting about 200 more <tr/> for each table. Now it's the _left_ side that reappears while scrolling. It's sporadic, though: depending on whether you drag the scrollbar or use the mousewhell, or even how fast you go, it may leave 'holes'.

I'm using Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4.

[Nicolas Briche (nbriche)]

Created an attachment (id=410480)
Test case, long tables

Scroll up and down, see if any border re-appears.

[Nicolas Briche (nbriche)]

Oh, and no screenshot of the re-appeared border, because trying to do so makes them disappear again.

[nandhp (nandhp)]

Created an attachment (id=410484)
Screenshot of reappeared borders from scrolling

I am attaching a screenshot showing the reappearing of the borders when scrolling.

[Bernd (bernd-mozilla)]

Could you please retry with a nightly that incorporates http://hg.mozilla.org/mozilla-central/rev/91e00d39570f it fixed a couple of invalidation issues for border collapse borders.

[L. David Baron (dbaron)]

This seems unlikely to be a layout bug, I think.

[Flemming Frandsen (dren-dk)]

New data point: I've just reproduced the problem with an older 32 bit firefox I had around from when flash didn't exist in a 64 version:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.9) Gecko/2009040820 Firefox/3.0.9

This version worked fine before upgrading, so there is little doubt that this is a karmic bug rather than a Firefox bug.

[Flemming Frandsen (dren-dk)]

I've just reproduced the problem with an older 32 bit firefox I
had around from when flash didn't exist in a 64 version:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.9) Gecko/2009040820
Firefox/3.0.9

This version worked fine before upgrading, so there is little doubt that this
isn't a firefox bug, but rather a problem with the Intel driver.

[nandhp (nandhp)]

I just thought I'd mention that I saw on the Burning Edge that bug #452319 (border-collapse rewrite) was fixed, so I tried the nightly https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-21-03-mozilla-central/ , but there was no change.

[L. David Baron (dbaron)]

So the functions that are specific to drawing table borders are nsCSSRendering::DrawTableBorderSegment and DrawSolidBorderSegment in nsCSSRendering.cpp. In particular, if you look at DrawSolidBorderSegment:

http://hg.mozilla.org/mozilla-central/file/bcb580c05f4c/layout/base/nsCSSRendering.cpp#l2829

I think (based on reading the code):
 * the DrawLine case never gets hit (because the code is clearly broken, and
   because it should have been checking == aTwipsPerPixel rather than ==1)
 * the FillRect case is the reason that the borders are still being drawn
   correctly when they're one pixel wide
 * the FillPolygon case is what's broken
but it would be nice to confirm this.

Then the next step would be coming up with a simpler testcase (on top of the X APIs directly, or if that's too hard, at least on top of just cairo) that exhibits the same bug on this driver.

[L. David Baron (dbaron)]

So there only seem to be two uses of FillPolygon in our code. This table border drawing code is one of them. The other one of them is checkmark drawing for non-themed checkboxes, i.e., the check mark in:

data:text/html,<input type='checkbox' checked style='-moz-appearance:none'>

However, that seems to work ok. So it seems like some FillPolygon calls work and some don't.

[L. David Baron (dbaron)]

The difference between the two FillPolygon calls is the AntialiasMode of the context; if I comment out this line:
  ctx->SetAntialiasMode(gfxContext::MODE_ALIASED);
in nsCSSRendering::DrawTableBorderSegment, then the borders start appearing again (though with seams, which is what that call is designed to prevent).

[L. David Baron (dbaron)]

Created an attachment (id=414115)
simple testcase program on top of Gtk/Gdk/cairo

Here's a simple testcase program that shows the problem, written on top of Gtk+Gdk+cairo. I haven't looked into what X calls cairo is making (it might just be XFillPolygon, though I don't know how the antialias mode translates).

This draws a triangle on an Xvnc server, but draws nothing on the Intel server.

[L. David Baron (dbaron)]

Here's a testcase (.tar.gz containing Makefile and testcase.c) using only Gtk, Gdk, and cairo, that shows the same problem with the Intel X driver. It should draw a deep red equilateral triangle, but nothing shows up with the Intel driver.

(I tried to write an equivalent Xlib testcase using XFillPolygon, but it didn't show the bug; so I clearly don't know enough about cairo to reduce this to an Xlib testcase.)

[Nicolas Briche (nbriche)]

This bug seems to have been resolved with the latest libcairo2 (1.8.8-2ubuntu1.1) and/or xserver-xorg-video-intel (2:2.9.0-1ubuntu2.1) packages. Could somebody confirm?

The xserver-xorg-video-intel changelog shows:

  * Add 101_uxa_free_scratchpixmapheader.patch. Fixes a problem with
    non anti-aliased cairo shapes not being rendered at all on intel
    graphics. Cherrypick from upstream 2.9.1 release. (LP: #458545)

which matches with David's findings.

[Bryce Harrington (bryce)]

Hi nandhp,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISO CD images are available from http://cdimage.ubuntu.com/releases/)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Nicolas Briche (nbriche)]

Can we close this bug? Unless someone else still sees the problem, it's been resolved by xorg.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

I'm running Lucid now and this seems to be fixed with the Intel driver updates.

[Timo Aaltonen (tjaalton)]

apparently fixed since 10.04.