Avoid complex clips when painting with D2D

RESOLVED FIXED in Firefox 26, Firefox OS v1.2

Status

()

Core
Layout
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: mattwoodrow, Assigned: mattwoodrow)

Tracking

unspecified
mozilla28
x86
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox25 wontfix, firefox26 fixed, firefox27 fixed, firefox28 fixed, b2g-v1.2 fixed)

Details

(Whiteboard: [qa-])

Attachments

(6 attachments)

(Assignee)

Description

4 years ago
This may help with bug 812695, and should overall just perform better with D2D.

Try server: https://tbpl.mozilla.org/?tree=Try&rev=950bf785509c
(Assignee)

Comment 1

4 years ago
Jeff, can you please check if this helps with bug 812695, since I believe you can reproduce it locally.

Might pay to check that we're actually not hitting the complex clip path, clips might be being added from somewhere else.
Flags: needinfo?(jmuizelaar)
(Assignee)

Updated

4 years ago
Assignee: nobody → matt.woodrow
(Assignee)

Comment 2

4 years ago
Better try push: https://tbpl.mozilla.org/?tree=Try&rev=db5c62951922
Since Jeff hasn't responded yet, I figured I might as well: the try build doesn't affect the issue seen in bug 812695 on my laptop (it's still there).
(Assignee)

Comment 4

4 years ago
I can see at least one reason why that might be, this try push may or may not be better :)

https://tbpl.mozilla.org/?tree=Try&rev=c091818f8584
Whatever you changed, it seems to have helped tremendously! I can't confirm whether the issue is 100% fixed, but I didn't see any problems scrolling various pages that usually show the issue right away :)
(Assignee)

Comment 6

4 years ago
Reorganized a bit and fixed the reftest failures: https://tbpl.mozilla.org/?tree=Try&rev=c03125f5f428
(Assignee)

Comment 7

4 years ago
Created attachment 827826 [details] [diff] [review]
Part 1: Avoid assertions when trying to draw an inactive layer item twice

Currently we have this pretty weird system where we initiate the transactions for inactive layer managers during layer construction, and then (hopefully) end them during painting. We also have to have code in the ClippedDisplayItem dtor to clean up any that didn't actually get painted this time.

This doesn't work (or rather, asserts) if we end up trying to paint the same display item twice.

This patch just makes us start and end the transaction in both places separately.
Attachment #827826 - Flags: review?(roc)
(Assignee)

Comment 8

4 years ago
Created attachment 827827 [details] [diff] [review]
Part 2: Factor out some parts of DrawThebesLayer

More preparation work and cleanup.
Attachment #827827 - Flags: review?(roc)
(Assignee)

Comment 9

4 years ago
Created attachment 827828 [details] [diff] [review]
Part 3: Don't clip in the callers of DrawThebesLayer

Instead of clipping in the callers of DrawThebesLayer, this moves all clipping to happen within DrawThebesLayer itself.

I really don't know why we have 3 different ways of clipping, but changing it causes reftest failures. I haven't looked into this too much.
Attachment #827828 - Flags: review?(roc)
(Assignee)

Comment 10

4 years ago
Created attachment 827829 [details] [diff] [review]
Part 4: Paint one rect at a time with Direct2D
Attachment #827829 - Flags: review?(roc)
(Assignee)

Comment 11

4 years ago
Created attachment 827830 [details] [diff] [review]
Part 5: Avoid painting display items that aren't in the current clip rect
Attachment #827830 - Flags: review?(roc)
Attachment #827826 - Flags: review?(roc) → review+
Attachment #827827 - Flags: review?(roc) → review+
Comment on attachment 827828 [details] [diff] [review]
Part 3: Don't clip in the callers of DrawThebesLayer

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

::: gfx/layers/client/ContentClient.cpp
@@ +886,5 @@
>      return result;
>    }
>    result.mContext->Translate(-gfxPoint(drawBounds.x, drawBounds.y));
>  
> +  result.mClip = CLIP_DRAW;

I tihnk you should keep the comment.

::: gfx/layers/opengl/ThebesLayerOGL.cpp
@@ +819,5 @@
>    result.mContext->Translate(-gfxPoint(quadrantRect.x, quadrantRect.y));
>    // Move rgnToPaint back into position so that the thebes callback
>    // gets the right coordintes.
>    result.mRegionToDraw.MoveBy(-offset);
> +  result.mClip = CLIP_DRAW;

Keep the comment.
Attachment #827828 - Flags: review?(roc) → review+
Comment on attachment 827829 [details] [diff] [review]
Part 4: Paint one rect at a time with Direct2D

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

This seems very sad. what's wrong with D2D?

::: layout/base/FrameLayerBuilder.cpp
@@ +3320,5 @@
>      static_cast<ThebesDisplayItemLayerUserData*>
>        (aLayer->GetUserData(&gThebesDisplayItemLayerUserData));
>    NS_ASSERTION(userData, "where did our user data go?");
> +
> +  if (!ShouldDrawRectsSeparately(aContext, aClip)) {

Call this once and store the result so we can use it below.
Attachment #827829 - Flags: review?(roc) → review+
Attachment #827830 - Flags: review?(roc) → review+
(Assignee)

Comment 14

4 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #13)
> Comment on attachment 827829 [details] [diff] [review]
> Part 4: Paint one rect at a time with Direct2D
> 
> Review of attachment 827829 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This seems very sad. what's wrong with D2D?

Bas would be a better person to answer this, but I'll give it a shot.

Direct2D doesn't support anything other than axis aligned rects (not regions) as a clip, so we have to do a lot of extra work to support 'complex' clips. We need to push a group/layer for each drawing primitive that happens when we're clipped.

Jeff also thought that this was likely to be the reason we were hitting bug 812695, which appears to be true.
Testing the try build with cset: http://hg.mozilla.org/try/rev/c091818f8584 

seems to have cleared most if not all the issues with font corruption.

However, I noted this morning that scrolling on m-c tbpl with this build there are really strange paint issues on the page, it blanks out, wait several seconds and it will properly display, each scroll blanks out, then refreshes after a few seconds.  TBPL is the only page I've seen so far that behaves this way, so maybe something unique to TBPL.
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #15)
> However, I noted this morning that scrolling on m-c tbpl with this build
> there are really strange paint issues on the page, it blanks out, wait
> several seconds and it will properly display, each scroll blanks out, then
> refreshes after a few seconds.  TBPL is the only page I've seen so far that
> behaves this way, so maybe something unique to TBPL.
I saw something like this on my desktop PC (which has an nvidia card) when refreshing my e-mails in gmail. It looked like a strip was missing (white) for a second before correcting itself. I saw this twice on gmail but couldn't reproduce, so figured it might be gmail itself. Didn't see any problems in a brief test with tbpl, but maybe it's the same issue.
Correction: this was using c091818f8584 on my laptop (to confirm the fix) and my desktop (to make sure everything else was fine).

I tested tbpl just now using c03125f5f428 (which I just noticed also starts with c0) and haven't seen the problem yet.
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #17)
> Correction: this was using c091818f8584 on my laptop (to confirm the fix)
> and my desktop (to make sure everything else was fine).
> 
> I tested tbpl just now using c03125f5f428 (which I just noticed also starts
> with c0) and haven't seen the problem yet.

I sure hope this is not another AMD problem then in different form.  
I use an AMD HD3200 chipset/video on a AMD Phenon II Quad-core CPU.
I see the issues reported the build from comment #4 - it's very obvious on tbpl. However, I've encountered no problems using the try build from comment #6 - so I think this issue was fixed along with the reftest failures.
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #19)
> I see the issues reported the build from comment #4 - it's very obvious on
> tbpl. However, I've encountered no problems using the try build from comment
> #6 - so I think this issue was fixed along with the reftest failures.

Ahh, yes !  No more corruption on tbpl with the try build from comment #6, completely overlooked there was another try build. 

Good Work guys.
Alice, can you still reproduce the problems from bug 812695 with the try build from comment #6?

Comment 22

4 years ago
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #21)
> Alice, can you still reproduce the problems from bug 812695 with the try
> build from comment #6?

I cannot reproduce the font problem(STR:Bug 812695 Comment#74) on the try build of comment#6.
(Assignee)

Comment 23

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e3639f686cb2
https://hg.mozilla.org/integration/mozilla-inbound/rev/05d1961093c1
https://hg.mozilla.org/integration/mozilla-inbound/rev/7bd003284099
https://hg.mozilla.org/integration/mozilla-inbound/rev/e1f4fbc3c9d1
https://hg.mozilla.org/integration/mozilla-inbound/rev/82ff69542540
(Assignee)

Comment 24

4 years ago
Thanks for everyone's help testing this!
Flags: needinfo?(jmuizelaar)
https://hg.mozilla.org/mozilla-central/rev/e3639f686cb2
https://hg.mozilla.org/mozilla-central/rev/05d1961093c1
https://hg.mozilla.org/mozilla-central/rev/7bd003284099
https://hg.mozilla.org/mozilla-central/rev/e1f4fbc3c9d1
https://hg.mozilla.org/mozilla-central/rev/82ff69542540
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
(Assignee)

Comment 26

4 years ago
Looks like this regressed some SVG talos testing, looking into it.
(Assignee)

Comment 27

4 years ago
The SVGx subtests that regressed were hixie-005.xml and hixie-006.xml.

Basically the entire CPU time for these tests is painting gradients.

The same regression doesn't happen on OSX (even with the flag flipped so we get the actual behaviour change).

I'm pretty sure this is because we're processing each display item multiple times, and without a gradient cache for SVG, we have to rebuild the stops object each time. This is expensive for d2d and explains the regression, and why it's limited to these tests.
Target Milestone: mozilla28 → ---
(Assignee)

Comment 28

4 years ago
Looks like bug 930451 is fixing this.

Setting up a try push to see if that is landable, and confirm that it fixes the regression.
Depends on: 930451
Target Milestone: --- → mozilla28
(Assignee)

Comment 29

4 years ago
Confirmed that it fixes the regression, and then some. It's currently crashing on some crashtests though, will try get that fixed and landed asap.

Updated

4 years ago
Blocks: 812695
Branch uplift attempts:
Aurora: https://tbpl.mozilla.org/?tree=Try&rev=dfcdbd84c8c6
Beta: https://tbpl.mozilla.org/?tree=Try&rev=2594f2dd290a
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #30)
> Branch uplift attempts:
> Aurora: https://tbpl.mozilla.org/?tree=Try&rev=dfcdbd84c8c6
> Beta: https://tbpl.mozilla.org/?tree=Try&rev=2594f2dd290a

Looking remarkably green on the stuff that matters :)
(Assignee)

Comment 32

4 years ago
Comment on attachment 827826 [details] [diff] [review]
Part 1: Avoid assertions when trying to draw an inactive layer item twice

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Moz2D content
User impact if declined: Broken text rendering for some users - bug 812695
Testing completed (on m-c, etc.): Been on m-c for a few days, multiple affected users have confirmed that it fixes bug 812695.
Risk to taking this patch (and alternatives if risky): Reasonably big change to the way we render, but is limited to direct2d and very easy to revert if necessary. No real alternative other than continue shipping the broken text.
String or IDL/UUID changes made by this patch: None.

This patch queue alone caused a significant regression to SVG gradient rendering with direct2d, showing up as ~20% tsvgx talos regression, with the gradient sub-tests almost doubling. This is fixed (and actually improves) with bug 930451, which I think we should uplift at the same time as this bug.

It also caused a couple of windows 8 only talos changes. A ~6% improvement for tscroll, and a ~9% regression for tresize. The latter is being tracked in bug 936521. I think this bug is important enough to uplift even if this regression can't be fixed in time.
Attachment #827826 - Flags: approval-mozilla-beta?
Attachment #827826 - Flags: approval-mozilla-aurora?

Comment 33

4 years ago
(In reply to Matt Woodrow (:mattwoodrow) from comment #32)
> User impact if declined: Broken text rendering for some users - bug 812695

Note that while this has been around for quite a while (roughly since IE10 for Win7 was released), it's a bug that has gotten a ton of complaints and probably people leaving Firefox over it.
In addition, Windows 8.1 exhibits the problem by default for people affected, so the problem's scope increased recently.
Attachment #827826 - Flags: approval-mozilla-beta?
Attachment #827826 - Flags: approval-mozilla-beta+
Attachment #827826 - Flags: approval-mozilla-aurora?
Attachment #827826 - Flags: approval-mozilla-aurora+
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → fixed
https://hg.mozilla.org/releases/mozilla-aurora/rev/8ec63d52437e
https://hg.mozilla.org/releases/mozilla-aurora/rev/813bcdac20ff
https://hg.mozilla.org/releases/mozilla-aurora/rev/c0ab158ff967
https://hg.mozilla.org/releases/mozilla-aurora/rev/05c2a19d916d
https://hg.mozilla.org/releases/mozilla-aurora/rev/99414b953810

https://hg.mozilla.org/releases/mozilla-beta/rev/95f496bd733d
https://hg.mozilla.org/releases/mozilla-beta/rev/dc14c876fba6
https://hg.mozilla.org/releases/mozilla-beta/rev/866ff3287e56
https://hg.mozilla.org/releases/mozilla-beta/rev/015c3674108a
https://hg.mozilla.org/releases/mozilla-beta/rev/6112868d6c81
status-firefox25: affected → wontfix
status-firefox26: affected → fixed
status-firefox27: affected → fixed
Depends on: 931028
No longer depends on: 931028
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/95f496bd733d
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/dc14c876fba6
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/866ff3287e56
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/015c3674108a
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/6112868d6c81
status-b2g-v1.2: --- → fixed
Depends on: 937519

Updated

4 years ago
Depends on: 937972
(Assignee)

Updated

4 years ago
Depends on: 938395
(Assignee)

Comment 37

4 years ago
We may want to back this out of aurora/beta.

We currently have a few regressions from this: bug 937519, bug 936521 and bug 937972.

I can fix 937972 fairly easily, and get this uplifted.

I'm currently working on fixes to the regressions for bug 937519, but it's not currently clear if we can easily fix them.

We don't/won't have australis on aurora/beta, but it's very possible that this performance regression will affect real web content as well, and we just don't have performance tests for them.

It's not clear yet how easy it will be to uplift the performance fixes to the branches.
Flags: needinfo?(lsblakk)
(Assignee)

Comment 38

4 years ago
Created attachment 831921 [details] [diff] [review]
Part 6: Add pref to disable this

We can land this (with the default swapped or with an entry in prefs.js) to disable this patch, while still give users affected by the bug an option to use it.
Attachment #831921 - Flags: review?(jmuizelaar)
(Assignee)

Comment 39

4 years ago
Added a patch to bug 937972 that we'll need to uplift if we leave these patches on aurora/beta.
I don't want to complicate the situation any further, but if a pref can enable this on Beta and Aurora, would it be possible to tie that to the hardware or (perhaps more simply) driver version used? I think all or at least most of the hardware affected by this is on the Legacy driver offered by AMD (device manager shows this to be version 8.970.100.110 for my ATI Mobility Radeon HD 4650). If information from around the web is to be believed, the latest normal display driver has version 13.250.18.0, so I imagine they'd be easy to distinguish.
Attachment #831921 - Flags: review?(jmuizelaar) → review+
Let's back out for now, perhaps it can be reconsidered again for Aurora, but without tests to help catch performance regressions we should really have more bake time on pre-release branches next time.
Flags: needinfo?(lsblakk)
(Assignee)

Comment 42

4 years ago
Comment on attachment 831921 [details] [diff] [review]
Part 6: Add pref to disable this

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 934860
User impact if declined: Performance regression for some dynamic content
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): 
String or IDL/UUID changes made by this patch: None

Can we land this patch to disable the changes rather than backing out? It'll be a lot easier if we decide to re-enable it in the future, and it provides a good workaround for users affected by the original bug.
Attachment #831921 - Flags: approval-mozilla-beta?
Attachment #831921 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 43

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/6887b71d36ee
(Assignee)

Comment 44

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ab7264010d2a
https://hg.mozilla.org/mozilla-central/rev/6887b71d36ee
https://hg.mozilla.org/mozilla-central/rev/ab7264010d2a
Flags: in-testsuite?

Updated

4 years ago
Keywords: verifyme
Blocks: 939826
Attachment #831921 - Flags: approval-mozilla-beta?
Attachment #831921 - Flags: approval-mozilla-beta+
Attachment #831921 - Flags: approval-mozilla-aurora?
Attachment #831921 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/de17c895d5b8
https://hg.mozilla.org/releases/mozilla-beta/rev/2bcc119c46d9
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/2bcc119c46d9
I was able to reproduce Bug 812695 (dependency) by following the scenarios described by:
- Alice0075 White in Comment 74 (partially reproducible, using the sample HTML page),
- Eduard Braun in Comment 106 (completely reproducible, using the test cases),
using Windows 7 x64 with Nightly 18.0a1 (BuildID: 20121006134717): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0.

Altough slight distortions can still be noticed temporarily, while scrolling through the sample HTML page provided by Alice, the behavior from Aurora 27.0a2 (BuildID: 20131129004001): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0, is better than the one encountered on the above stated Nightly 18.0a1.

Matt, could you please provide some steps to reproduce for *this* issue, so that we can verify the fix made specifically for this bug?
Flags: needinfo?(matt.woodrow)

Comment 49

4 years ago
(In reply to Andrei Vaida, QA [:AndreiVaida] from comment #48)
> I was able to reproduce Bug 812695 (dependency) by following the scenarios
> described by:
> - Alice0075 White in Comment 74 (partially reproducible, using the sample
> HTML page),
> - Eduard Braun in Comment 106 (completely reproducible, using the test
> cases),
> using Windows 7 x64 with Nightly 18.0a1 (BuildID: 20121006134717):
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0.
> 
> Altough slight distortions can still be noticed temporarily, while scrolling
> through the sample HTML page provided by Alice, the behavior from Aurora
> 27.0a2 (BuildID: 20131129004001): Mozilla/5.0 (Windows NT 6.1; WOW64;
> rv:27.0) Gecko/20100101 Firefox/27.0, is better than the one encountered on
> the above stated Nightly 18.0a1.
> 
> Matt, could you please provide some steps to reproduce for *this* issue, so
> that we can verify the fix made specifically for this bug?

I have found an easy way for myself to reproduce bug 812695:
1) Right click just a hair below the address bar on the empty space below it
2) Choose the bottom item "Configure..." in the context menu
3) In the resulting window, some of the text will appear very distorted (garbled, rainbow-like) for the first few seconds, after which it corrects itself.

With the workaround (layout.paint_rects_separately) applied the resulting window displays all the text correctly right immediately upon opening.
Dusty, I was unable to reproduce Bug 812695 using your STR with:
1. Nightly 18.0a1 (BuildID: 20120901030528): Mozilla/5.0 (Macintosh; intel Mac OS X 10.6; rv:18.0) Gecko/18.0 Firefox/18.0 (Mac OS X 10.6.8)
2. Nightly 18.0a1 (BuildID: 20121006134717): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 (Windows 7 x64.)

I added the "layout.paint_rects_separately" (true) entry in about:config despite my results, but I didn't notice any change in the browser's behavior, neither on Mac OS X 10.6.8 nor on Windows 7 x 64.

I was only able to reproduce Bug 812695 using Alice0075 White and Eduard Braun's comments, as mentioned in my previous comment. Also, as previously mentioned, on Aurora 27.0a2 this issue is partially still reproducible.
(Assignee)

Comment 51

4 years ago
(In reply to Andrei Vaida, QA [:AndreiVaida] from comment #48)
> I was able to reproduce Bug 812695 (dependency) by following the scenarios
> described by:
> - Alice0075 White in Comment 74 (partially reproducible, using the sample
> HTML page),
> - Eduard Braun in Comment 106 (completely reproducible, using the test
> cases),
> using Windows 7 x64 with Nightly 18.0a1 (BuildID: 20121006134717):
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0.
> 
> Altough slight distortions can still be noticed temporarily, while scrolling
> through the sample HTML page provided by Alice, the behavior from Aurora
> 27.0a2 (BuildID: 20131129004001): Mozilla/5.0 (Windows NT 6.1; WOW64;
> rv:27.0) Gecko/20100101 Firefox/27.0, is better than the one encountered on
> the above stated Nightly 18.0a1.
> 
> Matt, could you please provide some steps to reproduce for *this* issue, so
> that we can verify the fix made specifically for this bug?

This is a patch that is meant to fix bug 812695, so these STR should be.

But it's disabled without layout.paint_rects_separately=true, so we expect these tests to still reproduce the issue on all branches.
Flags: needinfo?(matt.woodrow)
(In reply to Matt Woodrow (:mattwoodrow) from comment #51)
> (In reply to Andrei Vaida, QA [:AndreiVaida] from comment #48)
> > I was able to reproduce Bug 812695 (dependency) by following the scenarios
> > described by:
> > - Alice0075 White in Comment 74 (partially reproducible, using the sample
> > HTML page),
> > - Eduard Braun in Comment 106 (completely reproducible, using the test
> > cases),
> > using Windows 7 x64 with Nightly 18.0a1 (BuildID: 20121006134717):
> > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0.
> > 
> > Altough slight distortions can still be noticed temporarily, while scrolling
> > through the sample HTML page provided by Alice, the behavior from Aurora
> > 27.0a2 (BuildID: 20131129004001): Mozilla/5.0 (Windows NT 6.1; WOW64;
> > rv:27.0) Gecko/20100101 Firefox/27.0, is better than the one encountered on
> > the above stated Nightly 18.0a1.
> > 
> > Matt, could you please provide some steps to reproduce for *this* issue, so
> > that we can verify the fix made specifically for this bug?
> 
> This is a patch that is meant to fix bug 812695, so these STR should be.
> 
> But it's disabled without layout.paint_rects_separately=true, so we expect
> these tests to still reproduce the issue on all branches.

Hi Matt, as I previously specified in Comment 48 and Comment 50, I was able to only partially reproduce Bug 812695. 

Unfortunately, the "layout.paint_rects_separately=true" pref does not seem to work on my end.
Keywords: verifyme
Assignee: matt.woodrow → jmuizelaar
Assignee: jmuizelaar → matt.woodrow
Whiteboard: [qa-]
Depends on: 920227
You need to log in before you can comment on or make changes to this bug.