Closed
Bug 11472
Opened 25 years ago
Closed 25 years ago
Delete and Rename changes do not show up immediately in Profile Manager
Categories
(Core Graveyard :: Profile: BackEnd, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M10
People
(Reporter: jay, Assigned: vidur)
Details
If you rename or delete a profile in the Profile Manager dialog, the changes do
not show up immediately.
Steps:
1. Get to the Profile Manager (apprunner -ProfileManager)
2. Create a new profile and click rename
3. After filling in the new name, click OK
4. Normally, the new name will show up in the list of profiles, but it is still
the same
5. Start and quit apprunner
6. If you start again with step one, the new name will show up when you launch
the Profile Manager the second time
NOTE: Trying to delete a profile does the same thing. Initially when you
confirm the delete, the profile will remain in the list of profiles...if you
quit and launch the Profile Manager again, the profile is gone. The Main dialog
for the profile manager does not seem to refresh after the changes have been
made, so the list is not updated immediately.
Builds Tested:
Win98 build 1999080908
Linux RH6 build 1999080908
Updated•25 years ago
|
Assignee: selmer → gayatrib
Priority: P3 → P1
Target Milestone: M9
Comment 1•25 years ago
|
||
Gayatri, either we're not forcing the reload, or they've changed something with
replacing pages again...
This should work now. The problem was this.location used to return the complete
url, which I used to load the page. This is failing now. For now, I fixed the
bug by providing the complete url (resource:/<file path and name>) instead of
using location.this. So you should not face this problem with the next build.
However, reassigning the bug to vidur as I was wondering if location.this is
supposed to continue working...?
Reporter | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 3•25 years ago
|
||
Resolving Fixed, as this is no longer a problem with 1999081008 builds...please
reopen if necessary.
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 4•25 years ago
|
||
Jay, please let Vidur decide if this should be closed. As it stands now,
Gayatri has checked in a workaround that avoids the bug. She did not check in a
fix to Vidur's code. If Vidur thinks this new behavior is correct, then he can
close the bug. If you just want it off the M9 radar, the TFV can be changed
since we have the workaround.
Clearing Fixed resolution due to reopen.
Moving to M10...
Jay, please put text for a Release Note workaround into M9 Release Note Bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=11352
Comment 6•25 years ago
|
||
I got the reference for the release notes, but I'm not sure what I should write
about this. It sounds like people using the M9 build won't see this problem, due
to the workaround. What, if anything, do they need to know about it?
Assignee | ||
Comment 7•25 years ago
|
||
Fixed with the change to fix 11577. window.location was temporarily broken.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 8•25 years ago
|
||
aug16 builds ok
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•