Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show welcome page only at first run #130

Merged
merged 3 commits into from
Jun 5, 2018
Merged

Show welcome page only at first run #130

merged 3 commits into from
Jun 5, 2018

Conversation

simonhong
Copy link
Member

@simonhong simonhong commented Jun 4, 2018

When welcome page is requested at the first run, store that this profile
has been shown the welcome page.

close brave/brave-browser#221
close brave/brave-browser#264

Submitter Checklist:

  • Submitted a ticket for my issue if one did not already exist.
  • Used Github auto-closing keywords in the commit message.
  • Added/updated tests for this change (for new code or code which already has tests).
  • Ran git rebase -i to squash commits (if needed).
  • Tagged reviewers and labelled the pull request as needed.
  • Request a security/privacy review as needed.

Test Plan:

--filter BraveWelcomeUIBrowserTest*

Reviewer Checklist:

  • New files have MPL-2.0 license header.
  • Request a security/privacy review as needed.
  • Adequate test coverage exists to prevent regressions

@simonhong
Copy link
Member Author

simonhong commented Jun 4, 2018

To add test case for this, brave/brave-browser#264 should be resolved first.

@bbondy
Copy link
Member

bbondy commented Jun 4, 2018

Just curious if you know why code to remember no welcome page is needed, I'd think this would already be handled by chromium code somewhere.

You probably already know but you can test spanning restarts of the app with:

Tests Spanning Restarts
A test can span a restart of the browser process. This is useful in testing that something persisted, as an example. To do this, use the PRE prefix:

IN_PROC_BROWSER_TEST_F(InProcessBrowserTest, PRE_Foo) {
  // Do something.
}

IN_PROC_BROWSER_TEST_F(InProcessBrowserTest, Foo) {
  // Verify something was done.
}

from: https://www.chromium.org/developers/testing/running-tests

@simonhong
Copy link
Member Author

Just curious if you know why code to remember no welcome page is needed, I'd think this would already be handled by chromium code somewhere.

You're right. chromium handles it in each webui controller(WelcomeUI and WelcomeWin10UI) for their URL. After we changed the chromium url to our welcome url from HandleURLRewrite() in our url handler(brave_content_browser_client.cc), that code has not been executed.
Because of that, I created our webui controller for kWelcomeRemoteURL.

You probably already know but you can test spanning restarts of the app with:

Yep, I tried to check the tab list state between first run and second run by using spanning test technique. I realized that our browser test should use BraveMainDelegate to test BraveContentBrowserClient features.

@bbondy
Copy link
Member

bbondy commented Jun 5, 2018

That makes sense, thanks.

@simonhong simonhong requested a review from bbondy June 5, 2018 02:11
@simonhong simonhong changed the title WIP: Show welcome page only at first run Show welcome page only at first run Jun 5, 2018
profile->GetPrefs()->SetBoolean(prefs::kHasSeenWelcomePage, true);
#if defined(OS_WIN)
g_brave_browser_process->local_state()->SetBoolean(
prefs::kHasSeenWin10PromoPage,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to set this pref even know we don't want a win10 promo page?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked that chrome shows this promo page at first run. Then, it shows welcome page at next run.
So, if we doesn't set, we will show our welcome ui at first run and second run.

bbondy
bbondy previously approved these changes Jun 5, 2018
@bbondy
Copy link
Member

bbondy commented Jun 5, 2018

ok thanks, looks good. Looks like you need to rebase test/BUILD.gn, then feel free to merge.

@simonhong
Copy link
Member Author

Thanks for fast review.
I'll merge after rebasing this on C67.

When welcome page is requested at the first run, store that this profile
has been shown the welcome page.
So far, ChromeMainDelegate is used.
welcome ui only should be added at first run.
@simonhong
Copy link
Member Author

@bbondy After rebasing on C68, your approving was disappeared :)

@simonhong simonhong self-assigned this Jun 5, 2018
@simonhong simonhong requested a review from emerick June 5, 2018 11:53
@simonhong
Copy link
Member Author

simonhong commented Jun 5, 2018

@emerick , PTAL again. I think @bbondy couldn't check for some time(travelling).
I got approved but it disappeared when this is rebased on C67.

Copy link
Contributor

@emerick emerick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@simonhong
Copy link
Member Author

@emerick Thank you!

@simonhong simonhong merged commit 1dc4273 into master Jun 5, 2018
@simonhong simonhong deleted the fix_welcome_ui branch June 5, 2018 11:59
@@ -47,6 +53,8 @@ WebUIFactoryFunction GetWebUIFactoryFunction(WebUI* web_ui,
if (url.host_piece() == kPaymentsHost ||
url.host_piece() == chrome::kChromeUINewTabHost) {
return &NewWebUI<BasicUI>;
} else if (url.spec() == kWelcomeRemoteURL) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@diracdeltas @bbondy - this isn't directly related to this PR, but I think a remote welcome url is a privacy issue. Is there any reason why it can't be an internal page?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed changing to local welcome page but no one has had time to do that yet. Note that browser-laptop is remote too so we have at least baseline parity with that. But we did talk about wanting to move to a local one.

Copy link
Collaborator

@bridiver bridiver Jun 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like it should be pretty easy to do now that we have a webui for it. Is there a ticket or should I create one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought there was but I couldn't find one, so I posted it here:
brave/brave-browser#276

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here's the original issue by @flamsmark brave/browser-laptop#12691. i also feel strongly that this should be baked into brave for privacy reasons.

simonhong added a commit that referenced this pull request Jun 11, 2018
This seems the regression from #130.
In that CL, BraveWelcomeUI WebUIController is introduced.
Because of this, current welcome ui page treated as webui.
This CL could be reverted when our local welcome ui is implemented.
NejcZdovc added a commit that referenced this pull request Dec 10, 2018
Favicon URL for youtube publishers should now be retrieved properly.
NejcZdovc pushed a commit that referenced this pull request Sep 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use BraveMainDelegate for brave_browser_tests https://brave.com/welcome/ shows on each browser launch
5 participants