Some images have a blue tint

Bug #1130857 reported by James Brierley on 2013-02-20
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
firefox (Ubuntu)

Bug Description

Firefox 19.0 on Xubuntu 12.10 on a Late 2005 Apple Mac mini.

Steps to reproduce:

1. Open Firefox.
2. Navigate to an image-heavy website (Flickr, for instance). Note that some images have a blue tint.
3. If you already have enough of a browsing history, open a new tab and observe that the screenshots of your most visited pages also look too blue.

Downgrading back to version 18.2 makes the problem go away, although using an outdated browser is not much of a workaround.

I can test if required.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: firefox 18.0.2+build1-0ubuntu0.12.10.1
ProcVersionSignature: Ubuntu 3.5.0-24.37-powerpc-smp
Uname: Linux 3.5.0-24-powerpc-smp ppc
AddonCompatCheckDisabled: False
ApportVersion: 2.6.1-0ubuntu10
Architecture: powerpc
 /dev/snd/controlC0: james 1451 F.... xfce4-volumed
                      james 1471 F.... pulseaudio
BuildID: 20130201191451
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Channel: Unavailable
Date: Wed Feb 20 17:18:15 2013
ForcedLayersAccel: False
 default via dev eth0 proto static dev eth0 scope link metric 1000 dev eth0 proto kernel scope link src metric 1
MarkForUpload: True
Plugins: IcedTea-Web Plugin (using IcedTea-Web 1.3 (1.3-1ubuntu1.1)) - /usr/lib/jvm/java-7-openjdk-powerpc/jre/lib/ppc/ (icedtea-7-plugin)
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=18.0.2/20130201191451 (In use)
RelatedPackageVersions: icedtea-7-plugin 1.3-1ubuntu1.1
RunningIncompatibleAddons: False
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)

Bug 486918 added new image resizers from SKIA. Since this was enabled resized images on my ppc32 machine show up with a blue tint.

The convolver code extracts the RGBA bits from each 32 bit pixel but doesn't take the endian order into account.

Created attachment 687479
proposed fix. Detect that this is a PPC and set the BENDIAN then use that when extracting the bits

Comment on attachment 687479
proposed fix. Detect that this is a PPC and set the BENDIAN then use that when extracting the bits

Review of attachment 687479:

::: gfx/2d/convolver.cpp
@@ +206,3 @@
> if (has_alpha)
> + accum[3] += cur_filter * source_data_rows[filter_y][byte_offset +

Can you just leave these all on the same line?

@@ +231,5 @@
> //
> // We only need to do this when generating the final output row (here).
> + int max_color_channel = NS_MAX(out_row[byte_offset + R_OFFSET_IDX],
> + NS_MAX(out_row[byte_offset + G_OFFSET_IDX], out_row[byte_offset
> + + B_OFFSET_IDX]));

Same line here too

Created attachment 688092
v2 of the patch, all one one line but this exceeds 80 characters

Created attachment 688094
v3 has the line break but in a better spot

I would strongly recommend that the change to SkPreConfig.h gets a patch file added to gfx/skia/patches, or that this change be upstreamed to google's skia repo (or both!).

Otherwise this change is at risk of being overwritten when we next update skia.

submitted for review upstream

Created attachment 690255
adds the changes to SkPreConfig.h as a patch listed in gfx/skia/patches

This patch will add a patch file in gfx/skia/patches to alter SkPreConfig.h the next time we import upstream sources

Sorry! I was confusing SkPreConfig.h with SkUserConfig.h, and incorrectly figured it didn't need to have a separate patch.

James Brierley (jmb8710) wrote :
James Brierley (jmb8710) wrote :

Oops, I got to Launchpad after I had downgraded, to be extra clear: this bug refers to *the latest Firefox as of 20/2/13.*

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
James Brierley (jmb8710) wrote :

David, here's the rather poor workaround I used:

apt-get remove firefox
cd /var/cache/apt/archives
dpkg -i *firefox*18.02*

Then pin Firefox at this version by pasting the following into /etc/apt/preferences.d/firefox:

Package: *firefox*
Pin: version n=18.0.2
Pin-Priority: 999

apt-get update and you should be sorted until this bug is fixed - modulo security holes.

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux ppc; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130218104019

Steps to reproduce:

Open a random site with png or jpg images on it (e.g. search on google images).

Actual results:

Many images (happens on both png and jpg) have a blu tint. It happens that the image loads fine (colors are OK), but when completely loaded a "blu layer" appears on it. Strangely when the same image is shown more time on the same page not all have the blu tint.

Expected results:

Images have correct colors as it happened on firefox <= 18. This happened after upgrading to ff 19 on a Ubuntu 12.04 (official ubuntu packages) on a powerpc G4 machine.

1) Test with a fresh profile, see

2) If images are normal in FF18-, so there is maybe a regression.
Use the tool mozregression to find a possible regression range, see
(ex: mozregression --good=2012-08-01)

I did a "mv .mozilla .mozilla_backup", started ff and confirmed the blu images. When trying a bisect I get:

$ mozregression --good=2012-08-01
Downloading nightly from 2012-11-12
Installing nightly
Starting nightly
['moznightlyapp/firefox/firefox', '-profile', '/tmp/tmpteutxk.mozrunner']
Traceback (most recent call last):
  File "/usr/local/bin/mozregression", line 9, in <module>
    load_entry_point('mozregression==0.6.4', 'console_scripts', 'mozregression')()
  File "/usr/local/lib/python2.7/dist-packages/mozregression/", line 187, in cli
    bisector.bisect(get_date(options.good_date), get_date(options.bad_date))
  File "/usr/local/lib/python2.7/dist-packages/mozregression/", line 108, in bisect
    dest = self.runner.start(midDate)
  File "/usr/local/lib/python2.7/dist-packages/mozregression/", line 237, in start
    if not, self.addons, self.cmdargs):
  File "/usr/local/lib/python2.7/dist-packages/mozregression/", line 141, in start
  File "/usr/local/lib/python2.7/dist-packages/mozrunner/", line 183, in start, outputTimeout)
  File "/usr/local/lib/python2.7/dist-packages/mozprocess/", line 621, in run
    self.proc = self.Process(self.cmd, **args)
  File "/usr/local/lib/python2.7/dist-packages/mozprocess/", line 76, in __init__
    universal_newlines, startupinfo, creationflags)
  File "/usr/lib/python2.7/", line 679, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/", line 1249, in _execute_child
    raise child_exception
OSError: [Errno 8] Exec format error
Exception AttributeError: "'ProcessHandler' object has no attribute 'proc'" in <bound method Runner.cleanup of <mozrunner.runner.Runner object at 0x10f71530>> ignored

mozregression will not work because we don't have PPC builds, only x64 and X86.
( )

Reporter: Please set image.high_quality_downscaling.enabled to false in about:config and test again.
gfx.color_management.mode to 0 would be another thing to try.

OK, can you tell me how to purge all things installed with "sudo pip install mozregression"?

Just setting image.high_quality_downscaling.enabled to false fixes the problem.

(In reply to Fabio from comment #4)
> OK, can you tell me how to purge all things installed with "sudo pip install
> mozregression"?

sudo pip uninstall mozregression ? (just a guess)

> Just setting image.high_quality_downscaling.enabled to false fixes the
> problem.

thanks, it seems to be a regression from bug 486918

(In reply to Matthias Versen [:Matti] from comment #5)
> thanks, it seems to be a regression from bug 486918

But bug 486918 landed in FF18, no? So why did the reporter see the issue only after upgrading to FF19?

It got disabled on Firefox18 (see bug 829940)

I think this is Linux-specific. No such issue with TenFourFox on OS X PPC, but it's also not using the same downscaler.

I should also add that the problem is likely an endianness flaw in Skia; it has never been tested on big-endian platforms. This is not really something I can advise on because TenFourFox doesn't use Skia either (only CG). Perhaps Tobias has an idea.

ojordan (ojordan12345) wrote :

Here is the mozilla bug with workaround .

ojordan (ojordan12345) wrote :

This bug has just popped up on the debina mailing list. It appears to contain a patch for this problem?

I can confirm this bug and the workaround. It has been reported on launchpad ( ). The debian PowerPC mailing list also has the problem reported ( ). Is the patch in mozilla bug 817356 the fix for this?

Joe could answer the question if this is a dupe of bug 817356.

btw: Thanks Cameron for commenting and confirming that this could be a skia issue !

Looking at the code, I'm pretty sure this is a dupe of bug 817356, yes.

Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed

Apparently attachment #690255 never went through review in m-c nor commited, and neither upstream who didnt reply on codereview. Should it be unbitrotten and r?'ed ?

Stumbled upon this while investigating why skia got broken on ppc again (see #849253)...

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

Oibaf (oibaf) wrote :

Fixed since Firefox 20.

Changed in firefox (Ubuntu):
status: Confirmed → Fix Released
Oibaf (oibaf) on 2013-09-04
Changed in firefox:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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