49406 - Unable to switch to the Account Wizard window

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Ninoschka Baca]

Build 2000-08-16-08M18: NT4
and Build ID: 2000080712 on Paul Jaros's win95b system.

Overview: Unable to switch to the Account Wizard

These steps are pasted from bug# 23122 and written by Paul Jaros:

"I'm using M17.... Okay, here is how you reproduce it:
- Install M17 (Build ID: 2000080712)
- start Mozilla
- start the mail client
  Now the Mail-Wizard will open
- click on the Mozilla browser in order to get the focus away form the wizard
- click on "Open Windows" and select: "Mail"

Now the Mail-client has focus _instead_ of the wizard. Now you can't click on
the wizard and you can't click on the mail-client. To get things working again,
you have to click another Window (like Mozilla) and select the wizard with the
mouse."

Additional Information:
- Mac, can't reproduce because when the Account Wizard has focus no other
windows (including Navigator) can be accessed.
- Linux, can't reproduce because I can switch to the Navigator window but
elements of the window do not respond. For instance selecting the File menu does
nothing, selecting "Open Windows" from the taskbar also does nothing. When
Account Wizard is closed then I can access Navigator's File menu and the "Open
Window" taskbar item.

Comment 1

[Alec Flett]

this is toolkit stuff, reassign to trudelle

Comment 2

[Peter Trudelle]

Isn't this a very unlikely scenario?  Don't you get the wizard only if you have
no mail accounts?  If so, why would you go out of your way to open mail while
adding your first account? Also, no crash/data loss/loss of function, and there
is a workaround. ->future

Comment 3

[Paul Jaros]

Okay, this is not a sever bug. Where I work we would call it a "should-do" bug
(where "must-do" bugs would be more sever ones and "could-do" bugs less sever
ones). Most users won't even notice it exists.
But what if the toolkit is reused in another project and then there wouln't be a
easy workaround as in this case?

Comment 4

[Peter Trudelle]

We are focussed on shipping this project, and can't afford to be distracted by
other hypothetical projects.  Our 'must fix' bugs are extremely severe indeed,
and typically affect most users in very common usage.  This bug doesn't seem to
qualify.

Comment 5

[Paul Jaros]

I can assure you that it's not my goal to distract you from anything.
I request to lower the priorty of this bug so it will be fixed as soon as the
higher prorites bugs are corrected, if you agree.

Comment 6

[Peter Trudelle]

I'm sure your goals are quite worthy, and appreciate your comments, but I feel
the need to hear of a more common scenario, or a worse outcome, in the Netscapce
6 product in order to even consider fixing this bug for Netscape 6. Note that
'future' could be very soon after Netscape 6 ships, possibly even before it if
there is a branch.

Comment 7

[Paul Jaros]

Well, a bug is a bug is a bug, no matter what scenario. I can understand that
you have no time to fix it before Netscape 6. I'm sure, you've got all sorts of
deadlines.
But a project is different. A project isn't finished until there is no one using
it anymore. Until then it will grow, sources will be changed and there will be
bugs awaiting their fix. I think most commercial (and free-sourced) projects are
shipped with lots of known unfixed bugs. Having know bugs is not a shame.
What is the purpose of a bug-database if bugs get burried on deadline
considerations?
I don't care if you don't fix the bug for Netscape 6. Will your boss kill you or
something if Netscape 6 isn't bug-free?
And no, I don't consider the non-common scenario and the non-fatal outcome a
argument to close the bug. Well, a bug is a bug is a bug, no matter what
scenario. I can understand that you have no time to fix it before Netscape 6.
I'm sure, you've got all sorts of deadlines.
But a project is different. A project isn't finished until there is no one using
it anymore. Until then it will grow, sources will be changed and there will be
bugs awaiting their fix. I think most commercial (and free-sourced) projects are
shipped with lots of known unfixed bugs. Having know bugs is not a shame.
What is the purpose of a bug-database if bugs get burried on deadline
considerations?
I don't care if you don't fix the bug for Netscape 6. Will your boss kill you or
something if Netscape 6 isn't bug-free?
And no, I don't consider the non-common scenario and the non-fatal outcome a
argument to close the bug. 

Comment 8

[Peter Trudelle]

I'm not closing the bug, merely delaying it until after N6. My team won't work
on it until then, although we'll consider taking a patch. (adding helpwanted
keyword).  Until then, we want it off the radar so we can focus on the bugs that
we do need to fix.  And no, my boss wouldn't harm a fly.

Comment 9

[David Hyatt]

Fixed.

Comment 10

[David Hyatt]

Oops! Wrong bug.

Comment 11

[Peter Trudelle]

->danm. Is this a window/modality issue, or should XPApps just prevent choosing
mail when account wizard is up?

Comment 12

[Thomas]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714
I followed the steps explaining the error
When I switch back (step 5), the wizzard still has focus

worksforme

Comment 13

[Dan M]

Me too, using my 20040609 build. None of the menu commands to open the mail
window (or bring it forward in this case) seem to do anything at all while the
account wizard is open. That itself is something of a bug, but it sure fixes
this one. S'pose I'll close it, then.