-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Allow auto-upgrade from browser-laptop via argument #1545
Comments
@garrettr I know we've talked about it before: does import handle the referral promo? (importing the |
@bsclifton Not yet, but isn't that being tracked in #1294? |
@garrettr yes- that is correct 😄 Totally forgot about that (nothing to see here!) 😅 |
While exploring options for implementing this feature, I discovered that Chromium already has a first-run auto-import feature. Here's how it works:
To reuse this functionality to achieve auto-import from browser-laptop upon upgrade, we would need to:
With these items implemented, Brave Browser would auto-import all supported data types from the user's current default browser, regardless of whether it is browser-laptop/Muon or something else. We should then consider whether we want to:
It'd be nice to leverage this existing functionality, as long as it satisfies our design requirements. @bsclifton What do you think? See any potential conflicts with the functionality you require? |
@garrettr wow- this is pretty cool and it would be great to re-use this 😄 I guess it depends on how hard implementing #104 would be. If you think we can land this (along with the other import logic) within the next week, I'd say lets go for it. If that might be at risk, I'd say let's go for a flag-only approach for now (and then follow up with this later, if it makes sense) With regards to the auto-import from browser-laptop/Muon... could we implement both? For example, we can (by default) implement your option 1 (only import if it's the default browser). We could then override this by providing the flag specified here ( So far, all stakeholders have agreed on always importing on first run. We can definitely revisit that though- cc: @rebron @davidtemkin @bbondy @kjozwiak |
When we auto-import from Muon following an upgrade, that is a version upgrade from a user POV. It's like going from Chrome 69 to Chrome 70, except that there are, ahem, substantial changes. But the process we are modeling is that of upgrading a browser to the latest version, not that of installing a new browser and importing from a pre-existing browser. So the expectation is that a user's data will be carried over. A manual download, I think, is different. I don't think we'd want to auto-import from any browser (Muon or other) when a user has manually downloaded/installed brave core. In that case, they need to decide what to do, as the process we are modeling in that case is one of installing a new browser. In that situation, it isn't a given that they'd want to import from Muon, or from their default browser, or from any browser. |
Good point, @davidtemkin—it's important to distinguish the "auto upgrade from muon to brave-core" and "manually installed brave-core" cases, and a command line set on the first run of the new browser by the upgrader is definitely the simplest way to accomplish that. We could tie reusing the existing first_run::AutoImport functionality together with a command line arg by adding a pref that can be set on the command line, e.g. via CommandLinePrefStore. The only potential downside is it would limit Brave auto-import to running only when both conditions—brave-core is on first run, and pref is set (by command line arg, or another mechanism)—are true. This seems to exactly fit our use case, but I can imagine it might make manual testing somewhat cumbersome because you would have to clear brave-core's state every time so it would think it was on its first run (but devs should probably do that anyway?) |
@garrettr as long as it's manually testable, no worries about needing to nuke profiles/states. QA nukes states/profiles on a daily basis so no worries there 👍I personally do it at least 10-15 times sometimes. |
Worth noting that some Chromium devs appear to have been considering the removal of |
Using test plan from description and
I found that:
Verification passed on
Verification passed on
Verification Passed on
|
Logged follow up issue #2013 for cookies not being imported |
@garrettr @bsclifton should launching b-c with the command line paramenter when b-l is open should it import ? It does ask the browser to be closed when you try to manually import from Brave |
@srirambv you'll get a chance to try that with the browser-laptop release, but as soon as brave-core is launched, browser-laptop quits |
Good question, @srirambv, I will test to verify the behavior. The b-l importer cannot run correctly if b-l is open. When a b-c user initiates b-l import, the status of b-l is detected and the user is prompted to close b-l before continuing the import. It is likely that this check is getting ignored or bypassed when the importer is run automatically. |
Test plan (run on Win32/Win64/macOS/Linux)
Test: first run
--upgrade-from-muon
Test: only runs once
After completing steps 1-5 of the first run test:
--upgrade-from-muon
Test notes
Brave Payments is not covered with this issue. That work is taking place in brave/brave-core#736 (which fixes issue #1215)
Description
brave-browser should recognize an optional argument, e.g.
--upgrade-from-muon
or--upgrade-from-browser-laptop
, such that if the argument is provided, it should:We may also want to:
--quit-after-import
).The text was updated successfully, but these errors were encountered: