Closed Bug 738234 Opened 10 years ago Closed 10 years ago
Account provisioner success window blocks compose window password prompt
STR: 1) Order a new email address from Hover.com through the account provisioner 2) When the success window appears, choose to compose a new message. 3) Write a message to some recipient, and send What happens? The sending is blocked until the success window is closed. This is because the composer is attempting to prompt for a password, but is being blocked by the success modal window.
Moving to 13, as we're not shipping account prov in 12.
So I know that we'd ideally like to have our providers echo back the user's password via XML so that the user doesn't have to re-enter the password for their new account... ...but in the event that this doesn't happen, this patch closes the success dialog when the user chooses to write a new message, which eliminates the password-prompt problem. Blake - sound like the right approach?
Attachment #626084 - Flags: ui-review?(bwinton)
Comment on attachment 626084 [details] [diff] [review] Patch v1 Ugh, given that there are more things we would want the user to be able to do after writing email, I don't think this is really the right approach, unless we can re-open the success dialog after the compose window closes… /me mumbles something about compose-in-a-tab and tab-modal password prompts… I mean, I guess this is better than hanging, so ui-r=me if we really need to land something, but it also doesn't feel like the right solution…
Attachment #626084 - Flags: ui-review?(bwinton) → ui-review-
Blake: How about we just make the success dialog non-modal? -Mike
Making the success dialog non-modal is both possible, and does seem to address the issue (in that the password prompt successfully came up when I tried to send mail from a new Hover.com account when using a composer spawned from the success dialog). What do you think of this approach, Blake?
Comment on attachment 626466 [details] [diff] [review] Make success dialog non-modal - Patch v1 Yeah, I think this works… ui-r=me! And the code looks good too, so let's say r=me while we're here to save time. Thanks, Blake.
Comment on attachment 626466 [details] [diff] [review] Make success dialog non-modal - Patch v1 I think this is pretty low risk.
Whoops - this broke one of our newmailaccount Mozmill tests, since it was using the modal window tools instead of our normal window tools. This patch fixes that, and our newmailaccount tests pass with this patch. Carrying forward ui-r+ and r+ from bwinton, since the change is test-only.
Attachment #626557 - Attachment description: Patch v2 (fixes tests) → Patch v2 (fixes tests - carrying forward ui-r+/r+ from bwinton)
(In reply to Mike Conley (:mconley) from comment #9) > comm-beta: https://hg.mozilla.org/releases/comm-beta/rev/5fa5eaf77d48 That was actually landed on a relbranch, so I've transplanted it to the default branch: https://hg.mozilla.org/releases/comm-beta/rev/383e1aa8a1c5
(In reply to Mark Banner (:standard8) from comment #10) > (In reply to Mike Conley (:mconley) from comment #9) > > comm-beta: https://hg.mozilla.org/releases/comm-beta/rev/5fa5eaf77d48 > > That was actually landed on a relbranch, so I've transplanted it to the > default branch: > > https://hg.mozilla.org/releases/comm-beta/rev/383e1aa8a1c5 Yikes, sorry about that. Thanks Mark.
You need to log in before you can comment on or make changes to this bug.