Closed Bug 378358 Opened 17 years ago Closed 16 years ago

On startup, focus/delay issue with Profile Manager

Categories

(Core :: General, defect)

x86
Windows 2000
defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla1.9beta4

People

(Reporter: sgautherie, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [Steps: see comment 0 and 4])

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414] (release) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.12pre) Gecko/20070322 SeaMonkey/1.0.8] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/20070421 SeaMonkey/1.1.1] (nightly) (W2Ksp4)

No bug, as far as my simple tests can tell.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070421 SeaMonkey/1.5a] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/2007042104 Minefield/3.0a4pre] (nightly) (W2Ksp4)

I file this bug under SeaMonkey, to get the "Profile: Manager" component;
but this happens with Firefox too, but I don't know which Core component to use
...
I believe this bug is more related to window focusing than to Profile Manager itself.

1. I start FF/SM by double clicking on Windows desktop icon.
2. Profile Manager shows up.
3. At this step, quite often [= not always], I get the following wrong behaviour(s):

3-mouse. If I click the "Start" button (or a profile !?),
the window looses its focus/highlight:
I need to click again to get the focus back.

3-keyboard. (or) If I press Enter,
the P.M. window goes away,
but there is a "7" seconds delay before the FF/SM browser window appears.

I think this is a regression that happened some (weeks/)months ago !
Perharps when some window focus handling code was modified ?
I don't remember the bug number(s) right now.
(In reply to comment #0)
> 3-keyboard. (or) If I press Enter,
> the P.M. window goes away,
> but there is a "7" seconds delay before the FF/SM browser window appears.

During that delay:
no (noticeable) cpu activity, windows display +/- frozen.
(In reply to comment #0)
> 3-mouse. If I click the "Start" button (or a profile !?),
> the window looses its focus/highlight:
> I need to click again to get the focus back.
> 
> 3-keyboard. (or) If I press Enter,
> the P.M. window goes away,
> but there is a "7" seconds delay before the FF/SM browser window appears.

When the keyboard delay case happens,
the next window to get the focus, whether a dialog or the browser window,
will have the mouse case bug: first click looses focus/highlight...
Sorry, but I can't reproduce this on my suiterunner build; might that be
a) because I'm using Windows XP b) because it's a debug build?
Not too sure about everything I wrote,
but I seem to have found a reproducible case for the startup _delay_:


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/20070519 SeaMonkey/1.1.2] (nightly) (W2Ksp4)

No bug, with the following steps.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/2007051804 Minefield/3.0a5pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/2007052105 SeaMonkey/1.5a] (suiterunner, tinderbox-builds) (W2Ksp4)

1. Move the mouse pointer away from where the profile dialog will show up.
2. Without moving the mouse anymore, press Enter to select the suggested profile.
2r. delay !

If, at step 2, I move the mouse, preferably hover the dialog, then press Enter, I don't get the delay.

Just a wild guess: I wonder if that could be related to bug 326273 somehow ?

NB: Same bug if I start sr with a simple 'seamonkey' from command line.

*(Product) M.A.S. -> FireFox, to get more visibility.
Component: Profile: Manager → General
Product: Mozilla Application Suite → Firefox
QA Contact: profile-manager → general
Target Milestone: --- → Firefox 3
Flags: blocking-firefox3?
Whiteboard: [Steps: see comment 0 and 4]
Regressed between
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060510 Minefield/3.0a1] (2006-05-10-02-trunk) (W2Ksp4)
and
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060510 Minefield/3.0a1] (2006-05-10-13-trunk) (W2Ksp4)

<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-10+02&maxdate=2006-05-10+14&cvsroot=%2Fcvsroot>
Luky me, that bug 326273 again !
Profile manager isn't a supported feature of the product, so we won't block on this, but we'd love to see this happen.
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [Steps: see comment 0 and 4] → [Steps: see comment 0 and 4][wanted-firefox3]
Flags: wanted-firefox3+
Whiteboard: [Steps: see comment 0 and 4][wanted-firefox3] → [Steps: see comment 0 and 4]
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022604 Minefield/3.0b4pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022601 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Bug 389931 patch fixed this bug:
(See bug 389931 comment 59.)
Blocks: 381699
Depends on: 389931
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Product: Firefox → Core
QA Contact: general → general
Target Milestone: Firefox 3 → mozilla1.9beta4
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.