Win: Display a native bubble (instead of the JS one) after the web signin flow.
Part of a 3 CL Voltron, along with:
[GTK] https://codereview.chromium.org/14258007
[Mac] https://codereview.chromium.org/13845022/
BUG=119728
TEST=Open Chrome. Delete all your profiles, so that you have a fresh one. Open a new tab, and press the "sign in" link in the top right corner. Sign in. Upon completion, this should show a native popup bubble, anchored off the wrench menu. If you try to log in with the same email in another profile, the bubble should display a sad error message. Check out the issue description for screenshots.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=197622
Merged the Bubble/Dialog classes as discussed, and hopefully fixed all of the other comments. Please ...
7 years, 8 months ago
(2013-04-17 20:32:37 UTC)
#5
Merged the Bubble/Dialog classes as discussed, and hopefully fixed all of the
other comments. Please review when free :)
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/browser...
File chrome/browser/ui/browser_window.h (right):
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/browser...
chrome/browser/ui/browser_window.h:235: const std::string& error_message) = 0;
On 2013/04/17 17:53:25, Roger Tawa wrote:
> nit: is it better to put the error_message arg before the callback ?
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/sync/on...
File chrome/browser/ui/sync/one_click_signin_helper.cc (right):
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/sync/on...
chrome/browser/ui/sync/one_click_signin_helper.cc:982: Browser* browser =
chrome::FindBrowserWithWebContents(contents);
On 2013/04/17 17:53:25, Roger Tawa wrote:
> Move the var declaration closer to where its used (i.e. inside the if block).
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/sync/on...
chrome/browser/ui/sync/one_click_signin_helper.cc:1245: error_message_);
On 2013/04/17 17:53:25, Roger Tawa wrote:
> why not std::string() like line 1284 below? Will there ever be an message in
> this case?
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/sync/on...
File chrome/browser/ui/sync/one_click_signin_helper_unittest.cc (left):
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/sync/on...
chrome/browser/ui/sync/one_click_signin_helper_unittest.cc:744:
To make sure it didn't go untested, I've rewritten them as browser tests. All
these particular tests used to do was check if a "showPopup" preference was set
in the PrefsService, which isn't applicable anymore. I'm not sure there is
something equivalent to tell whether the native dialog is showing.
On 2013/04/17 17:53:25, Roger Tawa wrote:
> Instead of removing this tests, can they be rewritten to test that the new
> bubble is showing? Is there a platform independent way to test for that?
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
File chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc (right):
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:224: bool
isAcceleratorPressed =
On 2013/04/17 17:53:25, Roger Tawa wrote:
> variable naming should be:
>
> is_accelerator_pressed
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:265:
toolbar_view->GetWebContents(),
Added a comment that both the dialog and the bubble outlive the tab (the bubble
registers the click and closes, and the tab is modal)
On 2013/04/17 17:53:25, Roger Tawa wrote:
> I'm concerned about storing a contents pointer as a member of the bubble view
> class. I suspect it could be possible for the bubble to outlive the contents.
> This does not concern me too much with the dialogs since they are modal, but
it
> *may* be a problem there too.
>
> The contents is used to show the a tab when the user clicks on a link in the
> bubble or dialog. I wonder if it would be better to save a pointer the
Browser
> object instead (which will certainly outlive the bubble or dialog) and then if
a
> link is clicked the code opens a new tab instead via Browser::OpenURL() ?
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:266:
toolbar_view->app_menu(), error_message);
On 2013/04/17 17:53:25, Roger Tawa wrote:
> ident lines 265 and 266 by 2 more.
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:295:
content::WebContents* web_content,
On 2013/04/17 17:53:25, Roger Tawa wrote:
> indent 2 more.
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:359:
l10n_util::GetStringUTF16(IDS_ONE_CLICK_SIGNIN_BUBBLE_MESSAGE));
On 2013/04/17 17:53:25, Roger Tawa wrote:
> indent 2 more.
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:376:
layout->AddView(ok_button_);
The two InitButtons functions got merged, so this isn't an issue anymre
On 2013/04/17 17:53:25, Roger Tawa wrote:
> I'm not sure InitButtons() needs to be virtual or reimplemented/overridden in
> the derived class. If its implemented only in the base class, and it checks
the
> returned pointers for null before adding them to the layout, I think it can be
> made generic.
>
> Also, since the bubble no longer needs an undo button (only the dialog does)
> then probably need to be creating it anyway. Might be able to remove a lot of
> code in OneClickSigninBubbleView::GetButtons().
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:395:
l10n_util::GetStringUTF16(IDS_ONE_CLICK_SIGNIN_DIALOG_UNDO_BUTTON);
On 2013/04/17 17:53:25, Roger Tawa wrote:
> Just want to double check this is the correct string. The IDS contains the
word
> "DIALOG", but this is not the dialog implementation. Same for line 405 below.
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:413:
l10n_util::GetStringUTF16(IDS_LEARN_MORE));
On 2013/04/17 17:53:25, Roger Tawa wrote:
> indent 2 less.
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:417: return
learn_more_link_;
Made private, renamed it to InitXXXLink and removed the return type, to be
consistent with InitContent/InitButtons etc.
On 2013/04/17 17:53:25, Roger Tawa wrote:
> Local var should not have a trailing _ in name.
>
> However, if this method were renamed to something like CreateLearnMoreLink(),
it
> could the member variable as well as return the pointer. Then you can make
this
> member variable private.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:424:
OneClickSigninBubbleView::Hide();
On 2013/04/17 17:53:25, Roger Tawa wrote:
> I don't think you need the class name here. Same at line 448 below.
Done.
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
File chrome/browser/ui/views/sync/one_click_signin_bubble_view.h (right):
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.h:81: virtual
views::Link* GetAdvancedLink();
Moved all of them to private as I killed the silly inheritance structure.
On 2013/04/17 17:53:25, Roger Tawa wrote:
> The GetXXXLink() methods should probably moved below all the base class
> overrides. Why are these methods protected?
https://codereview.chromium.org/13979003/diff/23003/chrome/browser/ui/views/s...
chrome/browser/ui/views/sync/one_click_signin_bubble_view.h:96:
content::WebContents* web_content_;
On 2013/04/17 17:53:25, Roger Tawa wrote:
> Member variables should always be private. Might be better to name
> web_contents_ ?
Done.
Roger Tawa OOO till Jul 10th
lgtm https://codereview.chromium.org/13979003/diff/34001/chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc File chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc (right): https://codereview.chromium.org/13979003/diff/34001/chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc#newcode260 chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc:260: (*undo_button)->SetStyle(views::Button::STYLE_NATIVE_TEXTBUTTON); if !is_sync_dialog_, probably should not create the ...
7 years, 8 months ago
(2013-04-17 21:09:17 UTC)
#6
Hi sky/thakis/erg, Could you please do an owners review? I've split this fix up in ...
7 years, 8 months ago
(2013-04-18 17:25:52 UTC)
#7
Hi sky/thakis/erg,
Could you please do an owners review? I've split this fix up in 3 different CLs,
and the GTK/Mac platform-specific implementations are coming in followup CLs
later on this week. I will only commit them all at the same time -- hope that
sounds ok (the alternative was a massive CL, but let me know if you'd prefer
that)
@thakis:
chrome/browser/ui/cocoa/browser_window_cocoa.h
chrome/browser/ui/cocoa/browser_window_cocoa.mm
@erg
chrome/browser/ui/gtk/browser_window_gtk.h
chrome/browser/ui/gtk/browser_window_gtk.cc
@sky
chrome/browser/ui/views/frame/browser_view.h
chrome/browser/ui/views/frame/browser_view.cc
chrome/browser/ui/views/sync/one_click_signin_bubble_view.h
chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc
chrome/browser/ui/views/sync/one_click_signin_bubble_view_browsertest.cc
Thanks!
https://codereview.chromium.org/13979003/diff/54001/chrome/browser/ui/browser_window.h File chrome/browser/ui/browser_window.h (right): https://codereview.chromium.org/13979003/diff/54001/chrome/browser/ui/browser_window.h#newcode234 chrome/browser/ui/browser_window.h:234: const std::string& error_message, The error_message comes as a utf8 ...
7 years, 8 months ago
(2013-04-18 18:08:28 UTC)
#9
https://codereview.chromium.org/13979003/diff/54001/chrome/browser/ui/browser...
File chrome/browser/ui/browser_window.h (right):
https://codereview.chromium.org/13979003/diff/54001/chrome/browser/ui/browser...
chrome/browser/ui/browser_window.h:234: const std::string& error_message,
The error_message comes as a utf8 string from
OneClickSigninHelper::SigninFailed, where it seems to be
gotted/internationalized with l10n_util::GetStringUTF8.
I could convert it to string16() when ShowOneClickSigninBubble is called,
instead of when displaying it in the views label as I currently do -- would that
be better? I don't particularly know why it isn't got initially as a UTF16, but
one option I guess would also be changing that?
On 2013/04/18 17:53:28, Nico wrote:
> We used to use string16 for text that could possibly contain international
text.
> I think that's no longer true, but since the previous parameter is string16,
> should error_message be string16 too?
7 years, 8 months ago
(2013-04-18 19:04:11 UTC)
#10
https://codereview.chromium.org/13979003/diff/54001/chrome/browser/ui/browser...
File chrome/browser/ui/browser_window.h (right):
https://codereview.chromium.org/13979003/diff/54001/chrome/browser/ui/browser...
chrome/browser/ui/browser_window.h:234: const std::string& error_message,
On 2013/04/18 18:08:28, Monica Dinculescu wrote:
> The error_message comes as a utf8 string from
> OneClickSigninHelper::SigninFailed, where it seems to be
> gotted/internationalized with l10n_util::GetStringUTF8.
>
> I could convert it to string16() when ShowOneClickSigninBubble is called,
> instead of when displaying it in the views label as I currently do -- would
that
> be better? I don't particularly know why it isn't got initially as a UTF16,
but
> one option I guess would also be changing that?
>
>
> On 2013/04/18 17:53:28, Nico wrote:
> > We used to use string16 for text that could possibly contain international
> text.
> > I think that's no longer true, but since the previous parameter is string16,
> > should error_message be string16 too?
>
It might have been utf8 previously because that is what the ntp bubble expected.
But with the new bubble, changing to string16 in one-clicks-signin before
passing to ShowOneClickSigninBubble sounds good.
noms (inactive)
Done. I left the OneClickSigninHelper::SigninFailed to continue returning an std::string, as that's what it gets ...
7 years, 8 months ago
(2013-04-19 19:13:00 UTC)
#11
Done.
I left the OneClickSigninHelper::SigninFailed to continue returning an
std::string, as that's what it gets from the GoogleServiceAuthError object, and
changing that is a pretty deep rabbit hole. :)
On 2013/04/18 19:04:11, Roger Tawa wrote:
>
https://codereview.chromium.org/13979003/diff/54001/chrome/browser/ui/browser...
> File chrome/browser/ui/browser_window.h (right):
>
>
https://codereview.chromium.org/13979003/diff/54001/chrome/browser/ui/browser...
> chrome/browser/ui/browser_window.h:234: const std::string& error_message,
> On 2013/04/18 18:08:28, Monica Dinculescu wrote:
> > The error_message comes as a utf8 string from
> > OneClickSigninHelper::SigninFailed, where it seems to be
> > gotted/internationalized with l10n_util::GetStringUTF8.
> >
> > I could convert it to string16() when ShowOneClickSigninBubble is called,
> > instead of when displaying it in the views label as I currently do -- would
> that
> > be better? I don't particularly know why it isn't got initially as a UTF16,
> but
> > one option I guess would also be changing that?
> >
> >
> > On 2013/04/18 17:53:28, Nico wrote:
> > > We used to use string16 for text that could possibly contain international
> > text.
> > > I think that's no longer true, but since the previous parameter is
string16,
> > > should error_message be string16 too?
> >
>
> It might have been utf8 previously because that is what the ntp bubble
expected.
> But with the new bubble, changing to string16 in one-clicks-signin before
> passing to ShowOneClickSigninBubble sounds good.
Roger Tawa OOO till Jul 10th
https://codereview.chromium.org/13979003/diff/39003/chrome/browser/ui/sync/one_click_signin_helper.cc File chrome/browser/ui/sync/one_click_signin_helper.cc (right): https://codereview.chromium.org/13979003/diff/39003/chrome/browser/ui/sync/one_click_signin_helper.cc#newcode1406 chrome/browser/ui/sync/one_click_signin_helper.cc:1406: RedirectToNtpOrAppsPage(show_bubble); The sign in code does two redirects to ...
7 years, 8 months ago
(2013-04-22 20:49:05 UTC)
#12
https://codereview.chromium.org/13979003/diff/39003/chrome/browser/ui/sync/on...
File chrome/browser/ui/sync/one_click_signin_helper.cc (right):
https://codereview.chromium.org/13979003/diff/39003/chrome/browser/ui/sync/on...
chrome/browser/ui/sync/one_click_signin_helper.cc:1406:
RedirectToNtpOrAppsPage(show_bubble);
The sign in code does two redirects to the NTP: once at line 1326 and another
here. The reason for this is to show the NTP as soon as possible so that the
user is not staring at a blank page (line 3126). Then, once we know whether the
sign in was successful or not, we redirect again to display the bubble.
Redirecting to the NTP is the only way to get that bubble shown (here).
Now that the bubble is not in the NTP, we probably don't need the extra redirect
here. Brian is looking into a bug where the multiple redirect cause a race
condition. Please go see him and see if removing the extra call would help him
out. Even if it does not, seems like we should get rid the extra redirect
anyway.
Elliot Glaysher
gtk lgtm stamp.
7 years, 8 months ago
(2013-04-23 18:18:40 UTC)
#13
gtk lgtm stamp.
noms (inactive)
https://codereview.chromium.org/13979003/diff/39003/chrome/browser/ui/sync/one_click_signin_helper.cc File chrome/browser/ui/sync/one_click_signin_helper.cc (right): https://codereview.chromium.org/13979003/diff/39003/chrome/browser/ui/sync/one_click_signin_helper.cc#newcode1406 chrome/browser/ui/sync/one_click_signin_helper.cc:1406: RedirectToNtpOrAppsPage(show_bubble); Done. (I hope!) On 2013/04/22 20:49:05, Roger Tawa ...
7 years, 8 months ago
(2013-04-23 19:21:22 UTC)
#14
https://codereview.chromium.org/13979003/diff/39003/chrome/browser/ui/sync/on...
File chrome/browser/ui/sync/one_click_signin_helper.cc (right):
https://codereview.chromium.org/13979003/diff/39003/chrome/browser/ui/sync/on...
chrome/browser/ui/sync/one_click_signin_helper.cc:1406:
RedirectToNtpOrAppsPage(show_bubble);
Done. (I hope!)
On 2013/04/22 20:49:05, Roger Tawa wrote:
> The sign in code does two redirects to the NTP: once at line 1326 and another
> here. The reason for this is to show the NTP as soon as possible so that the
> user is not staring at a blank page (line 3126). Then, once we know whether
the
> sign in was successful or not, we redirect again to display the bubble.
> Redirecting to the NTP is the only way to get that bubble shown (here).
>
> Now that the bubble is not in the NTP, we probably don't need the extra
redirect
> here. Brian is looking into a bug where the multiple redirect cause a race
> condition. Please go see him and see if removing the extra call would help
him
> out. Even if it does not, seems like we should get rid the extra redirect
> anyway.
Roger Tawa OOO till Jul 10th
lgtm https://codereview.chromium.org/13979003/diff/73001/chrome/browser/ui/sync/one_click_signin_helper.cc File chrome/browser/ui/sync/one_click_signin_helper.cc (right): https://codereview.chromium.org/13979003/diff/73001/chrome/browser/ui/sync/one_click_signin_helper.cc#newcode979 chrome/browser/ui/sync/one_click_signin_helper.cc:979: Profile::FromBrowserContext(contents->GetBrowserContext()); Can move these variables into the if ...
7 years, 8 months ago
(2013-04-23 19:49:12 UTC)
#15
7 years, 7 months ago
(2013-05-01 15:59:28 UTC)
#21
Message was sent while issue was closed.
Change committed as 197622
M-A Ruel
https://chromiumcodereview.appspot.com/13979003/diff/116001/chrome/browser/ui/views/sync/one_click_signin_bubble_view_browsertest.cc File chrome/browser/ui/views/sync/one_click_signin_bubble_view_browsertest.cc (right): https://chromiumcodereview.appspot.com/13979003/diff/116001/chrome/browser/ui/views/sync/one_click_signin_bubble_view_browsertest.cc#newcode51 chrome/browser/ui/views/sync/one_click_signin_bubble_view_browsertest.cc:51: IN_PROC_BROWSER_TEST_F(OneClickSigninBubbleViewBrowserTest, ShowBubble) { I saw this test fail on ...
7 years, 7 months ago
(2013-05-21 17:48:25 UTC)
#22
Issue 13979003: Win: Display a native bubble (instead of the JS one) after the web signin flow.
(Closed)
Created 7 years, 8 months ago by noms (inactive)
Modified 7 years, 7 months ago
Reviewers: Roger Tawa OOO till Jul 10th, Elliot Glaysher, sky, Nico, M-A Ruel
Base URL: https://chromium.googlesource.com/chromium/src.git@master
Comments: 59