Closed Bug 622507 Opened 9 years ago Closed 9 years ago

[harfbuzz][D2D]Unexpected autorepeat buttons or space at bottom appear in Bookmarks menupopup of menubar

Categories

(Core :: XUL, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b12
Tracking Status
blocking2.0 --- -

People

(Reporter: alice0775, Assigned: jfkthame)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(4 files, 4 obsolete files)

Attached image screenshot
Build Identifier:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110102 Firefox/4.0b9pre ID:20110102030355

Unexpected autorepeat buttons appear in Bookmarks of menubar after  undo delete bookmark


Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Add a bookmark to Bookmarks menu.
3. Restart Browser
4. Alt > Bookmarks
5. Delete the added bookmark
6. Open Library(Ctrl+Shift+B) AND  Undo(Ctrl+Z)
7. Alt > Bookmarks

Actual Results:
 Unexpected autorepeat buttons appear in Bookmarks menupopup 

Expected Results:
 Unexpected autorepeat buttons should not appear.
 Popup should be resized automatically 

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/d48a0e23feec
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101201 Firefox/4.0b8pre ID:20101201030318
Fails:
http://hg.mozilla.org/mozilla-central/rev/d1228efe31dd
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101130 Firefox/4.0b8pre ID:20101201024409
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d48a0e23feec&tochange=d1228efe31dd
blocking2.0: --- → ?
I don't think this is a bookmarks bug.  Looks like menu drawing code.
Component: Bookmarks & History → Menus
QA Contact: bookmarks → menus
I wouldn't block on this from the UX side of things, but it's clearly an unintentional regression and I'd like to understand the cause and effect before making a decision. Specifically, might this be causing other strange issues with drawing menus?
In local build(windows):
build from bacd5fbd6456 (+90cbd8bf83e2+d1228efe31dd): fails
build from d48a0e23feec: works

(In reply to comment #2)
> I wouldn't block on this from the UX side of things, but it's clearly an
> unintentional regression and I'd like to understand the cause and effect before
> making a decision. Specifically, might this be causing other strange issues
> with drawing menus?

Yes, it is strange issue.
The problem does not happen, when I install ja langpack and start with -UIlocale ja.
Watch properties of menumpoup id=bookmarksMenuPopup,
height and width properties are created when I delete a bookmarks from Bookmarks Menu, 

I think height and width properties of menumpoup should not exist.
Frank: you're implied by comment 3. Please take a look. I'm not sure how your code change could cause this, though ... something to do with the specific new entity?
(In reply to comment #5)
> Frank: you're implied by comment 3. Please take a look. I'm not sure how your
> code change could cause this, though ... something to do with the specific new
> entity?

I don't know either. Shawn may have a better understanding of this.

Localized builds did have problems before they got updated with the new entities; for example, bug 616129

(In reply to comment #0)
> Regression window:
> Works:
> http://hg.mozilla.org/mozilla-central/rev/d48a0e23feec
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101201
> Firefox/4.0b8pre ID:20101201030318
> Fails:
> http://hg.mozilla.org/mozilla-central/rev/d1228efe31dd
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101130
> Firefox/4.0b8pre ID:20101201024409

Do you have some of these numbers in the wrong order?
I cannot reproduce it by doing the steps in comment 0 with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre. Alice, do you have any global extensions installed, which interfere with the menus?
(In reply to comment #7)
> I cannot reproduce it by doing the steps in comment 0 with Mozilla/5.0 (Windows
> NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre. Alice, do you have
> any global extensions installed, which interfere with the menus?

Clean profile,
That's why I have asked for globally installed add-ons. They will also appear in a clean profile.
about:support

  Application Basics

        Name
        Firefox

        Version
        4.0b9pre

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre

        Profile Directory

          Open Containing Folder

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

  Extensions

        Name

        Version

        Enabled

        ID

  Modified Preferences

      Name

      Value

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage_override.buildID
        20110103030359

        browser.startup.homepage_override.mstone
        rv:2.0b9pre

        extensions.lastAppVersion
        4.0b9pre

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        128823

        privacy.sanitize.migrateFx3Prefs
        true

  Graphics

        Adapter Description
        ATI Radeon HD 4300/4500 Series

        Vendor ID
        1002

        Device ID
        954f

        Adapter RAM
        512

        Adapter Drivers
        aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.801.0.0

        Driver Date

        Direct2D Enabled
        true

        DirectWrite Enabled
        true

        WebGL Renderer
        ATI Technologies Inc. -- ATI Radeon HD 4300/4500 Series        -- 3.3.10362 Compatibility Profile Context

      GPU Accelerated Windows
      1/1 Direct3D 10
OK, not blocking since I can't get an answer. If someone has an answer, they can renominate.
blocking2.0: ? → -
It happens if I enabled harfbuzz(i.e. gfx.font_rendering.harfbuzz.level !=0 , default 2 now).
And It does _not_ happen if disable H.A(i.e. disable D2D, D3D10 both) even if enabled harfbuzz.

Reproducible: Always

Steps to Reproduce:
1 .Start Minefield with clean profile (*no-addon* in about:config)
2.Disable auto-hide menubar (Alt > View > Toolbars> check Menu Bar)
3.Open http://www.mozilla.com/en-US/firefox/customize/
4.Drag a link "Check out the Traveler’s Pack Collection" to Bookmarks in the Menu Bar --- autorepeat buttons appear at top/bottom of popup, sometimes

5.Delete the bookmark by contect menu. --- space appears at bottom of popup

6. Drag the link  to Bookmarks in the MenuBar again
7. Drag the link  to Bookmarks in the MenuBar again2 --- autorepeat buttons appear at top/bottom of popup

[Actual Result]
  space appears at bottom of popup when delete bookmark
  autorepeat buttons appear at top/bottom of popup when add bookmark

[Expected Result]
  The popup should be automatically re-sized.
blocking2.0: - → ?
Component: Menus → Graphics
Product: Firefox → Core
QA Contact: menus → thebes
Summary: Unexpected autorepeat buttons appear in Bookmarks menupopup of menubar when undo delete bookmark → [harfbuzz][D2D]Unexpected autorepeat buttons or space at bottom appear in Bookmarks menupopup of menubar
Error in step 1 in comment #12:
s/about:config/about:addons/
I suspect that this is XUL menus not accounting for different font metrics, or something along those lines.
Component: Graphics → XUL
QA Contact: thebes → xptoolkit.widgets
This is really bizarre. Additional observation: if I launch the browser with harfbuzz disabled, the menu resizes as expected; if I then turn harfbuzz on, the problem starts happening. But OTOH if I launch with harfbuzz enabled, and then turn it off, the problem does *not* go away; a restart is required.

I don't think this is a question of different font metrics with the different text back-ends, partly because the harfbuzz setting should not have any effect at all on vertical metrics of the fonts; but mostly because the problem is not that the menu is slightly mis-sized for its content, but rather it never resizes at all. I can keep adding bookmark after bookmark, and the menu stays the same size, it just scrolls further. It's as though a notification that size needs to be recomputed is not getting sent. But why that should depend on whether we're using harfbuzz or dwrite shaping is a mystery.
With no extra bookmarks in the menu, and gfx.font_rendering.harfbuzz.level=2, the menu items "Bookmark This Page" and "Show All Bookmarks" appear truncated, with an ellipsis replacing the last two letters of each. With harfbuzz=0, they appear in full, as expected.

This occurs whenever we're using DirectWrite fonts with harfbuzz shaping, whether or not D2D is enabled.
AFAICT, the problem where the Bookmarks menu stops resizing, and instead becomes scrollable, starts when the "Bookmark This Page" and "Show All Bookmarks" items get truncated with an ellipsis. If I pre-populate the menu with some long bookmarks, so that it is wider than needed for these items, then it grows and shrinks fine as I add or remove items. But as soon as I remove the last "wide" bookmark, those two items get truncated in order to leave space for their accelerators (which suggests something is being fractionally mis-measured), and at that point the XUL content of the menu acquires fixed "height" and "width" attributes as mentioned in comment #4. From then on, the menu no longer resizes as bookmarks are added or removed.

The fact that we have a problem with the measurement of menu items shows up in a few other places as well: e.g., in the View menu, Sidebars submenu, I see "Bookmar..." in place of "Bookmarks", and in the Toolbars submenu, I see "Bookmarks Toolb..." (note that in this case, it's not competing for space with an accelerator, it's simply the longest item in the menu).

If we can resolve whatever measurement discrepancy is happening here, I think that will also resolve the problem with the Bookmarks menu "locking" its size.
I logged Bug 629014 for the truncated bookmarks.  Not sure if it should be closed as duplicate.
(In reply to comment #18)
> I logged Bug 629014 for the truncated bookmarks.  Not sure if it should be
> closed as duplicate.

Let's keep it separate for now; my current belief is that they're symptoms of the same underlying issue, but things might turn out to be more complex.
Might want to check the widths being computed in nsTextBoxFrame. That's what does text measurement for text in menus. Maybe once we start ellipsizing, GetPrefSize() starts returning the wrong thing? I dunno.
It appears that this (along with the related bug 627824) has been fixed by the backout of bug 562138. Alice, can you confirm that?
(In reply to comment #21)
> It appears that this (along with the related bug 627824) has been fixed by the
> backout of bug 562138. Alice, can you confirm that?

Argh.... not so simple after all; it's happened again. It looks like the visibility/painting changes in that backout may have had some effect on the exact situations that trigger this, but the problem is still here.
This is not actually triggered by harfbuzz (though it can affect the precise situations where it occurs) or by D2D specifically; it can be reproduced with GDI+DWrite, too. It occurs because DWrite returns fractional-pixel text widths, and we lose the fractional amounts during conversion to and from device pixels while we're sizing the widgets.

A simple fix is to ensure that the width of the menu item text is always rounded *up* to an integer number of device pixels.
(In reply to comment #23)
> It occurs because DWrite returns fractional-pixel text widths,
> and we lose the fractional amounts during conversion to and from device pixels
> while we're sizing the widgets.

Can you describe the problem in a bit more detail? It sounds we might need to fix something else.
(In reply to comment #25)
> (In reply to comment #23)
> > It occurs because DWrite returns fractional-pixel text widths,
> > and we lose the fractional amounts during conversion to and from device pixels
> > while we're sizing the widgets.
> 
> Can you describe the problem in a bit more detail? It sounds we might need to
> fix something else.

Wellllll... I'm not sure I totally understand all that's going on between measuring the menuItem's string and setting the widget size, but a few pointers:

- The (unwanted) height and width attributes mentioned in comment #4 are being set in nsXULPopupManager::PopupResized() at http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsXULPopupManager.cpp#363. When this happens on removing a bookmark (with no long bookmarks in the menu, so it is at its "normal" width), I observed a width passed in of 237 (device) pixels, but the menu's currentSize (in appunits) was equivalent to 237.55 [device] pixels. That looks like a truncated (rather than rounded) value, and means that code incorrectly believes the popup is being explicitly resized and applies the attributes.

- When the menu is initially created, I verified that the menuPopupFrame has appunit dimensions that appear to correctly include a fractional-device-pixel element from the string widths. However, we can of course not preserve the fractional part when we create the actual widget; it seems to be lost. This doesn't affect the initial display of the menu, but when the user adds or deletes a bookmark and the widget gets resized, the (device-pixel) resize gets propagated down to the menuPopupFrame and its dimensions are forced to match. This results in truncated menu items when nsTextBoxFrame::CalculateTitleForWidth tries to fit a string that requires (say) 200.55 pixels into a frame that has been forced to 200 pixels wide, and it also causes the height and width attributes to be attached to the menu (above).

- I'm a bit suspicious of the code at http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsMenuPopupFrame.cpp#486 that takes the nsMenuPopupFrame's rect and (if there's an associated widget) converts it from appUnits to devPixels and then back; this will lose any fractional-pixel size that may have been part of the view's rect, and might be one place we're having trouble due to fractional-width strings, but I'm not entirely sure how all this interacts.

As far as I can tell, fixing this without enforcing integer-pixel string widths for the menu items would require two things: (1) figuring out why the widget is (sometimes?) getting a truncated rather than rounded dimension, which causes us to detect "false resizes" and freeze the dimensions when we don't really want to; and (2) allowing some "fuzz" in nsTextBoxFrame::CalculateTitleForWidth() so that it doesn't truncate and ellipsify a string that only exceeds the (rounded) available width by a fraction of a pixel.

Of these, (2) ought to be trivial - though it might still be less than ideal, in that we might get fractional clipping of the trailing glyph edge (which we can avoid if we always round the dimensions upwards, rather than to the nearest pixel); but I'm not currently sure where to fix (1).
(In reply to comment #26)
> - The (unwanted) height and width attributes mentioned in comment #4 are being
> set in nsXULPopupManager::PopupResized() at
> http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsXULPopupManager.cpp#363.
> When this happens on removing a bookmark (with no long bookmarks in the menu,
> so it is at its "normal" width), I observed a width passed in of 237 (device)
> pixels, but the menu's currentSize (in appunits) was equivalent to 237.55
> [device] pixels. That looks like a truncated (rather than rounded) value, and
> means that code incorrectly believes the popup is being explicitly resized and
> applies the attributes.

Yes, it sounds like someone truncated instead of rounding. We should track that down and fix it, and then see what else needs to be done. As a general rule, we convert from appunits to dev pixels by snapping edges to the nearest pixel boundary, so 237.55 should have snapped to 238. Can you have a go at tracking that down?

> (2) allowing some "fuzz" in nsTextBoxFrame::CalculateTitleForWidth() so
> that it doesn't truncate and ellipsify a string that only exceeds the(rounded)
> available width by a fraction of a pixel.
> 
> Of these, (2) ought to be trivial - though it might still be less than ideal,
> in that we might get fractional clipping of the trailing glyph edge (which we
> can avoid if we always round the dimensions upwards, rather than to the nearest
> pixel); but I'm not currently sure where to fix (1).

If we fix #1 then we may not need to fix #2 to fix this bug. There might be other cases where we need to do #2 though.
(In reply to comment #27)
> Yes, it sounds like someone truncated instead of rounding. We should track that
> down and fix it, and then see what else needs to be done. As a general rule, we
> convert from appunits to dev pixels by snapping edges to the nearest pixel
> boundary, so 237.55 should have snapped to 238.

That's what I thought, but didn't locate the culprit yet; I'll dig some more tomorrow.

> If we fix #1 then we may not need to fix #2 to fix this bug. There might be
> other cases where we need to do #2 though.

This aspect is related to bug 627824, which claims to be FIXED but I think is actually still rather fragile at best. The simplistic initial patch here would avoid the issue; I think if we just do #1 here, there may still be a residue of 627824 that will be triggered in certain cases.

Anyhow, I'll see if I can figure out #1....
OK, this problem originates from nsIView::CalcWidgetBounds, which converts the "ideal" bounds of the view to actual screen pixels using nsRect::ToNearestPixels (see http://mxr.mozilla.org/mozilla-central/source/view/src/nsView.cpp#415). Checking the definition at http://mxr.mozilla.org/mozilla-central/source/gfx/src/nsRect.h#398, we see that this function rounds each side of the rect separately. As a result, the width (and height) of the device-pixel rect may not be the same as the value that would result from converting and rounding the width and height of the view's rect.

This leads to the discrepancy described in comment #26 where nsXULPopupManager::PopupResized() compares the popup view's size (in appunits) to the widget's size (as set by nsIView::CalcWidgetBounds), concludes there is a mismatch and therefore an explicit resize, and sets width & height properties on it.

A simple fix may be to modify nsRect::ToNearestPixels so that it preserves the (rounded) width and height rather than rounding the edges independently; this fixes the menu-sizing bug in my early testing, at least, but I don't know how many other side-effects it may have; I've pushed a tryserver job to see how unit tests fare with this.

Another option might be to add a new method nsRect::ToPixelsPreservingDimensions and only use it from nsIView::CalcWidgetBounds; this would avoid affecting other callers, but on the other hand the change might be a generally-desireable one, and I'm not really keen on increasing the number of subtly-different ways of converting coordinates if we don't actually need all the distinct varieties.
(In reply to comment #29)
> A simple fix may be to modify nsRect::ToNearestPixels so that it preserves the
> (rounded) width and height rather than rounding the edges independently; this
> fixes the menu-sizing bug in my early testing, at least, but I don't know how
> many other side-effects it may have; I've pushed a tryserver job to see how
> unit tests fare with this.

No, it is very important that nsRect::ToNearestPixels snap the left and right edges, not the width. The basic invariant we're preserving is that snapping a rectangle gives you a rectangle whose edges are on pixel boundaries and which contains the same set of pixel centers as the original rectangle. That is generally what we want in rendering.

> Another option might be to add a new method
> nsRect::ToPixelsPreservingDimensions and only use it from
> nsIView::CalcWidgetBounds; this would avoid affecting other callers, but on the
> other hand the change might be a generally-desireable one, and I'm not really
> keen on increasing the number of subtly-different ways of converting
> coordinates if we don't actually need all the distinct varieties.

Yes, I think widget sizing is one case where it makes sense to round the top-left and then round the dimensions.
In fact, that didn't used to make sense when we had child widgets and we depended on child widget rect snapping matching the snapping of, say, rectangles drawn into the parent widget.

This really only matters for popup widgets since only popups can have a fractional top/left, which is necessary for this bug to become an issue. So I think we should simply round the top/left coordinate of popup widgets (i.e. menus) somewhere.
(In reply to comment #30)
> No, it is very important that nsRect::ToNearestPixels snap the left and right
> edges, not the width. The basic invariant we're preserving is that snapping a
> rectangle gives you a rectangle whose edges are on pixel boundaries and which
> contains the same set of pixel centers as the original rectangle. That is
> generally what we want in rendering.

Yes; I confirmed that altering this for all users of ToNearestPixels is a Bad Thing, and leads to occasional "seams" in rendering - there are a couple of reftests that fail as a result.
One way to fix this issue is to modify nsIView::CalcWidgetBounds so that the widget bounds correctly reflect the rounded width and height of the view, rather than rounding the edges separately which may lead to a sizing discrepancy.

I believe this would be a reasonable change to make - it seems logical to expect that the widget's size should equal that of the view. Given that only popups can currently have fractional-pixel positions, no other widgets will actually be affected by the change, but if we do ever introduce another kind of widget (or a different situation, perhaps involving UI scaling?) where fractional positions are possible, it's likely that similar issues would arise.
Attachment #509110 - Attachment is obsolete: true
Attachment #513091 - Flags: review?(roc)
Attachment #509110 - Flags: review?(roc)
An alternative fix is to snap the position of the view to device pixels in nsMenuPopupFrame::LayoutPopup. This is arguably the less-intrusive fix, as it is clearly specific to popups and cannot affect any other kind of widget. However, it seems to me that option 1 is probably a better strategy - it feels more like the right place to be applying the fix.

Although I wouldn't say this hard-blocks, I do think we should take one of these fixes for FF4.0, as the risk involved is minimal - all we're doing is adjusting the precise pixel-rounding used in sizing the popup's frame - and the user experience when the Bookmarks menu size gets "stuck" is pretty bad.
Attachment #513095 - Flags: review?(roc)
Alice, there are tryserver builds with each of these patches available, if you'd like to confirm whether they fix the problem for you:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jkew@mozilla.com-283545b0f486 (option 1)

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jkew@mozilla.com-2cecc0ac8b9c (option 2)
both fixed the problem
(In reply to comment #32)
> Yes; I confirmed that altering this for all users of ToNearestPixels is a Bad
> Thing, and leads to occasional "seams" in rendering - there are a couple of
> reftests that fail as a result.

Excellent! :-)
Option 2 looks better to me, but I think the rounding code should be in nsMenuPopupFrame::SetPopupPosition.

I prefer option 2 because I think the code that uses widgets should be responsible for choosing the rounding behavior.
OK; something like this?
Attachment #513091 - Attachment is obsolete: true
Attachment #513095 - Attachment is obsolete: true
Attachment #513285 - Flags: review?(roc)
Attachment #513285 - Flags: approval2.0?
Attachment #513091 - Flags: review?(roc)
Attachment #513095 - Flags: review?(roc)
Comment on attachment 513285 [details] [diff] [review]
patch, snap popup menu position to device pixels

Yes, excellent!
Attachment #513285 - Flags: review?(roc)
Attachment #513285 - Flags: review+
Attachment #513285 - Flags: approval2.0?
Attachment #513285 - Flags: approval2.0+
We should write a test for this. It's not trivial, but it also shouldn't be particularly hard.
Landed the patch, as the tree was quiet-ish; will followup with a test.
http://hg.mozilla.org/mozilla-central/rev/26c7b580d5a2
Backed out because of mochitest orange on toolkit/content/tests/widgets/test_popupincontent.xul :(
http://hg.mozilla.org/mozilla-central/rev/e95166704b63

That didn't happen on tryserver with the slightly earlier iteration of the patch; need to figure out what changed.
It also gave an unexpected assertion in content/xbl/crashtests/336744-1.html:

###!!! ASSERTION: Popup is offscreen: 'screenPoint.x >= screenRect.x && screenPoint.y >= screenRect.y && screenPoint.x + mRect.width <= screenRect.XMost() && screenPoint.y + mRect.height <= screenRect.YMost()', file /builds/slave/cen-osx-dbg/build/layout/xul/base/src/nsMenuPopupFrame.cpp, line 1283
So it turns out that what we actually need to snap to pixels here is not "screenPoint", but the computed position of the view, which is what actually becomes the basis for creating the widget. In the Bookmarks menu case, the fractional-pixel offset is the same for both, so it doesn't make any difference which of them we snap to pixels, but in some of our tests the offset between the two is itself fractional, so it's important that we apply the pixel-snapping to the final view position.
Attachment #513473 - Flags: review?(roc)
Attachment #513473 - Flags: approval2.0?
Attachment #513285 - Attachment is obsolete: true
Comment on attachment 513473 [details] [diff] [review]
revised patch, snap the coordinates of the view in nsMenuPopupFrame::SetPosition

Cancelling r? request until I figure out why this seemed to cause mochitest failures on try, on Win7 only but not XP or other platforms.
Attachment #513473 - Flags: review?(roc)
Attachment #513473 - Flags: approval2.0?
Comment on attachment 513473 [details] [diff] [review]
revised patch, snap the coordinates of the view in nsMenuPopupFrame::SetPosition

I think this patch is fine after all. The mochitest failures on Win7 (depending on specific machine configuration - maybe screen size, font settings, etc? - they didn't occur on my Lenovo) occur on positioning tests that are sensitive how the coordinate of the right or bottom edge of the menu rounds to whole pixels. But because we're snapping the top/left to whole pixels, this may shift the bottom/right by up to half a pixel, and thus alter how it rounds.

To fix this, we can simply allow a slight (fractional-pixel) discrepancy when the test harness checks these coordinates against the "expected" values. I'll attach an additional patch that implements this; with that change, the tests all pass on tryserver.
Attachment #513473 - Flags: review?(roc)
http://hg.mozilla.org/mozilla-central/rev/2ce0aeb5929c (mochitest fix)
http://hg.mozilla.org/mozilla-central/rev/338a48d9f603 (patch)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b12
Depends on: 635813
Depends on: 961431
You need to log in before you can comment on or make changes to this bug.