Closed Bug 695304 Opened 8 years ago Closed 8 years ago
On the latest Nightly - Bookmarks are not imported from IE
Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 Bookmarks are not imported anymore from IE8 on the latest Nightly through Show All Bookmarks -> Import and Backup -> Import Data from Another Browser. Import can be done on the latest release (Firefox 7.0.1) and on the latest Aurora build: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Mozilla/5.0 (Windows NT 5.1; rv:9.0a2) Gecko/20111017 Firefox/9.0a2 This could be related to Bug 591884. Reproducible: always Steps to reproduce: 1. Start IE and add some bookmarks. 2. Start the latest Nightly 3. Go to Bookmarks menu -> Show All Bookmarks -> Import and Backup -> Import Data from Another Browser. 4. In the import dialog select Microsoft Internet Explorer -> Favorites Expected results: After going through the Import migration dialog the folder "From Internet Explorer" should be present under the location Bookmarks Menu. Actual results: The folder "From Internet Explorer" containing the favorites from IE8 does not exist in the Library window. *Note: Bookmarks were also not imported from IE9 using Windows 7: Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111017 Firefox/10.0a1
Regression window(cached m-c hourly), Works: http://hg.mozilla.org/mozilla-central/rev/cb4b93331e4f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929030852 Fails: http://hg.mozilla.org/mozilla-central/rev/e7854b4d29ba Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929012133 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb4b93331e4f&tochange=e7854b4d29ba Regression window(cached m-i hourly), Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/c5d8bfe7a014 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110928 Firefox/10.0a1 ID:20110928214028 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/e7854b4d29ba Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110928 Firefox/10.0a1 ID:20110928232235 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c5d8bfe7a014&tochange=e7854b4d29ba Suspected bug: e7854b4d29ba Michael Wu — Bug 675553 - Switch from PRBool to bool on a CLOSED TREE , r=bsmedberg,khuey,bz,cjones
I've pushed a fix to try. It will post here when the build is complete. Lemme know if that build fixes the issue. Thanks!
Assignee: nobody → mwu
Try run for 712729e3b4f4 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=712729e3b4f4 Results (out of 1 total builds): exception: 1 Builds available at http://firstname.lastname@example.org
Interesting, the bug was introduced by me as a misuse of PRBool quite some time ago, covered by the fact it was an int, and now it is visible due to switch to bool. Good catch Michael. r=me on the patch you have on try, that's clearly broken, regardless being the reason for this failure (I'm confident about that, but confirmation would be much welcome)
Also, I wonder if you may modify some of your static analysis scripts to catch this specific kind of failures, there may be others hiding in the wild.
(In reply to Marco Bonardo [:mak] from comment #5) > Also, I wonder if you may modify some of your static analysis scripts to > catch this specific kind of failures, there may be others hiding in the wild. The static analysis I have does catch these issues, but I couldn't figure out how to run clang on Windows. So, OSX and Linux are mostly well checked, but we've hit a couple Windows specific issues. However, MSVC does put out warnings for situations like this (AFAIK).
(In reply to Michael Wu [:mwu] from comment #6) > However, MSVC does put out > warnings for situations like this (AFAIK). I just tried (MSVC10) to force recompilation in migration, but I don't see any kind of warning.
Build tested, import succeeds.
Target Milestone: --- → Firefox 10
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.