Closed Bug 901944 Opened 11 years ago Closed 9 years ago

Rendering glitches on H.264 video only in FF23 on Vista

Categories

(Core :: Audio/Video: Playback, defect)

23 Branch
x86
Windows Vista
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox23 + verified disabled
firefox24 + disabled
firefox25 + disabled
firefox26 + fixed

People

(Reporter: banakon, Assigned: cpearce)

References

Details

(Keywords: regression, Whiteboard: [leave open])

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130730113002

Steps to reproduce:

Install FF23

then watch these video in the left side
http://ie.microsoft.com/testdrive/graphics/videoformatsupport/default.html



Actual results:

Green lines on the right of the videos h264.



Expected results:

all the video have to work fine as with FF22!!

the changelog of FF23 tells about accelerated h264 on Vista+....
I guess a bug has been introduced. zwero issue with ff22 on the same machine.
to resolve the bug, install FF22.

please fix this bug related to h264 html5 ;)
thanks.
on ff23 the issue is fixed disabling acceleration hw in ff.
since I have a new gpu and new drivers, I guess that this issue has to be resolved by Mozilla, since
http://www.mozilla.org/en-US/firefox/23.0beta/releasenotes/
Enabled DXVA2 on Windows Vista+ to accelerate H.264 video decoding
http://www.mozilla.org/en-US/firefox/23.0/releasenotes/
Enabled DXVA2 on Windows Vista+ to accelerate H.264 video decoding

maybe that this change introduced a bug...do you agree? thanks.
hi, where are you? ;)
WFM with FF23 on Win 7, but it's clearly an issue with FF23 on Vista, as you reported.
Component: Untriaged → Video/Audio
Product: Firefox → Core
Summary: Bug H264 only in FF23 → Rendering glitches on H.264 video only in FF23 on Vista
Thank you for your reply and for better topic title.
If wanted, I can upload a dxdiag.txt.
Vista32 sp2.
Ok silverlight and flash. 
I guess that the issue is related to h264 accelerated on html5.

I hope that the developers will fix, perhaps in FF23.0.1.
Please let me know if there are good news ;9
regards.
Severity: normal → major
Please provide a copy of the Graphics section of your about:support page.

It's unlikely that this is a regression since we just implemented support for this. It's more likely that your machine represents an edge case we did not account for.
Severity: major → normal
Nominating this for tracking while we investigate.
Thanks for getting this on our radar Anthony, I'll start tracking once we have more information about the regression range,affected version etc.
(In reply to banakon from comment #6)
> Thank you for your reply and for better topic title.
> If wanted, I can upload a dxdiag.txt.

Please do! Having a dxdiag report would help. Also, what graphics card do you have?
Also, you can set the pref "media.windows-media-foundation.use-dxva" to "false" if you load "about:config" in the URL bar to disable DXVA, and that should enable you to work around the problem. Also, if setting this pref to false makes the problem go away, it will definitely prove that DXVA is the problem.
And as Anthony asked, a copy of your Graphics section from about:support would be very handy.

We'll need to just blacklist this card on Vista I think, and we need the information asked for in order to identify the card. Thanks!
Attached file DxDiag.txt
Thanks for your reply! much appreciated.
the GPU is not old, I am wondering if my GPU on Vista32 sp2 (PLUS platform upgrade + supplement to the platform upgrade via "Windows Update") were not supported by the changes introduced with FF23 (since the changelog refers to "Vista+" and "dxva2", and my graphic does support dxva5 too). Here the Graphics, thanks for investigating!!
(OK if h264 runs in flashplayer and silverlight (acceleration ON: CPU 3-9% 1080p full screen, therefore I am sure that the acceleration works fine, otherwise I would find more than 3-9% cpu load while watching the videos 1080p full screen mode, in FF)
=====
5-12-2013 NVIDIA GeForce GTX 650
Direct2D attivo true
DirectWrite attivo true (7.0.6002.23097)
Driver scheda grafica  nvd3dum nvwgf2um,nvwgf2um
Finestre con accelerazione GPU  1/1 Direct3D 10
GPU #2 attiva false
ID dispositivo 0x0fc6ID 
produttore 0x10de
RAM scheda grafica 2047
Rendering WebGLGoogle Inc. -- ANGLE (NVIDIA GeForce GTX 650)
Versione driver 9.18.13.2018
AzureCanvasBackend direct2d 
AzureContentBackend direct2d 
AzureFallbackCanvasBackend cairo
====

what is wrong here?

@Chris: thanks you too, here my dxdiag.txt attached ;)
my card vga (via hdmi):
http://www.asus.com/Graphics_Cards/GTX650E2GD5/

If this may help, I add following:
the 2 "html5 h264" videos in my link above look with green lines on the rightside (FF with hw acceleration on).

oh no, please do not blacklist my card!! ;) it were fine if you could take an effort to make my card working with dxva enabled on Vista ;)
Ok, I will read tomorrow your response, after investigating ;)

Chris, I confirm: by setting the key to false, all is ok!!!!
what should I do now, leaving the setting to false until ff24, then re-setting it to true or what now?? thanks for suggestions.
very strange my friend, that FF23 doesnt support dxva2 (my card does support dxva5 too!) in Vista, VLC player does it on the same machine! very strange. perhaps you will find a fix, not a workaround ;) :)

PS: issue: I have to use the space bar on the keyboard to pause /play the videos, full screen and small screen too.
If I press the > Play/Pause botton: nothing happens, the video get forward og ONE FRAME only!! I have to use the keyboard botton and all is ok!!! strange.

Best regards.
Thanks for posting that information. A few other people have reported problems with Nvidia GT450. I will try to investigate in the next few weeks, I've got a lot on my plate at the moment.
GTX 650, a card from the end of 2012, not too old ;) 

[[  nvidia and asus via email -but NOT officially on their website due to concurrence/business reasons...told me that this card GTX 650 is capable to support accelerated H26**5** rendering too! while gtx 640 doesnt ]].

Ok Chris, I can wait without problems ;)
thanks a lot!
I'm on Vista with a very capable GTX 460 and getting these same crazy artifacts, H.264 worked fine in FF 22 so I've downgraded to it for the time being.

If FF22 wasn't using DXVA2 then what was it using to accelerate video on the GPU?
FF22 was using not accelerating H.264 decoding using the GPU, it was doing everything in software on the CPU. Setting the pref media.windows-media-foundation.use-dxva to false makes Firefox go back to using the CPU for decoding.
I also got the green lines with a 8800GTX on Vista but not Windows 7.
With the "Trace Log"-feature of the program "DXVA Checker"[1][2] you can see that Firefox isn't using DXVA2 in Vista, even if both media.windows-media-foundation.*-preferences are set to true and HW-acceleration is enabled.
DXVA2 for H264 is working fine on the same machine in Vista in media-players like MPC-HC with LAV Filters, so it's probably no driver- or OS-problem.

[1]: http://bluesky23.yu-nagi.com/en/DXVAChecker.html
[2]: http://forums.mozillazine.org/viewtopic.php?p=13008365#p13008365
elbart: If you set the pref "media.windows-media-foundation.use-dxva" to "false" in "about:config" does the problem go away?
Yes.
(In reply to elbart from comment #20)
> With the "Trace Log"-feature of the program "DXVA Checker"[1][2] you can see
> that Firefox isn't using DXVA2 in Vista, even if both
> media.windows-media-foundation.*-preferences are set to true and
> HW-acceleration is enabled.
> DXVA2 for H264 is working fine on the same machine in Vista in media-players
> like MPC-HC with LAV Filters, so it's probably no driver- or OS-problem.
> 
> [1]: http://bluesky23.yu-nagi.com/en/DXVAChecker.html
> [2]: http://forums.mozillazine.org/viewtopic.php?p=13008365#p13008365


On my Vista I see the DLL "Microsoft DTV-DVD Video Decoder":
Msmpeg2vdec.dll,
Mfh264dec.dll in the folder system32
therefore I should not experience problems with accelerated h264, even vlc and flashplayer are using h264 accelerated, and the gpu does support dxva5, so I hope that these "not old" cards will not be blacklisted by Mozilla.
As said by friend Chris, we wait a few weeks, or until the 17th september with FF24, no problems ;)
(In reply to Chris Pearce (:cpearce) from comment #18)
> FF22 was using not accelerating H.264 decoding using the GPU, it was doing
> everything in software on the CPU. Setting the pref
> media.windows-media-foundation.use-dxva to false makes Firefox go back to
> using the CPU for decoding.

That suggests this is a regression in 23 then?  Can we get a regression range? If there's a low-risk backout we can consider taking it as a ride-along to a 23.0.1
This is a regression from bug 847267. It affects Vista only, on some graphics cards only.

I have acquired a graphics card on which this bug occurs, and I am currently in the process of installing Vista on an old machine so that I can reproduce this and see if I can fix it.

We could easily disable this feature on Vista only with a simple low risk patch. 

We can then either re-enable this feature on Vista once I have figured out how to fix this issue, or if I can't fix it we can blacklist graphics cards that we know we have issues on, and re-enable it on other Vista machines.
OK, I installed Vista on my machine and I discovered that I can reproduce the bug on my nVidia GTS 240 video card. This bug has also been reported on nVidia Cards GTX 460, 8800GTX, and GT450. This makes me think that the bug may be very widespread, affecting a large number, possibly all, nVidia cards on Vista. Possibly it affects vendors of other cards, I just don't know.

I think we should disable DXVA on Vista and ship that in Firefox 23.0.1. We'll fallback to having H.264 decoded in software, just as we did in Firefox 22.

We can then fix this in Nightly and let the proper fix ride the trains, so that we limit the risk of further regressions in our release build.
Disable DXVA on Vista. We will fallback to using software decoding for H.264, as we did in Firefox 22.
Assignee: nobody → cpearce
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #788782 - Flags: review?(ajones)
Attachment #788782 - Flags: review?(ajones) → review+
Comment on attachment 788782 [details] [diff] [review]
Disable DXVA on Vista

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 847267; hardware accelerated H.264 video decoding on Windows using DXVA2.

User impact if declined: Some unknown percentage of Vista users will have the painting of their H.264 videos screwed up. For example see https://bug884203.bugzilla.mozilla.org/attachment.cgi?id=781665
Possibly all Vista users are affected, but it may be limited to all or some subset of nVidia video card owners. 

Testing completed (on m-c, etc.): Just landed this patch to disable hardware acceleration added in bug 847267. We will fallback to our previous software decoding method that we shipped in Firefox 22. I tested this patch on a physical (non-virtual) machine running Vista.

Risk to taking this patch (and alternatives if risky): This patch disables the regressing feature, this is the lowest risk thing that we can do.

String or IDL/UUID changes made by this patch: None.

Because this bug could affect all or at least a large proportion of Vista users, we should take this patch to disable the regressing feature on Aurora, Beta, and Release. I will fix this properly on Nightly and the fix can then ride the trains.
Attachment #788782 - Flags: approval-mozilla-release?
Attachment #788782 - Flags: approval-mozilla-beta?
Attachment #788782 - Flags: approval-mozilla-aurora?
This patch fixes the problem "properly". It seems that on Vista (at least with my nVidia GTS240), we get MF_E_TRANSFORM_TYPE_NOT_SET returned when we try to notify the decoder about the D3DDeviceManager. It seems that this happens because setting the D3D manager enables DXVA, and that affects the input and output types that the decoder can produce. It seems that we can just ignore this error, and the decoder will reconfigure itself to produce frames stored in D3D surfaces with in the correct format using DXVA.

The rendering artifacts we saw were caused by us treating this error as meaning that we can't use DXVA, setting mUseHWAccel=false, but we were not reconfiguring the decoder to output YV12, which is the format that we use when we're using software decoding. So we were still getting NV12, but were interpreting it as YV12, hence the rendering errors. So in this patch I also add code to reconfigure the video decoder if setting up DXVA fails, to ensure that we're outputting video frames in the format that we expect. This means if setup fails for some other reason, we'll fall back to software properly.

I could be wrong about MF_E_TRANSFORM_TYPE_NOT_SET being safe to ignore, which is why I think this fix should ride the trains.
Attachment #788792 - Flags: review?(paul)
Chris, please dont forget the gtx 650! see above ;) thanks.
Comment on attachment 788792 [details] [diff] [review]
Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA

Review of attachment 788792 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/wmf/WMFReader.cpp
@@ +588,5 @@
>      if (SUCCEEDED(hr)) {
>        ULONG_PTR manager = ULONG_PTR(mDXVA2Manager->GetDXVADeviceManager());
>        hr = videoDecoder->ProcessMessage(MFT_MESSAGE_SET_D3D_MANAGER,
>                                          manager);
> +      if (hr == MF_E_TRANSFORM_TYPE_NOT_SET) {

I would have assumed that other project experience the same issue and use the same workaround, but apparently not (I checked VLC and a couple other projects using dxva2).

It seems to work without this workaround for Chrome: http://mxr.mozilla.org/chromium/source/src/content/common/gpu/media/dxva_video_decode_accelerator.cc#660, but I'm not sure if they use dxva2 on vista.

VLC does use dxva2 on Vista, from what I've read, but they don't implement this workaround as well.
Attachment #788792 - Flags: review?(paul) → review+
Comment on attachment 788782 [details] [diff] [review]
Disable DXVA on Vista

Let's get this landed on mozilla-release and mozilla-beta (24) for now.  If the 'proper fix' is low enough risk perhaps it can get uplifted to aurora and maybe even up to beta 24 but for now let's get this out of our larger user populations.  Please set the status to 'disabled' for 23/24 once landed.
Attachment #788782 - Flags: approval-mozilla-release?
Attachment #788782 - Flags: approval-mozilla-release+
Attachment #788782 - Flags: approval-mozilla-beta?
Attachment #788782 - Flags: approval-mozilla-beta+
I dont understand: will ff24 release resolve th issue or there will be a workaround disabling dxva?
ff 26 will be still affected??
We will disable hardware accelerated video in Firefox 23 and Firefox 24 on Vista only. Video will continue to playback on Vista in Firefox 23 and 24 using software decoding, just as it did in Firefox 22.

I will attempt to fix this properly in Firefox 25.
Thanks for your explanation!
I wait for the 29th october (FF25).
(Please look at the PS: on comment #14 too).
This was disabled in Nightly (Fx26) when I landed the changeset in comment 28.
(In reply to Paul Adenot (:padenot) from comment #33)
> Comment on attachment 788792 [details] [diff] [review]
> Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA
> 
> Review of attachment 788792 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: content/media/wmf/WMFReader.cpp
> @@ +588,5 @@
> >      if (SUCCEEDED(hr)) {
> >        ULONG_PTR manager = ULONG_PTR(mDXVA2Manager->GetDXVADeviceManager());
> >        hr = videoDecoder->ProcessMessage(MFT_MESSAGE_SET_D3D_MANAGER,
> >                                          manager);
> > +      if (hr == MF_E_TRANSFORM_TYPE_NOT_SET) {
> 
> I would have assumed that other project experience the same issue and use
> the same workaround, but apparently not (I checked VLC and a couple other
> projects using dxva2).

I'm not sure about VLC, but Chromium's code initializes and uses the H.264 decoder directly, so they have finer control over the startup phase and the order which input/output formats are setup during startup. Whereas we're using the IMFSourceReader API, and have much less control over the startup phase. We're actually passing in the D3DDeviceManager *after* the setup has happened, and I'm guessing on Win7 and later the SourceReader automatically reconfigures to reflect that, whereas on Vista it does not.

I imagine VLC might have finer control over the decoder initialization like Chromium does, since VLC is likely to use their own MP4 demuxer (like Chromium does).
1.) Does this mean 24ESR will never have DXVA for Vista?
2.) Were there also reports of glitches with AMD- and Intel-GPUs on Vista, or why is this feature being disabled for all GPUs on Vista?
the real fix comes with FF26 on the 10th december. it should be a very big issue.
Comment on attachment 788792 [details] [diff] [review]
Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 847267; hardware accelerated H.264 video decoding on Windows using DXVA2.

User impact if declined: Some unknown percentage of Vista users will have the painting of their H.264 videos screwed up.

Testing completed (on m-c, etc.): Landed yesterday on m-c. I tested this patch on a physical (non-virtual) machine running Vista with an nVidia card.

Risk to taking this patch (and alternatives if risky): This patch ignore an error returned by the video decoder. It seems to be safe to ignore that error, but there is some risk of it causing regressions.

String or IDL/UUID changes made by this patch: None.
Attachment #788792 - Flags: approval-mozilla-aurora?
I can't reproduce this issue, using a nVIDIA GeForce GT 610 video card. First I tried with an older version of the video driver (311.06), and then with the latest one (320.49). With neither one of the driver versions was I able to see the problem.

From the 3 videos, only one is available (implemented) on Vista for the moment: WebM (HTML5 video)
(In reply to Manuela Muntean [:Manuela] [QA] from comment #48)
> I can't reproduce this issue, using a nVIDIA GeForce GT 610 video card.
> First I tried with an older version of the video driver (311.06), and then
> with the latest one (320.49). With neither one of the driver versions was I
> able to see the problem.
> 
> From the 3 videos, only one is available (implemented) on Vista for the
> moment: WebM (HTML5 video)

I tested with Firefox 23 release
All the 3 videos are available on Vista.
(try with GTX 650).
(In reply to banakon from comment #50)
> All the 3 videos are available on Vista.
> (try with GTX 650).

I'm sorry, but we only have 610 and 620 video cards.
(In reply to Manuela Muntean [:Manuela] [QA] from comment #49)
> (In reply to Manuela Muntean [:Manuela] [QA] from comment #48)
> > I can't reproduce this issue, using a nVIDIA GeForce GT 610 video card.
> > First I tried with an older version of the video driver (311.06), and then
> > with the latest one (320.49). With neither one of the driver versions was I
> > able to see the problem.
> > 
> > From the 3 videos, only one is available (implemented) on Vista for the
> > moment: WebM (HTML5 video)
> 
> I tested with Firefox 23 release


You need to fully patch your Vista via Windows Update to play H.264 video. You need service pack 1, 2, and you also need the "platform update for Windows Vista" installed.
Samvedana tested this in the QA Lab; we have a Windows Vista PC with an NVidia 8800GTX. She was able to reproduce this issue in Firefox 23.0 but not in Firefox 23.0.1. Based on this I think we can say this is "resolved" in a matter of speaking for Firefox 23.0.1.
QA Contact: samvedana.gohil
Has the proper fix been landed in Nightly 2013-08-14 or earlier? Because I cannot get any logs from "DXVA Checker" regarding usage of DXVA2 in the same way I get logs on Windows 7 with Firefox 23, see the attachment.
There's also no change of cpu-load, which would indicate that hardware-decoding is being used. And there's no way to tell from within Firefox if hardware-decoding is being used or if the software-decoder is used.
Calling this verified disabled for Fx23 as per comment 54.
Samvedana, can you please also confirm this issue is no longer reproducible in the latest Firefox 24 Beta builds?
Comment on attachment 788782 [details] [diff] [review]
Disable DXVA on Vista

Given the potential for unknown regressions in ignoring the error we should let the 'proper' fix ride the trains for the full length of time to collect feedback so let's disable on Aurora as well.
Attachment #788782 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 788792 [details] [diff] [review]
Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA

Approved the disabling patch for Aurora, we'll let this ride from Nightly.
Attachment #788792 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
Samvedana, can you please verify this is no longer reproducible in tomorrow's Firefox 24.0b4 build1 candidate and tomorrow's Firefox 25.0a2 Aurora build?
See also 878030 and bug 908386, this issue occurs on Win7 on at least the following GPUs, with the most up-to-date drivers:

Intel(R) G41 Express Chipset
Mobile Intel(r) 965 Express Chipset

I will track fixing this on Win7 in bug 908386; we need to decide what we're going to do about this issue on Win 7 until the fix in Firefox 26 ships on Release.
Any info regarding comment #56?
I still cannot get any logs as of Nightly 08-27.
I imagine DXVA Checker doesn't detect DXVA when it's used the way we're using it?
Unless Firefox is using DXVA in Vista differently than in Windows 7, "DXVA Checker" detects the usage DXVA just fine in Windows 7 64bit using the latest Nightly (Build ID 20130828030202) and the log looks like the attachment in comment #56.

I assume that the proper fix of comment #31 for Vista is at least not working for my card (8800 GTX), and Firefox is falling back to software-decoding without the user being able to see which decoding-method is being used. DXVA-decoding in Windows 7 on the same machine with the same drivers is working fine.
DXVA-decoding is working fine in my Vista-installation for other programs, for example with current nightlies of the videoplayer MPC-HC ( http://nightly.mpc-hc.org/ ), which also shows up in the "DXVA Checker" trace logs. So there's no fundamental problem with DXVA in Vista at least for my card/driver-combination.

Also, in Windows 7 I can see a difference of the CPU load between hardware (~7%) and software decoding (~11%). I cannot see the same kind of difference with the same Nightly version in Vista, which probably means that Firefox is using software-decoding even if media.windows-media-foundation.use-dxva is set to true.
in ff24 the default value for is media.windows-media-foundation.use-dxva is TRUE!
can vista users enable the accelerated rendering h264 starting from ff26 release?
my question because I dont see this bug in the ff26beta release notes.
I think FF doesn't use DxVA on Vista and it's impossible to enable it.
The restriction regarding Vista should have been lifted in 26, see comment #43.
But then it's impossible to tell if Firefox is using DXVA or not without using third-party tools.
I dont understand.
if FF is not using and will not use dxva this bug is unuseful, but above is written "fixed in FF26" and I want to tell what this means: dxva on or off in ff26?

elbart: if you set the key "dxva enabled", it should use dxva, and if this bug will be fixed in december, with dxva true we will watch the videos without green screen.
"Fixed" refers to the bug as reported; it means that there are no rendering glitches on Vista. This was achieved by disabling DXVA on Vista. DXVA was subsequently re-enabled with a fallback to software decoding if DXVA initialization failed.

So Firefox 26 will try to use DXVA on Vista using the same mechanism that works in other Windows versions, and if that fails, it falls back to software.

I was looking at the VLC and MPC code the other day, and I found that they weren't using DXVA the same way we are. They're using the DXVA video decoder service interface, whereas we're using the IMFSourceReader interface. Maybe it's this difference that is causing DXVA to not work in Firefox but work in other media players on Vista.
Thanks Chris. 
Flash player and silverlight are using accelerated h264 too
we can monitor if ff26 on vista will use dxva by watching the task manager:
i.e. if 1080p video = 3% CPU load, then we can say that dxva is working properly. If we will see 30% we know that dxva is not active.
please tell me/us the nvidia driver version you are using, 
the drivers that on your vista are able to guarantee no rendering glitches with dxva *enabled*. this is important. the integration between nvidia and firefox!
default:
media.windows-media-foundation.use-dxva;true

FF25.
"So Firefox 26 will try to use DXVA on Vista using the same mechanism that works in other Windows versions, and if that fails, it falls back to software."

why it may fail the initialization?
it is very important to suggest the correct nvidia driver build, the build that works on your test machine, should become our build.
@the dev which handles this bug for vista:

what graphic card are you using for testing?
I have the gtx 650 with driver 320.18
GTS 240. Do you still see the glitches on your machine?
Ok gts 240 is old, so I guess that there will be no issue with newer cards like gtx.
I wait ff26 for testing, because I would like to see if the h264 html5 video will work well with acceleration enabled.
Hi Chris,

FF26. Gtx650
accekleration active. dxva true.
rendering glitches on Vista resolved.
I guess (not sure, but I guess) that the GPU acceleration is enabled, because the first video High profile (first post) requires 5-9-13% CPU load.
Component: Audio/Video → Audio/Video: Playback
shouldn't we close that bug? last update was almost 2 years ago
(In reply to Jean-Yves Avenard [:jya] from comment #82)
> shouldn't we close that bug? last update was almost 2 years ago

I'll put that to :cpearce since he added the [leave open] tag to this bug. In general if there's more work to do in this bug it should remain open, otherwise it should be closed.
Flags: needinfo?(cpearce)
I think we can close this now.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(cpearce)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.