single-pixel rendering error when scrolling document (120DPI, 125DPI)

VERIFIED FIXED in mozilla1.0.1

Status

()

defect
P1
normal
VERIFIED FIXED
18 years ago
5 years ago

People

(Reporter: Ventifus, Assigned: kmcclusk)

Tracking

(Blocks 1 bug, 4 keywords)

Trunk
mozilla1.0.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2 RTM] [ETA 06/21])

Attachments

(14 attachments, 6 obsolete attachments)

4.09 KB, image/png
Details
6.37 KB, image/png
Details
4.49 KB, image/png
Details
5.92 KB, text/html
Details
3.37 KB, image/png
Details
2.96 KB, image/png
Details
545 bytes, text/html
Details
75.56 KB, image/gif
Details
65.06 KB, image/gif
Details
4.08 KB, text/html
Details
216 bytes, text/plain
Details
25.60 KB, image/gif
Details
26.73 KB, image/gif
Details
3.83 KB, patch
dbaron
: review+
waterson
: superreview+
Details | Diff | Splinter Review
version 0.9:

When scrolling the page, the browser will intermittently shift a line of
rendering either up or right. I don't know if there is a specific page structure
needed to reproduce this bug, but it happens on many web sites (slashdot, for
instance). This only occurs with text, and seems to only happen while scrolling
down with the keyboard's arrow keys, not with pagedown, and not with the
scrollbars. Could a high (i.e. maximum speed) keyboard repeat-rate be triggering
this? Also, if I select the text, or otherwise force a repaint, it gets properly
redrawn.

I'm pretty sure that this also occurs on Windows, but I'll have to verify that.
I am seeing the same thing all the time with 0.9.2 milestone and have for
several versions now.  I can usually reproduce it by mousewheel or arrow
scrolling on the following page:

http://news.bbc.co.uk/hi/english/world/

PgUp/PgDown/Space and scrollbars do not seem to have this problem.

I am running:
Redhat 7.1
Ximian Gnome 1.4
XFree86 4.0.3 on a GeForce2 GTS (Nvidia driver)
One other unusual condition: running Fontastic font server (from WordPerfect
Office 2000) in addition to xfs

The artifacts usually occur in the same position on the page.  I.e. I scroll
with mousewheel and get an artifact.  Scoll with scrollbar to get rid of it. 
Scrolling around with the mousewheel again gives the same artifact in the same
place.
You just reminded me that I (stupidly) forgot to include the vital statistics on
my machine. It is:

Redhat 7.1; kernel 2.4.5
XFree4.0.3, nVidia-supplied driver, v1.0-1251 (geForce2 GTS)
I am not running the WP font server.
My machine has 2 processors which might have a bearing.
I suspect that this problem has something to do with the X server or video
driver. I tried reproducing the problem by using the Exceed server and a RH7.0
client, but the bug did not manifest. I'll experiment with using the XFree nv
driver, and perhaps XFree 3.x.
This seems to be dup of bug 63336 (see also bug 16200).

You can try if setting display resolution (Prefs: Appearance: Fonts) to 96 dpi
helps.
Hey, that works for me.  I had switched the resolution to 100 dpi at some point
and switching back to 96 definitely fixes the text display problems and also
some single-pixel white lines that were cropping up in some images.  Thanks!
Upgraded to milestone 0.93 and this problem seems to be back.  I've tried
setting DPI to "System setting" and that doesn't help. I'm getting single pixel
errors in text and images.
I also see this on 0.9.4 on :
WinME
ATI Radeon 32MB DDR (driver 4.13.7115)
120dpi fonts at 1024x768.


 
Need a reduced test case.
Keywords: qawanted
What do you mean by reduced?
I'm seeing this happen only on one systems -- others don't reproduce.
Maybe its a thing with my video drivers, maybe my font sizes, etc.
Would you like me to post a screenshot?
I'd be happy to provide more info/assistance. (Short of installing BackOrifice
in my box :) )
I can't help with a reduced test case, it never happens (for me) in exactly the
same position, and rarely (never?) on simple pages.

I can almost always reproduce it though by going to Slashdot on loading a page
in nested mode (produces a long page with semi-complex layout) and scrolling
down a bunch of screens.

I'm getting the bug in 0.9.3 (and earlier), I'm running
Win2k SP1
P3 600 (OCed) on P3V4X
512MB
Asus GeForce 2 w/ nVidia drivers. 20.x or something fairly new. (Doesn't say in
the properties, lists it as 5.12.xxx)
I'm not seeing this anymore on 0.9.5 under the conditions I listed in my earlier
notes.  I don't think I've seen it for a while but didn't notice before that the
problem is gone.  Perhaps you guys should try 0.9.5 and see if it still happens.
Still present for me on 0.9.5 on both my Windows ME box
and my RedHat 7.2 box.
not a table specific bug, reassigning to core owner.
Assignee: karnaze → attinasi
With build 2001121808 I see this in the regular text of slashdot now (when
scrolling with the mouse wheel and then stopping).  Previously it was in the
headings.  I've also seen this in mail with this build.

Damn hard to reproduce though,
I am seeing this in 20020111 (Linux Mandrake 8.0) especially on
http://slashdot.org . I've noticed that if you highlight the problem text then
it magically cures itself until you scroll it off and back on again.
Notice that a line has "run" on the left of the roundered box edge
Scrolling with the arrow keys/mouse wheel helps to show this bug up because the
page is not entirely blanked/refreshed in one go. Anything that causes mozilla
to redraw the page clears up the problem.

I am using Truetype fonts with mozilla (MS Verdana is being used on the /.
page). My distribution is Linux Mandrake 8.0 Intel. I am using XFree 4.0.3 with
the Nvidia drivers (I have a geforce 1). The drivers auto detect a resolution of
72dpi with my current monitor. I can try testing with the default XFree 4
drivers if people think it will help...
Problem is mild but occured in a window of 800x600 by scrolling from the top to
the bottom of the testcase with the down arrow key.
Attachment #64694 - Attachment mime type: text/plain → text/html
Taking this bug
Assignee: attinasi → kmcclusk
Whiteboard: DUPME
Target Milestone: --- → mozilla1.1
Could be related to bug 63336, but bug 87738 is probably better for addressing 
the original problem.
Adding bug 97861 to the list of possibilities
I just wiped my profile and started from scratch with 0.9.8.  When I did this, I
reintroduced this bug (it had left me).  I noticed it on the article icons on
Slashdot.  I fixed it by switching font resolution from "System" to "96 dpi". 
My system details are in an earlier comment (#2).  I have not noticed any
problems with text, only with some images.

An additional note:  I installed Wordperfect 2000 in the past which has its own
type manager in addition to XFS.  It's possible this affects the situation.
I see this issue w/ 0.9.8 (build ID 2002020516) on Solaris, so it's not a
Linux-specific bug.  And I don't believe I'm using any of the special font
handers the Linux users are -- just whatever comes with Solaris 2.8.  I haven't
tried setting DPI to 96 yet.
Just to clarify, it turns out I was using the standard XFree86 font server, NOT
the special one that comes with Wordperfect so I think we can rule out freaky
font servers.
OK, I'm setting Plat/OS to All/All, because I see this on windows 2000 (0.9.8,
dpi=96, system dpi=125). I think it's very likely that one of those "rounding
error" bugs is the culprit. However, I don't understand the internals enough to
just go ahead and mark this bug as a dup (probably of 63336).

My vague and inaccurate impression is that this bug is more common on complex
pages, like slashdot. It still occurs on simple pages (like this bug page), just
less often.
OS: Linux → All
Hardware: PC → All
Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.
Priority: -- → P2
Target Milestone: mozilla1.1 → Future
This behavior appeared upon upgrading to 0.9.8 on my home computer.  I haven't
seen it on various other copies of .9.8 that I am using, so it is something
specific to this setup.  Around the time I upgraded mozilla I did a general
update (using debian testing + ximian), so other things may have changed around
that time as well.  It appears in both mozilla and galeon.  If there are any
specific things to check I can do that (and am quite willing to), but
unfortunately I have no idea where to begin looking to figure out what is going
on here.

Note that changing the dpi settings did not fix this for me, as it did for a
previous reporter.

I also do _not_ think this bug should have a low priority - for those who
experience this (and it seems fairly cross platform) it is a very annoying
visual bug.  But of course I have no idea how to fix it so maybe I shouldn't
talk :-)
I have to agree w/ poster 28.  This occurs for me on Linux and Win2000 machines.
 Co-workers that have noticed it have scoffed at the browser with quotes like
"Well IE doesn't do *that*".

This should not be a low priority issue.  Its easily as serious as any deviance
from a standard.
about to attach paired xmag shots - one of the rendering bug in action, one of
the same section of the page when rendered 'correctly' (i.e. after
highlighting).  These shots are useful for several reasons:

- I went to some trouble to make sure that they lined up correctly; you can
easily flip back and forth between them and see clearly all the differences that
appear.

- They demonstrate that the problem is not just text - it is most noticable in
text, but appears in images, as in the left side of a slashdot headline which is
shown here.  This bug is almost certainly a dup of 87738 (or that one a dup of
this), but many of the posts there seem to be under the belief that the problem
is entirely font-based.

- They show an example of several strange and related things going on at once. 
There is an entire line which shifts a pixel, and this phenomena is really only
noticable under xmag.

Now if only someone with the knowledge of the layout code was paying attention
to this bug... :-)
lined up with previous attachment by the vertical bar on the left, and the top
of the green area.
Can you tell I don't like this bug?

First of all, I think I spoke in error earlier: changing to 96dpi apparently
fixed the problem, but only after restarting mozilla.  Switching back to system
causes the problem to reappear.

I have come up with a reduced testcase and and a mechanism that (at least for
me) allows at will duplication of the visual error.  Please post if this works
for you as well (assuming anyone at all is listening).

To reproduce the bug, on a page that can induce it (more about this later, but
slashdot comment pages and my test case which I will post shortly should work),
open a new window and move it so that a window edge, horizontal or vertical, is
covering some text.  It's best for the edge of the window to cross through a
character that if it's glitched is noticeable, 'e' in most fonts works for me. 
Then either move the window away, or shade it, so that some of the page is
uncovered.  You should see that portions of the text have slid to the left. 
Highlighting will cause the text to be redrawn correctly.

This is helpful to look at in galeon: when you refocus the window whatever
redrawing is needed for the correct version gets done, so I see large portions
of the text move at once.  Mozilla doesn't seem to do this; you need to
highlight to get it to redraw.

I arrived at a test case after much suffering with code produced by slashdot (it
would be educational for some of the people who write slashcode to do something
like what I did, I think).  It consists of a table with a single cell.  The cell
has the attributes 'width="99%" align="center"'.  Remove either of these and the
problem goes away.  Changing the alignment to either left or right causes the
problem to go away.  Changing the width to 100% causes the problem to go away. 
I imagine that some other percentile values of width would show the problem,
though I didn't test that.  

This looks like a rounding error in that in two different pieces of code which
are used for the same purpose (?!?) the rounding is performed differently, or
the same piece of code does the rounding differently under different circumstances.
as noted before, the important part here are the two attributes of the table
entity.  To get the problem to show on this test case (assuming it shows at all
on your computer) see my previous comment.  If this doesn't work for anyone who
has observed this bug on their system, please let me know - I have no way of
testing this except on my computer at home.
I get what appears to be two different but very related problems.  I'm using
mozilla 0.9.9 and have a screen resolution of 1600x1200.  First if I have the
horizontal size of the Mozilla window at or above 1382 I can get 1 pixel
shifting when slashdot loads, actually slashdot starts out correct but near the

end of the rendering process the stuff gets shifted.  Attached is an animated
gif of the problem.
I'm using mozilla 0.9.9 and have a screen resolution of 1600x1200.  This is an
example of the 1 pixel shifting that occures when I scroll around the web page,
this shifting happens when the horizontal window size is 922 pixels or larger.
Bug 134638 is probably a dub of this
Blocks: 134942
This bug has been around forever, and is probably also related to all the other
'off by 1 pixel' scrolling bugs (like the 'white stripe', and 'extra row of
pixels' bugs - which seem to be fixed lately).

For what it's worth, it's not the single distorted line that's affected.  What
seems to be happening is that the top 'half' of the window is shifted relative
to the bottom 'half', and the two halves just happen to meet on the affected
line of text.  It's gotta be related to the fact that when you scroll, part of
the window is simply scrolled, while the other part is repainted from scratch. 
The two parts are just not in horizontal alignment.

Yes, it's a 'trivial cosmetic issue'.  No, it's not unimportant.

It's probably the most visible, obvious bug that the unsophisticated user (read:
all those AOL users that are about to come on board) is certain to notice.  And
it screams "unprofessional".

Plus - it's easily reproducable, so it ought to be fixable.
An alternative for 1.0 would be to default to either 72dpi or 96dpi, and maybe
label 2system setting" as experimental. 

For the record, I've seen this  at home with 73x73dpi and at work with 90x89
dpi, both taken from xdpyinfo (mandrake linux 8.*, xfree86 v4.2).
Summary: single-pixel rendering error when scrolling document → single-pixel rendering error when scrolling document (120DPI, 125DPI)
Whiteboard: DUPME
Work in progress - Align all frames (x,y,width,height) on pixel boundaries when
Attachment #78997 - Attachment is obsolete: true
Attachment #78999 - Attachment description: Same as above patch but include XP_UNIX → Align frames on pixel boundaries
Keywords: nsbeta1
Priority: P2 → P1
*** Bug 122577 has been marked as a duplicate of this bug. ***
Attachment #78999 - Attachment is obsolete: true
*** Bug 112673 has been marked as a duplicate of this bug. ***
nsbeta1+. To get the Align frames for non 96DPI setting on the branch only. I
don't think we should check this fix in on the trunk. We need to investigate a
better solution.
Keywords: nsbeta1nsbeta1+
is this related to (or dup of) bug 120918 or bug 87738 ?

Has anyone seen this problem in a post bug 120918 fix (after 2002-04-12) build?
I'm seeing it bigtime, build 20020424 linux-i686
It seems to arise more with mouse-wheel scrolling.  When I select the text it
goes away.  Here, I'll post some screen shots.
I see the exact same thing as Brian, i'm using 20020417 (rc1).

I've tried every possible DPI setting and it does not change the behaviour at all. 

I think this bug should be raised to a higher severity. Small text becomes
unreadable with this bug. I constantly have to select all text on the page to
make mozilla redraw it correctly so I can read it.
Target Milestone: Future → mozilla1.0
Whiteboard: [adt2]
Just a quick note to those looking at this page for a workaround to the bug:

A few have argued that the workaround of changing the DPI setting doesn't
actually work. You have to set the display resolution to any *anything other
than* System Setting and then *restart Mozilla* for it to take effect. Then, you
will probably no longer see the error. (But it's still a bug :P) If you still
see it after you've restarted (Windows folks, make sure Mozilla is completely
removed from memory before restarting) then by all means make a comment and tell
us a bit about your setup.
Ooh, wonderfull. When I restart mozilla at 96 DPI it works. I've had this
problem for a year or something, and now no more. When you change the setting
the complete window is redrawn, making you believe the change was applied, but
you have to restart.

If this bug is not fixed before 1.0 maybe the system setting (and custom
setting) should be disabled or at least the default value should be set to 96.
*** Bug 141431 has been marked as a duplicate of this bug. ***
*** Bug 142726 has been marked as a duplicate of this bug. ***
This should get higher severity since it makes webpages with small fonts
completely unreadable. I think it is also one of the more embarrassing bugs 
to have in 1.0 - people will say "look, mozilla cant even render fonts
correctly when scrolling". The very least to do for 1.0 would mention the
workaround from comment #53 in the release notes.
Keywords: relnote
*** Bug 129400 has been marked as a duplicate of this bug. ***
*** Bug 121920 has been marked as a duplicate of this bug. ***
The workaround (setting the DPI explicitly instead of letting it use system
setting) has been working nicely for me -- I used to see this bug constantly,
and now I never see it.

My system dpi is 101, I don't see the bug when I use 96.  So apparently we can't
deal with dpi settings that are a little off from the ones we understand, 72 and
96?  A fix for that seems fairly straightforward: when we're at "use system
setting", round to the nearest dpi setting we do understand.  Wouldn't that be
an easy fix that would cure the bug for everyone who's seeing it?
I reported bug 121920, which seems a bit different from most of the reports
here.  I see a horizontal error (the line of the error is horizontal), but most
people here seem to be seeing vertical errors.  However, comment #49 here shows
exactly the same error as I see, and the workaround (to change the DPI from
system setting -- 90 in my case -- to one of the explicitly listed ones) gets
rid of the symptom, so perhaps it's the same bug anyway.  I've never seen it on
slashdot, but enough sites have this problem that it's far too annoying to go
unfixed (or not mentioned in the release notes) for 1.0.
Setting the DPI explicitly has not solved my problems.  Win2000
1600x1200, 120dpi in system, neither 72 nor 96 dpi solves the problem.
Changing the DPI setting here to 96,72,100 or 120 (and restarting etc) makes no
difference on my setup either- Windows 2000, Large Fonts 125%/120dpi, 1600x1200
resolution, 16bit color, and Matrox G200.

BTW when scrolling various sites, and slashdot in particular, the single pixel
shift  sometimes also affects *images* that appear in the same table cell as the
text.
Just checked on my Linux (Debian) box.  The yahoo test case fails reliably on
either 72 or 96 dpi (as set in Mozilla).  1024x768 screen.

This patch fixes the off-by-one pixel rendering errors when running on WinXP in
120 DPI for www.yahoo.com test case. It should also fix Linux.
Attachment #79370 - Attachment is obsolete: true
Attachment #83094 - Attachment is obsolete: true
*** Bug 143535 has been marked as a duplicate of this bug. ***
Whiteboard: [adt2] → [adt2] Waiting for (r/sr) for checkin to the trunk
Comment on attachment 83108 [details] [diff] [review]
Align frames to pixel boundary. Updated patch

sr=attinasi - but, could you add a comment about the pref being read only at
initialization, and not updated dynamically. Also, that the default is TRUE and
that it is temporary (I assume it is temporary...)
Attachment #83108 - Flags: superreview+
Comment on attachment 83108 [details] [diff] [review]
Align frames to pixel boundary. Updated patch

r=karnaze
Attachment #83108 - Flags: review+
Attachment #83108 - Attachment is obsolete: true
*** Bug 119081 has been marked as a duplicate of this bug. ***
Has this patch been applied?
In 20020519 I still see the text off-by one on the horizontal glitch, but the at
least "lines in images" bug (thought to be related?) seems to be gone. 
This is on WinME, 1024x768, large (125dpi) fonts, mozilla prefs set to 96dpi.
I tried this with both "allow documents to use other fonts" on and off.
Comment on attachment 83430 [details] [diff] [review]
Patch with comments suggested by attinasi

This patch is incompatible with the trunk. When applied it hangs while opening
the browser window
Attachment #83430 - Attachment is obsolete: true
Whiteboard: [adt2] Waiting for (r/sr) for checkin to the trunk → [adt2]
*** Bug 94851 has been marked as a duplicate of this bug. ***
*** Bug 145668 has been marked as a duplicate of this bug. ***
Attachment 83430 [details] [diff] seems to work on Mozilla 1.0RC3.

This bug sometimes turns E's into F's, B's into E's and things like that,
potentially causing confusion; in my experience it's far and away the most
severe Mozilla bug at this point.

As a Mozilla user, I wonder: Is it possible for this problem to be worked around
(with attachment 83430 [details] [diff] [review] or a similar patch) for 1.0? Or is 1.0 going to ship with
this bug?
*** Bug 138521 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0.1
*** Bug 150455 has been marked as a duplicate of this bug. ***
Is the patch going to apply in the future? I applied Attachment 83430 [details] [diff] to Mozilla
1.0 and it seems to solve the problem I have been having for the last few months
with various visual defects in rendering. I especially noticed it on Slashdot
and Freshmeat. Now I don't see any problems with Slashdot or Freshmeat. This bug
is in the offical release of Mozilla 1.1a.
This bug is result of an optimization which removed the PushState PopState in
nsContainerFrame::Paint in favor of setting a negative translation to restore
the state. Since the setting the negative translation is additive to the
transformation matrix this results in the accumulation of small errors which
normally do not make any difference. But when running 120DPI many frames are
positioned precisely at twips locations which maps to a fractional 1/2 pixel
scanline. During scrolling the number of negative offsets used to restore the
state varies based on the container frame's children that intersect the damage
rect. The small error between successive scrolls can result in a whole pixel
shift if the textframe is positioned at 1/2 pixel boundary.

Going back to the original PushState, PopState calls fixes the problem but
re-introduces the performance problem that the negative translation optimization
eliminated.

The patch I attached fixes the problem by saving the translation components of
the transformation matrix before painting the children and restores the
translation components directly.
I tried attachment 87955 [details] [diff] [review] and found it does seem to fix the problem with two
halves of a table's contents being one pixel misaligned, but doesn't address the
problem of one pixel shift on selection of text. Attachment 83430 [details] [diff] seems to fix
both problems.
I have these problems at 104dpi.
Comment on attachment 87955 [details] [diff] [review]
Fix off by one error by changing how the rendering context state is saved/restored in nsContainerFrame's Paint method

sr=waterson
Attachment #87955 - Flags: superreview+
Comment on attachment 87955 [details] [diff] [review]
Fix off by one error by changing how the rendering context state is saved/restored in nsContainerFrame's Paint method

r=dbaron
Attachment #87955 - Flags: review+
Keywords: top100
Target Milestone: mozilla1.0 → mozilla1.0.1
checked fix (attachment 87955 [details] [diff] [review]) into the trunk
Nice fix. Since MathML consists of little frames that are piled up, little
cummulative errors can easily add up and become apparent. Should the fix be
extended to nsViewManager::Refresh() which is another user of negative translation?
Keywords: adt1.0.1, approval
"Should the fix be extended to nsViewManager::Refresh() which is another user of
negative translation?"

That case should be OK. It always follows the same sequence of adding to the
translation then subtracting translation. The problem I solved in this bug was
where the sequence of positive and negative translations varied depending on the
descendants of the container frame that intersected the damage rect. This caused
the errors to accumulate differently between subsequent paints for the same
container depending on the scroll position.

I am resolving this bug as fixed, since the original problem: horizontal
shifting of one line of pixels has been fixed by attachment 87955 [details] [diff] [review]. 

I created bug 152671 to cover the issue of one line of pixels being chopped off
during scrolling when running in 120DPI.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Keywords: testcase
With the 2002-06-19-08 trunk (Windows Me), I couldn't reproduce the problem as
described. Tested under 120 dpi System setting. Marking Verified.
Status: RESOLVED → VERIFIED
Attachment #87955 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls check
this in asap, then add the "fixed1.0.1" keyword.
Keywords: adt1.0.1adt1.0.1+
Whiteboard: [adt2] → [adt2 RTM] [ETA 06/21]
checked fix (attachment 87955 [details] [diff] [review]) into the 1.0 branch
Verified on the branch Windows Me build (2002-07-16-05).
Keywords: verified1.0.1
*** Bug 114896 has been marked as a duplicate of this bug. ***
*** Bug 160810 has been marked as a duplicate of this bug. ***
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
*** Bug 149862 has been marked as a duplicate of this bug. ***
Still present on Mozilla 1.2a. F.i. when viewing
http://www.mozilla.org/projects/phoenix/phoenix-release-notes.html and scrolling
up/down using the right scrollbar (not the keyboard).

RH7.3 and Gnome with nVidia GeForce4 MX420, latest drivers.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I also see it with 101DPI on 2002091318 (trunk) running on Red Hat 7.3.94
((null)) Public Beta under KDE.
I filed a new bug 171282 to cover the scrolling issue mentioned in comment 99
and comment 100. Please add any new off by one pixel scrolling issues to bug
171282. This bug has keywords and other notations which no longer apply, so I
opened a new bug.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Depends on: 171282
No longer depends on: 171282
Blocks: grouper
*** Bug 180442 has been marked as a duplicate of this bug. ***
verified with new trunk nightly.
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.