Username is overwritten with a blank one when updating the password for a Twitter account

VERIFIED FIXED in Firefox 46

Status

()

defect
P1
normal
VERIFIED FIXED
4 years ago
6 months ago

People

(Reporter: VladB, Assigned: timdream, Mentored)

Tracking

({regression})

Trunk
mozilla48
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox45 affected, firefox46blocking verified, firefox47 verified, firefox48 verified, firefox-esr45 affected)

Details

Attachments

(7 attachments, 14 obsolete attachments)

301.44 KB, image/jpeg
Details
1.64 KB, patch
timdream
: review+
Details | Diff | Splinter Review
25.55 KB, patch
timdream
: review+
Details | Diff | Splinter Review
9.49 KB, patch
timdream
: review+
Details | Diff | Splinter Review
2.53 KB, patch
timdream
: review+
Details | Diff | Splinter Review
1.64 KB, patch
timdream
: review+
Details | Diff | Splinter Review
14.30 KB, patch
timdream
: review+
Details | Diff | Splinter Review
Reporter

Description

4 years ago
Posted image screenshot
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160127030236

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160123151951

Prerequisites:
Have at least 2 logins saved for Twitter in browser.

Steps to Reproduce:
1. Login to Twitter with one of the saved accounts.
2. Go to Twitter->Settings->Password screen.
3. Enter the current password and the new one.
4. Click on "Save changes" button.
5. Select from `Confirm Password Change` window the username for which the password has been changed.
6. Click on "OK" button.
7. Open a new tab and go to about:preferences#security, click on "Saved Logins..." button.
8. Observe the username for which the password has been changed.

Expected results:
The username is displayed and only the password is updated.

Actual results:
The username is blank.

This issue is reproducible also on Windows 10, Mac OS X 10.11.
Good catch. The screenshot with multiple dialogs was very helpful.

This is a regression from the following hunk of bug 1016051 which changed _updateLogin. At least for this case from bug promptToChangePasswordWithUsernames but possibly others that were changed in that bug, we shouldn't `propBag.setProperty("username",…)` if the new username is empty.

http://hg.mozilla.org/mozilla-central/diff/105633f695fa/toolkit/components/passwordmgr/nsLoginManagerPrompter.js#l1.307
Blocks: 1016051
Mentor: MattN+bmo
Has Regression Range: --- → no
Keywords: regression
Priority: -- → P1
Hardware: x86_64 → All
Posted file WIP (obsolete) —
I think the easier way to fix this would be to wrap the line you mentioned in an `if`. The alternative would be to identify all the call sites and make sure aNewLogin comes with proper .username and .usernameField.

I spent some time to determine where the tests should be put in, and I suspect [1] is the right place. However, the comment there suggests we don't have tests in places _at all_?

[1] https://dxr.mozilla.org/mozilla-central/rev/f14898695ee0dd14615914f3e1401f17df57fdd7/toolkit/components/passwordmgr/test/test_notifications.html#334

It would probably require some effort to create a new set of tests. Should we do that here?
Assignee: nobody → timdream
Status: NEW → ASSIGNED
Attachment #8732756 - Flags: feedback?(MattN+bmo)
Posted patch WIP (obsolete) — Splinter Review
Attachment #8732756 - Attachment is obsolete: true
Attachment #8732756 - Flags: feedback?(MattN+bmo)
Attachment #8732759 - Flags: feedback?(MattN+bmo)
... and the added test would overlap with patch in bug 1255265.
Attachment #8732759 - Attachment is patch: true
Comment on attachment 8732759 [details] [diff] [review]
WIP

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

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #2)
> I think the easier way to fix this would be to wrap the line you mentioned
> in an `if`. The alternative would be to identify all the call sites and make
> sure aNewLogin comes with proper .username and .usernameField.

The former is what I had in mind too.

> I spent some time to determine where the tests should be put in, and I
> suspect [1] is the right place.

Yeah, it seems like the best place though you're right that I'm porting that test in bug 1255265 so could you make your test on top of that patch? Note that that test file isn't always checking the saved logins (only submitted) but we would want that for this case.

> However, the comment there suggests we don't
> have tests in places _at all_?

I think that comment is talking about a password-only form where we can't tell if we should save a new password or change an existing. In cases like https://twitter.com/settings/password where we have the old password and double-entry of the new one, it's more clear that we can *suggest* an update.
Attachment #8732759 - Flags: feedback?(MattN+bmo) → feedback+
Thanks for the feedback. I should definitely be able to do what you asked here. It would be slow however, since I will be busy on management part of my job this week.
Unfortunately, I can't submit a branch with multiple commits (and one revert commit) to MozReview, so hello `git format-patch`.

Part Zero is just the one line patch that was previously feedback+'d.
Attachment #8734754 - Flags: review?(MattN+bmo)
Attachment #8732759 - Attachment is obsolete: true
Part 2 add assertions of the saved login on all tests.
Attachment #8734755 - Flags: review?(MattN+bmo)
Part II (ouch, the second patch was marked as Part I) adds a test like comment 0 said (the change password form on Twitter).

I split the patches for easier reviews -- I can squash a patch-to-commit if asked.
Attachment #8734757 - Flags: review?(MattN+bmo)
Attachment #8734754 - Flags: review?(MattN+bmo) → review+
Comment on attachment 8734754 [details] [diff] [review]
0001-Bug-1243729-Part-Zero-Don-t-empty-username-if-passwo.patch

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

Actually, thinking about this more, doesn't this mean the user will see a change password prompt with an empty username field still? I think what we save should match what we show as the user can edit it. The doorhanger should show the username we already have in storage.
Attachment #8734754 - Flags: review+
(In reply to Matthew N. [:MattN] (behind on bugmail) from comment #11)
> Actually, thinking about this more, doesn't this mean the user will see a
> change password prompt with an empty username field still?

I guess not in the attachment 8713167 [details] case where there are multiple existing logins with the same old password but I'm thinking of the case where there is only one and we show a doorhanger instead. Does this bug happen in that case too?
We probably should allow the user to blank the username from the doorhanger if we think we have a username but the site doesn't use usernames e.g. mailman.
It looks like we do properly fill in the old username with the doorhanger already. Comment 13 is still a problem but I don't think this bug makes it worse so that can be addressed in another bug.
Comment on attachment 8734757 [details] [diff] [review]
0003-Bug-1243729-Part-II-Test-for-change-password-form-r-.patch

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

Given what I just found, I wonder if this test would have passed without the fix since this is testing the doorhanger, not the dialog from the screenshot.

I'll have to come back to this bug later as I'm taking PTO for the rest of the day.
(In reply to Matthew N. [:MattN] (behind on bugmail) from comment #15)
> Given what I just found, I wonder if this test would have passed without the
> fix since this is testing the doorhanger, not the dialog from the screenshot.

Do we have tests in place already for the dialog in screenshot?

(To be honest, I don't save passwords and I have never saw that dialog ...)
... and you are right, test passes even if I reverted the part zero.
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #16)
> Do we have tests in place already for the dialog in screenshot?

I don't think we do, since I have not found any test script controlling the promptService selector dialog. If I found one I will create a separate browser chrome test for the case here -- since the test no longer testing the door hanger.
These is one interesting test file that simply mocks the prompt service. 
https://dxr.mozilla.org/mozilla-central/source/browser/base/content/test/general/browser_bug356571.js

The prompt service test itself has non-trivial script in prompt_common.js to wait for the dialog elements to show, and handleDialog interact with the dialog XUL elements directly.

I wonder if mocking the prompt service is the better approach here.
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #19)
> These is one interesting test file that simply mocks the prompt service. 
> https://dxr.mozilla.org/mozilla-central/source/browser/base/content/test/
> general/browser_bug356571.js

This test was disabled 6 years ago w/o a bug number (https://hg.mozilla.org/mozilla-central/rev/7f7ba2b353ac), so I don't think we could follow this.

What's the right approach to test out a feature that calls into prompt service?
The two tests here will correctly control the prompt service selection dialog, although in the non-e10s mode only. `getSelectDialogDoc` is mostly copied from prompt_common.js -- I can update it to e10s if I understand nsIWindowMediator and e10s well enough.

This test will fail as expected if I revert Part Zero. I do agree however Part Zero needs an alternative approach so users are allowed to empty the username (as you mentioned).
Attachment #8735396 - Flags: review?(MattN+bmo)
This is the new patch localized to `promptToChangePasswordWithUsernames()`. There is a comment on top:

   * Note: The caller doesn't know the username for aNewLogin, so this
   *       function fills in .username and .usernameField with the values
   *       from the login selected by the user.

So the patch simply honor that by creating a new LoginInfo object filling the .username and .usernameField properties.
Attachment #8734754 - Attachment is obsolete: true
Attachment #8735398 - Flags: review?(MattN+bmo)
Please tell me if we still want to keep the added assertions in Part I, and the added test in Part II.

Part II is probably a redundant test. Not sure about Part I. Noted that both patch does not guard against the side effect of the original Part Zero (disallowing user from emptying the username).
Attachment #8735398 - Flags: review?(MattN+bmo) → review+
Attachment #8734757 - Flags: review?(MattN+bmo) → review+
Comment on attachment 8734755 [details] [diff] [review]
0002-Bug-1243729-Part-I-Add-assertions-on-saved-password-.patch

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

Tim, can you please provide more context in your patches (or use MozReview)? 8 lines of context is recommended on MDN and it's hard to review this patch with only 3.

Thanks for doing this. I noticed we were assuming too much in those tests before.

::: toolkit/components/passwordmgr/test/browser/browser_capture_doorhanger.js
@@ +78,5 @@
>      clickDoorhangerButton(notif, REMEMBER_BUTTON);
>    });
>  
> +  {
> +    let logins = Services.logins.getAllLogins();

I've never seen browser code create blocks like this so I'd slightly prefer not doing this and just don't re-declare the variables below (re-use them instead).
Attachment #8734755 - Flags: review?(MattN+bmo) → review+
Comment on attachment 8735396 [details] [diff] [review]
0004-Bug-1243729-Part-III-Test-on-username-selection-dial.patch

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

r=me without the "skip-if = e10s"

Thanks and sorry for the delay.

::: toolkit/components/passwordmgr/test/browser/browser_username_select_prompt.js
@@ +1,2 @@
> +/*
> + * Test username selection on password update

Nit: Could you mention the dialog here. Also s/prompt/dialog/ in the filename for clarity since some people consider doorhangers prompts and I want to contrast that.

@@ +1,5 @@
> +/*
> + * Test username selection on password update
> + */
> +
> +Cu.import("resource://testing-common/ContentTaskUtils.jsm", this);

I think this is imported by default in browser-chrome tests

@@ +4,5 @@
> +
> +Cu.import("resource://testing-common/ContentTaskUtils.jsm", this);
> +
> +// TODO: e10s-ify this
> +function getSelectDialogDoc() {

All new tests need to support e10s but I don't see any problem with it already working with e10s. This browser_username_select_prompt.js file runs in the parent process and that's where the dialog is also created.

Could you add a comment that you copied this from prompt_common.js? In the futre we should share this code. It wouldn't be hard to share a test chrome script between mochitest plain and browser-chrome.

@@ +44,5 @@
> +                             "notifyu1", "notifyp1", "user", "pass");
> +let login1B = new nsLoginInfo("http://mochi.test:8888", "http://mochi.test:8888", null,
> +                              "notifyu1B", "notifyp1B", "user", "pass");
> +
> +requestLongerTimeout(2);

Did you actually need this? I suspect not since the test is short.
Attachment #8735396 - Flags: review?(MattN+bmo) → review+
Quick update:

(In reply to Matthew N. [:MattN] from comment #25)
> @@ +1,5 @@
> > +/*
> > + * Test username selection on password update
> > + */
> > +
> > +Cu.import("resource://testing-common/ContentTaskUtils.jsm", this);
> 
> I think this is imported by default in browser-chrome tests
> 

I can see ContentTaskUtils is not defined in the test script scope.


> @@ +4,5 @@
> > +
> > +Cu.import("resource://testing-common/ContentTaskUtils.jsm", this);
> > +
> > +// TODO: e10s-ify this
> > +function getSelectDialogDoc() {
> 
> All new tests need to support e10s but I don't see any problem with it
> already working with e10s. This browser_username_select_prompt.js file runs
> in the parent process and that's where the dialog is also created.
> 

Test in e10s failed from the following error (not the original cause I guessed). I am trying to look into this now.

JavaScript error: file:///Users/timdream/Repositories/gecko/obj-x86_64-apple-darwin15.4.0/dist/Nightly.app/Contents/Resources/components/Weave.js, line 13: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXPCComponents_Utils.import]
5 INFO Console message: [JavaScript Error: "TelemetryStopwatch: key "FX_PAGE_LOAD_MS" was already initialized" {file: "resource://gre/modules/TelemetryStopwatch.jsm" line: 282}]
this.TelemetryStopwatchImpl.start@resource://gre/modules/TelemetryStopwatch.jsm:282:7
this.TelemetryStopwatch.start@resource://gre/modules/TelemetryStopwatch.jsm:136:12
TabsProgressListener.onStateChange@chrome://browser/content/browser.js:4627:11
callListeners@chrome://browser/content/tabbrowser.xml:501:24
_callProgressListeners@chrome://browser/content/tabbrowser.xml:522:13
mTabProgressListener/<._callProgressListeners@chrome://browser/content/tabbrowser.xml:571:22
mTabProgressListener/<.onStateChange@chrome://browser/content/tabbrowser.xml:731:15
RemoteWebProgressManager.prototype._callProgressListeners@resource://gre/modules/RemoteWebProgress.jsm:176:11
RemoteWebProgressManager.prototype.receiveMessage@resource://gre/modules/RemoteWebProgress.jsm:235:7
openModalWindow@file:///Users/timdream/Repositories/gecko/obj-x86_64-apple-darwin15.4.0/dist/Nightly.app/Contents/Resources/components/nsPrompter.js:360:5
ModalPrompter.prototype.openPrompt@file:///Users/timdream/Repositories/gecko/obj-x86_64-apple-darwin15.4.0/dist/Nightly.app/Contents/Resources/components/nsPrompter.js:550:9
ModalPrompter.prototype.select@file:///Users/timdream/Repositories/gecko/obj-x86_64-apple-darwin15.4.0/dist/Nightly.app/Contents/Resources/components/nsPrompter.js:796:9
Prompter.prototype.select@file:///Users/timdream/Repositories/gecko/obj-x86_64-apple-darwin15.4.0/dist/Nightly.app/Contents/Resources/components/nsPrompter.js:99:16
LoginManagerPrompter.prototype.promptToChangePasswordWithUsernames@file:///Users/timdream/Repositories/gecko/obj-x86_64-apple-darwin15.4.0/dist/Nightly.app/Contents/Resources/components/nsLoginManagerPrompter.js:1346:14
LoginManagerParent.onFormSubmit@resource://gre/modules/LoginManagerParent.jsm:352:9
LoginManagerParent.receiveMessage@resource://gre/modules/LoginManagerParent.jsm:82:9
The error seems unrelated (it also show up in the doorhanger tests) and the tests seems to be blocked at waiting for the tab content to load.
With a few dump(), it looks like the select dialog will prevent tabbrowser from dispatching the TabSwitchDone event.

Let's see the timing issue can be produced on Try.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b81c151f8351
I am not entirely sure this is a workaround or a fix, but the JS Error and the test timeout both vanish if I employ this hashchange hack.

If you r+ this I will squash this into the test file commit, as shown in the try commits below.

New try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=05c0b112f14d

(I don't know why, but MozReview does not allow me to push multiple commits, while ./mach try still allow me to push them to try :-/.)
Attachment #8738474 - Flags: review?(MattN+bmo)
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #26)
> (In reply to Matthew N. [:MattN] from comment #25)
> > @@ +1,5 @@
> > > +/*
> > > + * Test username selection on password update
> > > + */
> > > +
> > > +Cu.import("resource://testing-common/ContentTaskUtils.jsm", this);
> > 
> > I think this is imported by default in browser-chrome tests
> > 
> 
> I can see ContentTaskUtils is not defined in the test script scope.
> 

This has moved to head.js, since LoginTestUtils.jsm is loaded from there too.
Attachment #8738474 - Attachment description: Additional to username selection dialog → Addition changes to username selection dialog tests
Attachment #8735398 - Attachment is obsolete: true
Attachment #8738474 - Attachment is obsolete: true
Attachment #8738474 - Flags: review?(MattN+bmo)
Attachment #8740174 - Flags: review+
Per discussion w/ :MattN in person, he agrees we should not land the workaround but with skip-if=e10s, and file a bug to track it. I've filed bug 1263760 to document that. :MattN, would you confirm this comment just for the record? Thanks!
Flags: needinfo?(MattN+bmo)
Posted patch part0.patchSplinter Review
HG patches for check-in.
Attachment #8740174 - Attachment is obsolete: true
Attachment #8740261 - Flags: review+
Posted patch part1.patchSplinter Review
Attachment #8740176 - Attachment is obsolete: true
Posted patch part2.patchSplinter Review
I did not move code correctly -- this is the new patch in HG format.

New try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=612c720d32ad
Attachment #8740177 - Attachment is obsolete: true
Attachment #8740263 - Flags: review+
Posted patch part3.patchSplinter Review
Attachment #8740178 - Attachment is obsolete: true
Attachment #8740264 - Flags: review+
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #36)
> Per discussion w/ :MattN in person, he agrees we should not land the
> workaround but with skip-if=e10s, and file a bug to track it. I've filed bug
> 1263760 to document that. :MattN, would you confirm this comment just for
> the record? Thanks!

Yes, I think that's fine for now as it's not going to be an issue related to e10s quality since this feature had no tests before (even in non-e10s).
Flags: needinfo?(MattN+bmo)
Comment on attachment 8740261 [details] [diff] [review]
part0.patch

Approval Request Comment
[Feature/regressing bug #]: Bug 1016051
[User impact if declined]: Username gets blanked when changing a password on pages where the username isn't present.
[Describe test coverage new/current, TreeHerder]: New tests for the dialog
[Risks and why]: Low risk, small change to preserve the existing username in this case.
[String/UUID change made/needed]: None
Attachment #8740261 - Flags: approval-mozilla-aurora?
Comment on attachment 8740261 [details] [diff] [review]
part0.patch

Regression in an oft-used scenario, Aurora47+
Attachment #8740261 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Hi Matt, Liz: Should we consider uplifting this one to Beta 46 (even though we are in RC week now seems severe enough to me)?
Flags: needinfo?(lhenry)
Flags: needinfo?(MattN+bmo)
We shipped 45 with this regression and with bug 1243722. But I agree with Ritu we should take it now. It helps that you all added some tests. Thanks!
Flags: needinfo?(lhenry)
Tim is going to check that the patches apply to beta and then we will uplift to m-b and m-r for the RC2 build.
Test commits don't apply on mozilla-beta either.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0eb5fcef4f40
Attachment #8743080 - Flags: review+
Attachment #8743080 - Flags: approval-mozilla-beta?
Posted patch Patch for m-b (part2) (obsolete) — Splinter Review
Part 2 applied on m-b.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a228fa19a558

Please wait for try result before land. Did not test locally.
Attachment #8743083 - Flags: review+
Attachment #8743083 - Flags: approval-mozilla-beta?
Attachment #8743083 - Attachment is patch: true
Posted patch Patch for m-b (part2) (obsolete) — Splinter Review
head.js was not included in browser.ini :'(

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f156540016cf
Attachment #8743083 - Attachment is obsolete: true
Attachment #8743083 - Flags: approval-mozilla-beta?
Attachment #8743108 - Flags: review+
Attachment #8743108 - Flags: approval-mozilla-beta?
And I would need to partially uplift bug 1255265 too.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0ef2895426d7
Attachment #8743108 - Attachment is obsolete: true
Attachment #8743108 - Flags: approval-mozilla-beta?
Attachment #8743126 - Flags: review+
Attachment #8743126 - Flags: approval-mozilla-beta?
Uplifting the m-b part 0 and part 2 seems straightforward enough.

Tomcat, can you uplift those two patches to m-a through m-r when the try push in comment 52 is green please. Thanks!

Liz/Vlad, we should probably get some sanity-check manual password manager runs on m-r for this bug and bug 1243722. It probably doesn't need to be cross-platform:
* Verify the two bugs
* Sanity check saving a new login, updating an existing login, autofill and autocomplete on some sites.

Thanks
Flags: qe-verify+
Flags: needinfo?(vlad.bacia)
Flags: needinfo?(lhenry)
Flags: needinfo?(cbook)
Flags: needinfo?(MattN+bmo)
Andrei can your team check password manager as described in comment 53? Thanks.
Flags: needinfo?(lhenry) → needinfo?(andrei.vaida)
Comment on attachment 8743080 [details] [diff] [review]
Patch for m-b (part0 only)

Belated approval, thanks!
Attachment #8743080 - Flags: approval-mozilla-release+
Attachment #8743080 - Flags: approval-mozilla-beta?
Attachment #8743080 - Flags: approval-mozilla-beta+
Comment on attachment 8743126 [details] [diff] [review]
Patch for m-b (part2)

[Triage Comment]
Attachment #8743126 - Flags: approval-mozilla-release+
Attachment #8743126 - Flags: approval-mozilla-beta?
Attachment #8743126 - Flags: approval-mozilla-beta+
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #55)
> Andrei can your team check password manager as described in comment 53?
> Thanks.

We'll make sure this area gets tested as well during the sign off of 46.0-build4. Leaving the ni? in place until we follow up with test results.
Confirming that the username is now correctly displayed when updating the password field.
Tested during the Fx 46.0-build4 (build ID 20160420024437) sign-off across platform.

Additional details are available in the actual sign off email sent for Fx46.0 RC2 (build 4), on r-d.
Flags: needinfo?(andrei.vaida)
Reporter

Comment 60

3 years ago
Verified this issue on:

-Firefox Dev Edition 47.0a2
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160421004015

- Nightly 48.0a1
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160421030302

and it is no longer reproducible.
Flags: needinfo?(vlad.bacia)
Marking the issue as verified on Firefox 47 based on the comment above.

Also, I will change the status of the bug in VERIFIED FIXED.
Status: RESOLVED → VERIFIED
Depends on: 1517726
You need to log in before you can comment on or make changes to this bug.