Closed
Bug 1192032
Opened 9 years ago
Closed 9 years ago
Import bookmarks / favorites from Microsoft Edge
Categories
(Firefox :: Migration, defect, P2)
Firefox
Migration
Tracking
()
VERIFIED
FIXED
Firefox 43
People
(Reporter: Dolske, Assigned: Gijs)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
40 bytes,
text/x-review-board-request
|
MattN
:
review+
|
Details |
23.32 KB,
patch
|
Gijs
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
24.50 KB,
patch
|
Gijs
:
review+
ritu
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
We need a migrator that can import a user's existing Edge bookmarks.
Reporter | ||
Comment 1•9 years ago
|
||
Edge also has a Reading List. We have Pocket, but importing to Pocket would be rather complicated. I think as part of the Favorites import, we should also import a "Reading List" folder with the user's Edge Reading List items.
Summary: Import bookmarks from Microsoft Edge → Import bookmarks / favorites / reading list from Microsoft Edge
Comment 2•9 years ago
|
||
We do the same for Safari, we create a "Reading List (From Safari)" folder in the bookmarks menu, see importedSafariReadingList
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•9 years ago
|
||
I've started looking at this. Good news: once you find the right folder, favourites seem to be stored in exactly the same format + layout as they were under IE. I've not tried finding the reading list stuff yet, and I think in principle that could be a followup bug. Bad news: bug 1163644 comment #9 and bug 1163644 comment #12 seem to not be particularly useful, as best I can tell, in that getting the SID for the app requires the "family name" which includes the useless goop (on win10 public release that seems to be _8wekyb3d8bbwe) at the end. The goop seems to be the same everywhere, judging by the number of hits on Google. It seems to have been different when Edge was still "Spartan". I don't know if it will change in the future, but I am worried about hardcoding it. While we could try to use the firewall APIs (see bug 1163644 comment #12) to enumerate app containers and find it that way, I think the simplest thing that would work here is to just grab the local app data folder, smack "Packages" on and enumerate subfolders (if possible, only those starting with Microsoft.MicrosoftEdge), and then find the sub(subsubsub...) folder we want.
Assignee | ||
Comment 4•9 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #3) > getting the SID for the app > requires the "family name" which includes the useless goop (on win10 public > release that seems to be _8wekyb3d8bbwe) at the end. The same goes for the package query APIs described in https://msdn.microsoft.com/en-us/library/windows/desktop/hh446597%28v=vs.85%29.aspx . I mean, that or a process ID, but obviously we can't assume Edge is running, and starting it sounds weird and would maybe be a bit of a chicken-egg problem anyway.
Comment 5•9 years ago
|
||
Edge definitely changed the (In reply to :Gijs Kruitbosch from comment #3) > Bad news: bug 1163644 comment #9 and bug 1163644 comment #12 seem to not be > particularly useful, as best I can tell, in that getting the SID for the app > requires the "family name" which includes the useless goop (on win10 public > release that seems to be _8wekyb3d8bbwe) at the end. The goop seems to be > the same everywhere, judging by the number of hits on Google. It seems to > have been different when Edge was still "Spartan". I don't know if it will > change in the future, but I am worried about hardcoding it. It was the same everywhere and changed when "Spartan" was changed to Edge. See the blog post from Microsoft: http://blogs.windows.com/bloggingwindows/2015/06/19/upcoming-changes-to-windows-10-insider-preview-builds/ > In the next build we release to Windows Insiders in the Fast ring, the “Project Spartan” > name will officially change to Microsoft Edge. One result of this naming means that the > Microsoft Edge app has a new app ID. This will cause any favorites, cookies, history and > Reading list items that you had saved in the Project Spartan app to be lost after upgrading > from a previous Windows 10 Insider Preview build. If you want to keep these, you will need > to back up your favorites before the next flight! To save your favorites, follow these > steps before upgrading to the next build we release (do it now): > - Copy your favorites from %localappdata%/Packages/Microsoft.Windows.Spartan_cw5n1h2txyewy/AC/Spartan/User/Default/Favorites. > - Save them to %userprofile%/Favorites. > - After upgrading to the next build open Microsoft Edge, choose Settings, and you’ll see an > option to import favorites from another browser. Choose Internet Explorer to import the > favorites you saved in your %userprofile% directory into Microsoft Edge. I think we can expect it will not be changed again because otherwise users will lose the bookmarks (and other settings) again. Moreover, we already depend on a hard-coded app ID: https://mxr.mozilla.org/mozilla-central/source/browser/components/shell/nsWindowsShellService.cpp?rev=7c48a3782efe&mark=875-875#862
Assignee | ||
Comment 6•9 years ago
|
||
Bug 1192032 - add edge bookmarks/favorites migrator, r?MattN
Assignee | ||
Updated•9 years ago
|
Attachment #8646421 -
Flags: review?(MattN+bmo)
Assignee | ||
Comment 7•9 years ago
|
||
Comment on attachment 8646421 [details] MozReview Request: Bug 1192032 - add edge bookmarks/favorites migrator, r?MattN Bug 1192032 - add edge bookmarks/favorites migrator, r?MattN
Assignee | ||
Updated•9 years ago
|
Summary: Import bookmarks / favorites / reading list from Microsoft Edge → Import bookmarks / favorites from Microsoft Edge
Comment 8•9 years ago
|
||
Sorry for not getting to this review today… it was probably the day with the most meetings in my life so far…
Updated•9 years ago
|
Attachment #8646421 -
Flags: review?(MattN+bmo) → review+
Comment 9•9 years ago
|
||
Comment on attachment 8646421 [details] MozReview Request: Bug 1192032 - add edge bookmarks/favorites migrator, r?MattN https://reviewboard.mozilla.org/r/15735/#review14207 Looks good! ::: browser/components/migration/EdgeProfileMigrator.js:13 (Diff revision 2) > +function EdgeProfileMigrator() > +{ Nit: brace on the same line please. The IE migrator was the only one using this incorrect style. ::: browser/components/migration/EdgeProfileMigrator.js:19 (Diff revision 2) > +EdgeProfileMigrator.prototype.getResources = function Edge_getResources() { Nit: My understanding is that you don't need to name the function here anymore. ::: browser/components/migration/MSMigrationUtils.jsm:19 (Diff revision 2) > +Cu.importGlobalProperties(["File"]); I'm not familiar with this global and I also don't see it being used. ::: browser/components/migration/MSMigrationUtils.jsm:30 (Diff revision 2) > + get exists() !!this._favoritesFolder, Could you at least add a sanity check test that ensures that `.exists` returns true for MIGRATION_TYPE_EDGE? Since we can't use skip-if AFAIK to skip this on <Win10, have the test do a Windows version check at runtime and bail saying it's not applicable. I realize this test will always bail in automation now since we don't have Win10 test machines yet but it will at least catch issues for developers locally and in the future when the test machines are running Win10 or later. ::: browser/components/migration/MSMigrationUtils.jsm:38 (Diff revision 2) > + let favoritesFolder = Services.dirsvc.get("Favs", Ci.nsIFile); It's surprising to me that the "Favorites" directory still exists in the user's home directory on Windows 10 but doesn't contain their Edge Favorites (even when Edge is set as the default browser). This seems like a weird decision on MSFT's part but okay. ::: browser/components/migration/MSMigrationUtils.jsm:167 (Diff revision 2) > + MIGRATION_TYPE_IE: 0, Nit: 0 is falsy which makes me worry someone will accidentally go into an error condition when migrating IE. e.g. if (!migrationType)… I would start numbering at 1 to avoid this ::: browser/components/migration/MSMigrationUtils.jsm:169 (Diff revision 2) > + getBookmarksMigrator(migrationType=this.MIGRATION_TYPE_IE) { Nit: spaces around operators ::: browser/components/migration/MigrationUtils.jsm:499 (Diff revision 2) > - "firefox", "ie", "chrome", "chromium", "safari", "360se", "canary" > + "firefox", "ie", "edge", "chrome", "chromium", "safari", "360se", "canary" I think Edge should come before IE since Edge is the default when it's available. ::: browser/components/migration/content/migration.xul:37 (Diff revision 2) > <radio id="ie" label="&importFromIE.label;" accesskey="&importFromIE.accesskey;"/> > + <radio id="edge" label="&importFromEdge.label;" accesskey="&importFromEdge.accesskey;"/> I think these get dynamically re-ordered based on the order in the migratorKeysOrdered(?) array but can you double-check that. Just in case and for consistency, can you please put Edge before IE for the same reason as my comment on migratorKeysOrdered?
Comment 12•9 years ago
|
||
The follow-up patch that landed included changes to browser/themes/windows/downloads/indicator.css that appear unintentional. Can you back out those changes or add a note in this bug why they were necessary?
Flags: needinfo?(gijskruitbosch+bugs)
Assignee | ||
Comment 13•9 years ago
|
||
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #12) > The follow-up patch that landed included changes to > browser/themes/windows/downloads/indicator.css that appear unintentional. > Can you back out those changes or add a note in this bug why they were > necessary? Ugh. Sorry. remote: https://hg.mozilla.org/integration/fx-team/rev/404d17fdf3b2
Flags: needinfo?(gijskruitbosch+bugs)
https://hg.mozilla.org/mozilla-central/rev/a8ef04862821 https://hg.mozilla.org/mozilla-central/rev/7308129e3aca https://hg.mozilla.org/mozilla-central/rev/4e883591bb5d
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox43:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
Reporter | ||
Updated•9 years ago
|
Priority: -- → P2
Assignee | ||
Comment 17•9 years ago
|
||
Florin, how do I get this prioritized for verification? I'd like to uplift this, but I'd like to make sure I'm not regressing anything in terms of IE favorites/bookmarks migration.
Flags: needinfo?(florin.mezei)
Comment 18•9 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #17) > Florin, how do I get this prioritized for verification? I'd like to uplift > this, but I'd like to make sure I'm not regressing anything in terms of IE > favorites/bookmarks migration. Just a needinfo on me is enough. Keeping it on to verify this as soon as we get the time.
Comment 19•9 years ago
|
||
I don't see Microsoft Edge (bug 1163644) in the latest Nightly (build ID: 20150818030209) importer. I've tried on two machines running Windows 10 64-bit. Importing from IE seems to work only for the Menu bookmarks, a "From Internet Explorer" folder is created and the bookmarks are properly imported. The Toolbar Bookmarks are *not* imported, the "From Internet Explorer" folder is created, but it's empty.
Flags: needinfo?(florin.mezei)
Assignee | ||
Comment 20•9 years ago
|
||
(In reply to Cornel Ionce [QA] from comment #19) > I don't see Microsoft Edge (bug 1163644) in the latest Nightly (build ID: > 20150818030209) importer. > I've tried on two machines running Windows 10 64-bit. Do they actually have bookmarks/favorites stored in Edge? The migrator will only show up if there's anything to import. > Importing from IE seems to work only for the Menu bookmarks, a "From > Internet Explorer" folder is created and the bookmarks are properly imported. > The Toolbar Bookmarks are *not* imported, the "From Internet Explorer" > folder is created, but it's empty. Please can you file a separate bug for that, and let me know what the folder for the toolbar bookmarks is called on those machines? Should just be "Links", but maybe this has changed since that migrator was written?
Flags: needinfo?(cornel.ionce)
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(cornel.ionce)
Assignee | ||
Comment 21•9 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #20) > (In reply to Cornel Ionce [QA] from comment #19) > > Importing from IE seems to work only for the Menu bookmarks, a "From > > Internet Explorer" folder is created and the bookmarks are properly imported. > > The Toolbar Bookmarks are *not* imported, the "From Internet Explorer" > > folder is created, but it's empty. > > Please can you file a separate bug for that, and let me know what the folder > for the toolbar bookmarks is called on those machines? Should just be > "Links", but maybe this has changed since that migrator was written? Actually, still interested in this, which shouldn't be affected by bug 1196311.
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(cornel.ionce)
Assignee | ||
Comment 23•9 years ago
|
||
Cornel, did you have a chance to verify the Edge migration here?
Flags: needinfo?(cornel.ionce)
Comment 24•9 years ago
|
||
I've tested the Edge migration and the bookmarks/favorites are properly imported, being the only option that can be imported for now: http://i.imgur.com/9Ava3Ee.png The thumbnails of the imported favorites are not displayed until the user visits them. The bookmarks from the toolbar are sent into a "From Microsoft Edge" folder while the ones from the bookmarks menu are imported into "From Microsoft Edge" - "Edge" folders: http://i.imgur.com/FortKdX.png Is this the desired behavior? I think a single "From Microsoft Edge" folder is enough for them too.
Flags: needinfo?(cornel.ionce) → needinfo?(gijskruitbosch+bugs)
Assignee | ||
Comment 25•9 years ago
|
||
(In reply to Cornel Ionce [QA] from comment #24) > I've tested the Edge migration and the bookmarks/favorites are properly > imported, being the only option that can be imported for now: > http://i.imgur.com/9Ava3Ee.png Right. > The thumbnails of the imported favorites are not displayed until the user > visits them. Yes, see also bug 718220. > The bookmarks from the toolbar are sent into a "From Microsoft Edge" folder > while the ones from the bookmarks menu are imported into "From Microsoft > Edge" - "Edge" folders: http://i.imgur.com/FortKdX.png > Is this the desired behavior? I think a single "From Microsoft Edge" folder > is enough for them too. I don't see this on my machine. Can you file a bug and include your windows and edge version, and ensure that your bookmarks aren't themselves in a folder called Edge? :-)
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(cornel.ionce)
Assignee | ||
Comment 26•9 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #25) > and ensure that your bookmarks aren't themselves in a > folder called Edge? :-) ... in edge, that is? :-) The bookmarks migration will import the folder structure as it exists in the Favorites folder that Edge uses.
Comment 27•9 years ago
|
||
My bad, you were right. The favorites contained an "Edge" folder. I've retested with several folders containing bookmarks and bookmarks saved without a folder. The entire structure was properly imported. I've tested with Windows 10 Insider build 10525 and Edge 20.10525.0.0
Flags: needinfo?(cornel.ionce)
Assignee | ||
Comment 28•9 years ago
|
||
(In reply to Cornel Ionce [QA] from comment #27) > My bad, you were right. The favorites contained an "Edge" folder. > I've retested with several folders containing bookmarks and bookmarks saved > without a folder. The entire structure was properly imported. > > I've tested with Windows 10 Insider build 10525 and Edge 20.10525.0.0 Perfect, thanks! Let's call this verified, then.
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Assignee | ||
Comment 29•9 years ago
|
||
Approval Request Comment [Feature/regressing bug #]: Start doing migration of user data from Edge [User impact if declined]: It's not possible to migrate data out of Edge [Describe test coverage new/current, TreeHerder]: there is some basic test coverage that (for now, with no win10 machines on treeherder) will only check that we don't expose the migrator on older versions of Windows. Once win10 comes online it'll check that that is working. There are also pre-existing tests for the IE favorites migration on which this is based. [Risks and why]: very low. The impact should be restricted to Edge migration. In principle this patch moved some code used for IE migration. Bug 1197112 was reported when testing this, though it isn't clear if that is a regression from this bug or not (and it doesn't reproduce everywhere). [String/UUID change made/needed]: Nope
Attachment #8654091 -
Flags: review+
Attachment #8654091 -
Flags: approval-mozilla-beta?
Attachment #8654091 -
Flags: approval-mozilla-aurora?
Comment 30•9 years ago
|
||
Comment on attachment 8654091 [details] [diff] [review] Patch for aurora uplift Verified patch, important feature, taking it to aurora. Ritu will make the call for 42.
Attachment #8654091 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 31•9 years ago
|
||
Comment on attachment 8654091 [details] [diff] [review] Patch for aurora uplift I just realized that beta will need hardcoded strings, and the patch has conflicts there because we didn't support canary/chromium migration. The strings were prelanded for 42 and applies there, so neither is an issue for Aurora. I'll try to get a beta patch ready and put up but I don't know that I'll manage it still today (and I'm on PTO next week).
Attachment #8654091 -
Attachment description: Patch for uplift → Patch for aurora uplift
Attachment #8654091 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 32•9 years ago
|
||
Approval Request Comment: see comment 29 Built and tested the hardcoded strings on beta. :-)
Attachment #8654205 -
Flags: review+
Attachment #8654205 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 33•9 years ago
|
||
(In reply to Gijs Kruitbosch (PTO until Sep 6) from comment #32) > Created attachment 8654205 [details] [diff] [review] > Patch for beta > > Approval Request Comment: see comment 29 > > Built and tested the hardcoded strings on beta. :-) Actually, considering the strings, let me update that part of the approval request to be thorough: [String/UUID change made/needed]: There are no new strings in the patch. The patch would normally have needed new strings. It would have needed those for two things: 1) the name of the browser we're importing from 2) the names of the things we're importing (for this patch: "Favorites", for some of the other IE import work, potentially things like "Cookies" or "Passwords"). I added a small bit of code to use the strings from IE for (2) (because the names should be identical, and to hardcode the name of the browser to use "Microsoft Edge". The name of the browser doesn't, as far as we know, change between different Windows locales, so I believe this is OK and isn't an issue. Using the IE names for things like bookmarks and cookies and so on, considering they are all standalone nouns without being in a sentence or something like that, should in principle work everywhere unless the translations end up relating to the browser name because of language differences with English. Either way, I think given the choice between not having the feature anywhere, and having it but having the potential for imperfect translations for the names of the resources to import, I believe we should pick the latter.
Comment 34•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/98983a6fd50d
Flags: in-testsuite+
Gijs, should we file a separate bug for new strings that may be needed instead of the string from IE that we used? We can fix that in Nightly and let it ride the trains.
Comment on attachment 8654205 [details] [diff] [review] Patch for beta This patch stabilized on Aurora for the last 2 days, seems safe to uplift to Beta. Also this patch will improve the end-user experience of Edge -> Firefox migration so it definitely meets the Beta41 uplift criteria.
Attachment #8654205 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 37•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/0eee84804240
status-firefox41:
--- → fixed
Comment 38•9 years ago
|
||
(In reply to Ritu Kothari (:ritu) from comment #35) > Gijs, should we file a separate bug for new strings that may be needed > instead of the string from IE that we used? We can fix that in Nightly and > let it ride the trains. We don't need a follow-up for new strings. The strings exist on mozilla-central, they just weren't available on the beta branch.
Comment 39•9 years ago
|
||
I'm also confirming this fix for the latest Aurora (build ID: 20150831004018) and Firefox 41 beta 6 (build ID: 20150831172306). Tested on a computer with Windows 1- 32-bit and a MS Pro 2 device running Windows 10 64-bit.
Blocks: 1200598
You need to log in
before you can comment on or make changes to this bug.
Description
•