Ubuntu

Black rectangle instead of image in FF3 [Hardy]

Reported by kripken on 2008-01-11
244
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
High
X.Org X server
Fix Released
Critical
XULRunner
Invalid
High
epiphany-browser (Ubuntu)
Undecided
Unassigned
firefox-3.0 (Ubuntu)
Medium
Alexander Sack
imagezoom (Ubuntu)
Undecided
Unassigned
xorg-server (Ubuntu)
Medium
Bryce Harrington
xulrunner-1.9 (Ubuntu)
Medium
Alexander Sack

Bug Description

workarounds:

1. use in-source jpeg (in xulrunner 1.9 >= beta5)
2. use Option "XAANoOffscreenPixmaps" "true" in your xorg.conf device section.

Binary package hint: firefox-3.0

Firefox 3.0 renders images fine at the default zoom, but for certain images shows only a black rectangle when the zoom is changed (by control-+ or control--). See e.g. this page:

http://www.everex.com/

There is a big image of a laptop on the right. This turns into a black rectangle when the zoom is not the default.

This is on a fresh install of Hardy Heron Alpha 3. I am using the "nv" open-source driver if that is relevant.

Created an attachment (id=296456)
The site mugshot.org in Firefox

Created an attachment (id=296457)
The same site (mugshot.org) in WebKit for comparison

It seems to be video-driver dependant: not reproducible with vesa X.org driver (ABI version 4). Screenshots were made using nv X.org driver (ABI version 3)

Binary package hint: firefox-3.0

Firefox 3.0 renders images fine at the default zoom, but for certain images shows only a black rectangle when the zoom is changed (by control-+ or control--). See e.g. this page:

http://www.everex.com/

There is a big image of a laptop on the right. This turns into a black rectangle when the zoom is not the default.

This is on a fresh install of Hardy Heron Alpha 3. I am using the "nv" open-source driver if that is relevant.

kripken (kripkenstein) wrote :

Looking at some other websites, I now notice that sometimes images are just not shown - at any zoom. Example:

http://arstechnica.com/news.ars/post/20080111-kde-4-0-rough-but-ready-for-action.html

There is a screenshot (PNG, not sure if that is important) that doesn't show up at all - just a blank area, same color as the background, where the image should be,

I can't reproduce this. I'm on a updated Hardy.

kripken (kripkenstein) wrote :

Mario: Well, perhaps it's something more specific. I'm using the "nv" open-source driver. Are you using binary drivers perhaps?

Yes, it could be that. I confirm that I'm using the "nvidia" driver and the problem doesn't occurr. :)

Nanley Chery (nanoman) wrote :

Same problem using the nv driver. Haven't tried the nvidia driver. Also, could bug 180525 be a duplicate?

kripken (kripkenstein) wrote :

I now think that indeed this and bug #18525 may be closely related, good point, Nanley. When resizing, all sorts of odd things occur to images, the 'black rectangles' reported in this bug may just be what happens when the image is moved out of the visual area completely. In other cases I have seen it moved partially out of the visual area.

So, is the "nv" driver the issue here? Perhaps this might explain why there isn't a flood of reports of this bug.

kripken (kripkenstein) wrote :

I am attaching screenshots of an example, on a familiar website. Here it is at default zoom:

kripken (kripkenstein) wrote :

And here it is when zoomed in one time. Note the black rectangle instead of the central image:

Nanley Chery (nanoman) wrote :

This is most definitely a problem in the nv driver as installing the nvdia driver fixed this problem for me and others.

Changed in xserver-xorg-driver-nv:
status: New → Confirmed
sojourner (itsmealso2) wrote :

I also confirm that this occurs with the NV driver but not with the Nvidia propriatary driver ( 169.04 64 bit ).

Alexander Sack (asac) wrote :

please attach an image that is affected (not screenshot, but the actual image).

Thanks,
 - Alexander

Changed in firefox-3.0:
importance: Undecided → Medium
status: New → Incomplete
kripken (kripkenstein) wrote :

Here is an example image.

Appears as a black rectangle at all but the default zoom using "nv" (works fine with "nvidia").

Alexander Sack (asac) wrote :

thanks, does it happen with all jpegs or just with some? are there pngs or gifs that don't work either?

Changed in xorg-server:
status: Unknown → Confirmed
kripken (kripkenstein) wrote :

This does not happen with all jpegs. For example, open www.ubuntu.com: the middle top jpeg (the one I attached above) has the problem, but the one on the left (with the four people, http://www.ubuntu.com/files/masthead/ulivecfp/masthead-left-gutsy.jpg) - is fine. However, this is 100% consistent - certain jpegs have the problem, and always do, in all of my testing. (No idea what makes certain ones vulnerable to this.)

Regarding PNG images, there are other serious issues with them. In some cases - not all - they completely fail to load, leaving an empty area, not even a black rectangle, and this occurs for ALL zoom levels. There is a bug at Mozilla here:

https://bugzilla.mozilla.org/show_bug.cgi?id=409345

An example page for testing is this:

http://www.canonical.com/projects/landscape

There should be several screenshots, but none appear when using the "nv" driver - there is just blank space. Sometimes the images load partially, but scrolling away and then back makes them vanish. All of this works with the "nvidia" binary driver, so again, the issues are with the "nv" driver.

Alexander Sack (asac) wrote :

maybe try to use the EXA accelmethod (instead of XAA) in your xorg.conf.

kripken (kripkenstein) wrote :

EXA doesn't help - still black rectangles and the other problems.

(FWIW I noticed that EXA is faster than XAA.)

I've been seeing something very much like this (the first part) for some time on Ubuntu Gutsy (7.10) and Hardy (8.04), using an open source Nvidia graphics driver.

Images (apparently only PNG) often fail to render and sometimes render incorrectly when scaled.

This also affects Liferea on Ubuntu Hardy, which is now embedding Gecko 1.9.

Bug 409345 describes identical symptoms and may be a dupe; bug 413276 sounds similar though I'm not convinced it's related.

My machine has a low memory spec (<400 MB), so I suspect (as a non-developer and general idiot) that bug 402631 may be the culprit.

I'm confirming this bug (since we seem to have three independent accounts) and increasing its severity to major, as this is a major rendering regression over Fx 2 that (for those it affects) makes using Firefox for day-to-day browsing awkward. I'm also requesting blocking-firefox3 for the same reason and to get some attention.

I have screenshots demonstrating scaled images being misrendered, which will follow.

Created an attachment (id=300345)
An unscaled image, correctly rendered

Confusingly, the image itself depicts a misrendering of images; but the image is being rendered correctly. Note, however, that the page icon (a scaled version of the image) is rendered wrongly.

Created an attachment (id=300346)
The same image, scaled, renders incorrectly

This is the same image as attachment 300345, but scaled to fit within the window. The bottom portion of the previously-visible part of the image shows at the top, and the rest is blacked out.

In some cases (not shown here) the page icon changes when zooming in for the first time. Generally it shows vertical bars of colour (or black and white), then changes to a square of grey (and stays like that). In all cases, it's rendered wrongly.

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

The Broken Website reporter works for me, so I'm morphing this bug to only cover the image display issues. If you still have problems with it in the latest nightlies (sounds like an XML error), please file a new separate bug.

This is not PNG-specific – background GIF images disappear from the BBC homepage beta in Fx 3; screenshots to follow.

Created an attachment (id=300351)
The BBC homepage beta in Firefox 2

This page renders correctly in Firefox 2 (aside from the black box around the Flash clock).

Created an attachment (id=300352)
The BBC homepage beta in Firefox 3

In Firefox 3, several background images don't appear.

The frames around “Customise homepage”, “Set your location” and “Reset homepage” are absent; these are background images and are GIF (presumably transparent GIF, though I haven't checked).

The arrow to the left of the “News” heading (bottom left of the picture), and the frame around “Edit” to its right are both also gone. (I assume without checking that these are background images.)

So far this bug has been seen affecting background images in PNG and GIF formats; I'm not sure whether it affects fully opaque images.

Created an attachment (id=300358)
Screenshots: scaling, opaque vs. transparent images

I have performed some science.

Results:

1: When loaded directly into Firefox, transparent images are not drawn at all, irrespective of whether they are scaled or unscaled.

2: Opaque images are always drawn. They are drawn correctly when unscaled, but wrongly when scaled.

3: Typically, scaled opaque images appear fully black; they sometimes show a portion of the picture in the wrong place (but still within the bounds of the image on the screen).

4: The incorrectly-placed portion appears when redrawing the image at a higher scale factor; as the scale factor approaches 100%, the image gradually moves to occupy its proper position.

5: There was no difference observed between GIF, PNG and JPEG images.

6: For all images, the page icon behaves erratically: it usually shows as vertical bars in some combination of black, white and the OS theme's highlight colour (!); changes when the image is redrawn or another tab is selected; and tends towards a grey square. The icon in the tab is not always the same as the icon in the location bar.

The process used to arrive at the results:

1: Four images were created using the Gimp: a transparent PNG, an opaque PNG, a transparent GIF, an opaque GIF. The opaque images were made using the Gimp's Flatten Image command; they have a red background for clarity. The transparent ones' backgrounds are completely transparent. The images are all somewhat taller than will fit in a maximised Firefox window (900 px), so Firefox will scale them they're loaded.

2: The images were all loaded into the latest trunk build of Firefox (Gecko/2008012904) running on Ubuntu Hardy (pre-release, vintage today). When the images were loaded in, the window was at a small size (to allow me to drag them in from the desktop); the content area was roughly 400 px tall.

3: The window was then maximised so the content area was about 540 px tall. This caused each image to be redrawn at a higher magnification (though still much less than 100%).

4: Screenshots were taken of each image in a maximised browser, scaled and unscaled (zoomed in by clicking). For the opaque images, screenshots were taken at two scale factors (plus unscaled): the original scale when the pictures were loaded (in an unmaximised window), and a larger scale <100% (in a maximised window).

(Some of these screenshots, and the images used to make them, are included in the attachment. I have the complete set if anyone's interested.)

5: A smaller opaque PNG image was made, that would fit inside a maximised window unscaled. This was loaded into a small browser window whose height was then varied (and the image allowed to redraw at various scales) until the image fitted unscaled inside the window.

6: A JPEG image was made, loaded and observed scaled and unscaled.

One more thing: I've also observed background images render as copies of other parts of the screen (including parts of Gnome's panels, which Firefox shouldn't know about), though this is more difficult to reproduce.

The Broken Website Reporter stated working after an upgrade.

The incorrect rendering of images sounds more and more like an X.org (XSHM?) bug that Firefox exposes. Especially parts of other windows showing up in images. Not only background images, I also get them in animated GIFs.

And we are both using prerelease versions of X.org.

It might be possible that this is indeed some X.org (specifically, "nv" driver?) issue that is only exposed by FF3. However, the interesting bit is that

1. The same issues don't occur on FF2

2. I have seen no issues whatsoever with other applications (and that includes graphic-intensive ones like movie players, image editing, etc.) when using the same X.org and driver.

(In reply to comment #15)
> 2. I have seen no issues whatsoever with other applications (and that includes
> graphic-intensive ones like movie players, image editing, etc.) when using the
> same X.org and driver.
>

I've seen it in Liferea, but that embeds Gecko 1.9.

I've filed this bug at Ubuntu's Launchpad as https://bugs.launchpad.net/ubuntu/+bug/187680 .

Hmm, might be the shared Gecko 1.9 then.

There is also this older bug on Launchpad:

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/182038

I can also reproduce with 'vmware' X.org driver (inside VMware Server 2), and the 'nouveau' driver, but the latter shows many more unrelated bugs too.

kripken (kripkenstein) wrote :

Is anything in particular missing because of which this report is 'incomplete'?

There are more details and screenshots at https://bugzilla.mozilla.org/show_bug.cgi?id=411831

I can also reproduce this on Feisty using a Firefox trunk build from Mozilla. Presumably Gutsy is affected too.

In Gutsy, images that fail to appear at all in Feisty and Hardy (for example: the tabs at https://help.ubuntu.com and the border around “Customise homepage” at http://www.bbc.co.uk/home/beta/ ) *are* drawn, but much too light—as if the opaque parts of the image had been overlaid with semi-transparent white.

Alexander Sack (asac) wrote :

this issue is incomplete for firefox-3.0 until we know that this is a firefox bug.

Alexander Sack (asac) on 2008-02-22
Changed in xorg-server:
milestone: none → ubuntu-8.04-beta
Changed in firefox-3.0:
milestone: none → ubuntu-8.04-beta
Alexander Sack (asac) on 2008-02-25
Changed in xulrunner-1.9:
status: New → Confirmed
Changed in firefox-3.0:
status: Incomplete → Invalid
Alexander Sack (asac) on 2008-02-25
Changed in xulrunner-1.9:
importance: Undecided → Medium
milestone: none → ubuntu-8.04
Changed in xorg-server:
importance: Undecided → Medium
Changed in xulrunner:
status: Unknown → Confirmed
Changed in xorg-server:
status: Unknown → Confirmed
Alexander Sack (asac) on 2008-03-10
Changed in xulrunner-1.9:
status: Confirmed → Triaged
Changed in epiphany-browser:
status: New → Invalid
Martin Pitt (pitti) on 2008-03-13
Changed in firefox-3.0:
milestone: ubuntu-8.04-beta → none
Steve Langasek (vorlon) on 2008-03-22
Changed in xorg-server:
milestone: ubuntu-8.04-beta → ubuntu-8.04
Alexander Sack (asac) on 2008-03-26
Changed in xulrunner-1.9:
assignee: nobody → asac
Changed in firefox-3.0:
assignee: nobody → asac
Alexander Sack (asac) on 2008-03-29
Changed in xulrunner-1.9:
status: Triaged → Fix Committed
Colin Watson (cjwatson) on 2008-04-02
Changed in xorg-server:
assignee: nobody → bryceharrington
Alexander Sack (asac) on 2008-04-03
description: updated
Changed in xulrunner-1.9:
status: Fix Committed → Fix Released
Bryce Harrington (bryce) on 2008-04-14
Changed in xorg-server:
status: Confirmed → Fix Committed
Changed in xorg-server:
status: Fix Committed → Fix Released
Alexander Sack (asac) on 2008-04-15
Changed in xorg-server:
status: Fix Released → Triaged
status: Triaged → Fix Committed
Changed in xorg-server:
status: Fix Committed → Fix Released
Saša Bodiroža (jazzva) on 2008-04-17
Changed in imagezoom:
status: New → Invalid
Changed in firefox:
status: Unknown → Confirmed
Changed in firefox:
status: Confirmed → Invalid
Changed in xulrunner:
status: Confirmed → Invalid
194 comments hidden view all 274 comments

that's not really a work around. I also concur that this should be a show stopper. I think that it must only partially be an Xorg bug as it didn't exist in ff2

If anybody is wondering why this bug magically fixed itself in their distro recently, it's because Ubuntu and Fedora have inverted the default behavior of the XAANoOffscreenPixmaps option.

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/182038/comments/111

In case you're trying to debug this, you may need one of the following options to bring back the broken behavior:

 Option "XAANoOffscreenPixmaps" "false"
 Option "XAAOffscreenPixmaps" "true"

Seems like sweeping things under the rug to me :o)

Created an attachment (id=321823)
Image rendering bug manifesting in the Preferences dialog

Does anyone else see this rendering bug too? It only appears when I switch back off-screen pixmaps.

Or is it unrelated? Similar glitches are also present in other programs like GNOME 2.22 Appearance dialog or the scrollbars in every app in KDE 4...

It would be best if Xorg was willing to fix it including backports to old X releases

Created an attachment (id=321843)
an image that manifests the "black box" problem

I think there are actually two problems here. This is an image that manifests the "black box" problem. Create the following HTML file in the same directory, and watch the image as it resizes. There seems to be a problem with calculating image offsets inside the clipping region, because for medium image sizes, the image displays but is vertically offset, and surrounded by black above or below; as the image's size continues to get bigger, the image that should be displayed moves upwards at about twice the speed of the increase in display size. For large or small sizes, the image shows as completely black, because the image content is being displayed above or below the clip region.

<html>
<head>
<script type="text/javascript">
function f() {
  var img = document.getElementById('pic');
  img.width += 100;
  if (img.width > 1700)
    img.width = 100;
  setTimeout('f()', 1000);
}
</script>
</head>
<body onload="javascript:f()">
<img src="kde4.0.png" id="pic"/>
</body>

The second problem is to do with transparency (not resizing), and displays a white image rather than a black image. I will attach an example below.

Created an attachment (id=321844)
an image that manifests the "invisible image" problem

This image is a PNG with an alpha channel, and does not display at all in FF3. Just go "firefox tmp.png" to see it (or not as the case may be :) ).

Running the script in the comment above on this image does *not* cause the image to be shown at certain sizes. Therefore it seems that this is an unrelated problem to do with alpha channels in images.

PS you can also see the black box problem by opening the image in attachment 321843 directly in FF3, and then holding Ctrl while rolling the mousewheel to zoom in and out.

In case you can't duplicate this problem by running the JS code I posted above, here is an animated GIF of the image resizing problem.

http://web.mit.edu/~luke_h/www/anim.gif

Actually I think this bug may cover three different issues, not two: wrong image offset calculations, easily spotted in this animation; the transparency problem, previously discussed; and also there seems to be a third problem with uninitialized memory with certain sizes of these "black box" cases. You can see some dim brown stripes that run down the black box in the first frame of this animation. If you stop the JS code running at that point and open another window, the pattern of lines changes, it's like the first row of the black box is pulling in data from some X shared memory, and that is copied all the way down. Dragging another window over the top of the black box causes trails to be left behind.

Ironically, on a "broken system", the above animated gif displays wrong too, it gets cropped into a narrow wide box near the top of the browser window, and as it animates, some window decoration junk gets inserted at the edges of the box along with content of the gif animation itself...

Created an attachment (id=321964)
an image that manifests the "uninitialized memory" problem

An example of the uninitialized memory problem: with the image scaled to the smallest size, it starts out with random gray stripes running from top to bottom, and then if you stop the JS code running and drag a window past the black box, you get something like this.

Sorry for all the comment spam... one more distinction between these problems: with the "black box problem", dragging the black box shows the correct image in the tooltip. With the "invisible image with transparency" problem, dragging the area of the browser window that should be showing the image does *not* show anything. However zooming in far enough with Ctrl-Scrollwheel eventually adds scrollbars to the browser window, so the image is there in the DOM, it's just not being displayed, and it seems that it's definitely a different problem in both cases.

I changed from using fglrx to radeonhd to fix another issue, and I can't
reproduce the problem on my platform.

I have found that using ``Option "XaaNoOffscreenPixmaps"'' slows down
some xscreensaver programs (fuzzyflakes, deluxe, twang). What I have done,
instead, is to run the X server using ``DefaultDepth 16'' instead of 24.
This fixes the problem fine for me.

System specs (in case it helps):
X : xorg-6.9.0
GPU: nVidia GeForce2 MX Integrated Graphics (pci id: 10de:01a0 (rev b1))
MEM: 32MB shared (main memory 256 MB). 32MB graphics aperture size.
MB: Asus A7N266-VM
CPU: AMD Athlon(TM) XP 2000+

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

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

I see this is marked RESOLVED INVALID and I understand the reason why, but I do want to point out that I see this bug on Firefox's DEFAULT Google start page http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official on Mandriva 2008.1 on X.Org X Server 1.4.0.90 with nv driver. The Firefox-Google logo http://www.google.com/images/firefox/sprite.png does not show. Will Google want to weigh in on this, maybe with a workaround, so that we don't receive an avalanche of reports with FFX3?

1st of all sorry if this is not the right place to discuss it, but I wouldn't know the "right" place.

I can understand this is not a bug but what I see is a whole bunch of users not being able to use FF3 because of this "issue". I'll be sticking to 2.x, since most of the sites (and my own among them) are not going to work with FF3.

If more and more users (almost everyone using 24bit? perhaps) will be having this kind of "issue", well, it won't be a good.

(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0)

WHERE TO PUT THE XAANoOffscreenPixmaps configuration option.

This is for anyone who (like me) was wondering precisely where to put the above option. These are the details for my system (OpenSuse 10.3).

Location /etc/X11/xorg.conf

...
Section "Device"
  BoardName "GeForce4 Go DH"
  BusID "1:0:0"
  Driver "nv"
  Identifier "Device[0]"
  Screen 0
  VendorName "NVidia"
  Option "XAANoOffscreenPixmaps" "on"
EndSection
...

This solved my problem with one of the background images not loading properly in Facebook.

(In reply to comment #116)
> WHERE TO PUT THE XAANoOffscreenPixmaps configuration option.
>
> This is for anyone who (like me) was wondering precisely where to put the above
> option. These are the details for my system (OpenSuse 10.3).
>
> Location /etc/X11/xorg.conf
>
> ...
> Section "Device"
> BoardName "GeForce4 Go DH"
> BusID "1:0:0"
> Driver "nv"
> Identifier "Device[0]"
> Screen 0
> VendorName "NVidia"
> Option "XAANoOffscreenPixmaps" "on"
> EndSection
> ...
>
> This solved my problem with one of the background images not loading properly
> in Facebook.
>

I have just tried to use the "XAANoOffscreenPixmaps" option on my Opensuse 10.3 system. I use a Nvidia GeForce 7800 GTX card with the latest Nvidia driver 173.14.05 on a X86_64 architecture. I tried the option with and without the trailing "on". The xorg X-server version is 7.2.0 (7.2.0-135.4 rpm package from SuSE). All relevant rpm packages for the system are from the SuSE repositories. KDE version is 3.5.9.

The settings did not change anything regarding the bad FF 3.0 image scaling on this system. The scaling quality remains that of a nearest neighbor interpolation as with FF 2.x. So it seems that there are more factors involved than just the XAA thing. At least when you use the drivers from Nvidia.

This bug has nothing to do with image scaling quality. The bug for that is bug 422179.

Just so everyone is aware - Freedesk xorg hackers already know what the issue is.

See http://bugs.freedesktop.org/show_bug.cgi?id=13795

"The issue here is almost certainly that FbComposite offsets the composite
operation by the coordinates of the drawable with no regard to the
transformation.

Fixing probably involves making image_from_pict() do the conversion, and
somehow fixing up miSourceValidate"

The final action in the bug that we logged is below, that bug can be found at http://bugs.freedesktop.org/show_bug.cgi?id=15098

"I really can't be arsed to fix this properly right now, XAA is just dire. For
7.4 I'm just going to turn off XAA offscreen pixmaps by default, they end up
being a performance loss in most cases anyway."

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

(In reply to comment #114)
> I see this is marked RESOLVED INVALID and I understand the reason why, but I do
> want to point out that I see this bug on Firefox's DEFAULT Google start page
> http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official
> on Mandriva 2008.1 on X.Org X Server 1.4.0.90 with nv driver. The

Mandriva should fix their default x org settings. I know that ubuntu and fedora do that.

Lee (deth) wrote :

I have this problem with an oddly-sized GIF image (attached) - it's supposed to have transparency under it, which gimp shows but display (from ImageMagick) does not... indicating that it's got a height change rather than true transparency. In my case, the black area shows where the transparency is supposed to be - beneath the button.

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

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

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

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

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

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

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

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

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

seems like xorg 1.6.0 dropped the patch that disabled offscreen pixmaps for xaa by default (still needs investigation why).

So this bug reappeared in jaunty.

See: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/316136

FWIW, we will patch xorg in ubuntu accordingly again; so still no action from mozilla side needed.

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

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

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

Another note: I encountered this problem with the "intel" driver, using the G45 chipset graphics.

It was necessary for me to use the following two entries in the Device section of xorg.conf. "RenderAccel" explicitly turns on EXA. The XAANoOffscreenPixmaps alone would not fix the problem:

 Option "XAANoOffscreenPixmaps" "on"
 Option "RenderAccel" "on"

Changed in xorg-server:
status: Confirmed → Fix Released

I know I'm jumping in late, but I see this behavior (black images) as of Firefox 3.5.6 on Windows XP SP3 (native, no virtualization).

Images become black more often as the number of tabs increases. Special culprits are Wikipedia and OKCupid. Rebooting the machine fixes the problem, so this smells more like a memory leak in the already bloated Firefox.

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

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

Changed in firefox:
importance: Unknown → High
Changed in xulrunner:
importance: Unknown → High
Changed in xorg-server:
importance: Unknown → Critical
Changed in xorg-server:
importance: Critical → Unknown
Changed in xorg-server:
importance: Unknown → Critical
Displaying first 40 and last 40 comments. View all 274 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

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