Awkward User Experience if more than 1 observer calls nsIProfileChangeStatus::VetoChange

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
16 years ago
3 years ago

People

(Reporter: ccarlen, Assigned: ccarlen)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

16 years ago
On a profile switch, the appshell service enumerates all open windows. If the
document to be closed pops up a Save/Don't Save/Cancel dialog, and the user
chooses "Cancel," the profile switch is stopped.
  Currently, this is only done by one observer. If we add another
"profile-approve-change" observer (see bug 202629), we could end up having more
than one observer put up a dialog which offered to cancel the operation. This is
wrong - the 1st cancel should cancel the operation.
  The problem is that the profile mgr uses
nsIObserverService::notifyObservers("profile-approve-change", ...). If one of
the observers calls VetoChange(), the enumeration will still continue, and the
next observer may put up another dialog.
  Here's the fix: Instead, the profile mgr should use
nsIObserverService::enumerateObservers("profile-approve-change", ...). Then, if
it's doing the enumeration, it could check for a veto after each observer and
stop enumerating on the 1st veto.
QA Contact: agracebush → profile-manager-backend

Comment 1

3 years ago
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.