Closed Bug 327303 Opened 19 years ago Closed 19 years ago

Accept languages empties when IE profile migration is selected.(when with --enable-official-branding)

Categories

(Firefox :: Migration, defect, P1)

Product:
Firefox
Component:
Migration
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 2 alpha1

People

(Reporter: masayuki, Assigned: masayuki)

References

Details

(5 keywords, Whiteboard: [tjp-dl])

Attachments

(1 file, 1 obsolete file)

Patch rv2.0
3.51 KB, patch
mconnor
: review+
mconnor
: approval-branch-1.8.1+
dveditz
: approval1.8.0.2+
Details | Diff | Splinter Review 
This is separated from bug 312391.
The bug is still reproduced if the build is using official branding.
Attached patch Patch rv1.0 (obsolete) — — Splinter Review 
This fixes this bug and bug 327306.
So, this is regression of bug 313529.
But I don't know this patch is correct.
# Why you call |resetPrefs| on here?
Attachment #212003 - Flags: review?(mconnor)
Attachment #212003 - Flags: approval-branch-1.8.1?(mconnor)
Blocks: 313529, 327306
Flags: blocking1.8.0.2?
Flags: blocking-firefox2?
Keywords: regression
Priority: -- → P1
Target Milestone: --- → Firefox 2 alpha1
Because if we're migrating from Netscape 6/7/Mozilla, we have user prefs loaded in memory from their prefs.js, and weird things happen (we only selectively import prefs for a reason, but its been a few months).

Really, we could do this conditionally if the import source is Mozilla, but this needs some solid testing.
(In reply to comment #2)
> Because if we're migrating from Netscape 6/7/Mozilla, we have user prefs loaded
> in memory from their prefs.js, and weird things happen (we only selectively
> import prefs for a reason, but its been a few months).

That's strange... If we have the problem, we should reset the prefs in |nsSeamonkeyProfileMigrator::Migrate| instead of here, right?
In theory, yes.  There was some weird race condition that I didn't have time to track down in the last-minute timeframe here.
Flags: blocking1.8.0.2? → blocking1.8.0.2+
Masayuki, can you test to ensure that Netscape/Mozilla home page/proxy settings migration still work with your patch?
Flags: blocking-firefox2? → blocking-firefox2+
Attached patch Patch rv2.0 — — Splinter Review 
O.K. Mike.
This fixes this problem and SeaMonkey's problem.
But we may have same problem (e.g., from NC4.x) yet...
http://lxr.mozilla.org/mozilla/ident?i=ReadUserPrefs
Assignee: nobody → masayuki
Attachment #212003 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #212236 - Flags: review?(mconnor)
Attachment #212236 - Flags: approval-branch-1.8.1?(mconnor)
Attachment #212003 - Flags: review?(mconnor)
Attachment #212003 - Flags: approval-branch-1.8.1?(mconnor)
Comment on attachment 212236 [details] [diff] [review]
Patch rv2.0

Ok.  We don't actually migrate the homepage from Netscape 4.x at present, not really planning to support that at any point.
Attachment #212236 - Flags: review?(mconnor)
Attachment #212236 - Flags: review+
Attachment #212236 - Flags: approval-branch-1.8.1?(mconnor)
Attachment #212236 - Flags: approval-branch-1.8.1+
checked-in to trunk and 1.8 branch.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Comment on attachment 212236 [details] [diff] [review]
Patch rv2.0

Let't go to 1.8.0.2.
Attachment #212236 - Flags: approval1.8.0.2?
Comment on attachment 212236 [details] [diff] [review]
Patch rv2.0

approved for 1.8.0 branch, a=dveditz
Attachment #212236 - Flags: approval1.8.0.2? → approval1.8.0.2+
checked-in to 1.8.0 branch.
Keywords: fixed1.8.0.2
Whiteboard: [tjp-dl]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: