With menu open and click on taskbar/start button, titlebar stays dimmed/inactive/gray-out when window is focused

NEW
Unassigned

Status

()

P3
normal
19 years ago
10 years ago

People

(Reporter: bugzilla, Unassigned)

Tracking

({platform-parity})

Trunk
Future
x86
Windows 98
platform-parity
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Guessing here on the component, pls reassign as necessary [also feel free, to 
resummarize, I had NO idea how to describe this :) ]

Steps to Reproduce:

(1) Start Mozilla and make sure you have at least one other thing on the taskbar
(2) Click any of the pulldown menus (i.e. Bookmarks)
(3) Now hold the mouse down onto something else on the taskbar, but then let it 
up somewhere else (not over the taskbar item).  When done correctly, this 
causes the Mozilla window to lose focus (as designated by the inactive 
titlebar), however focus will not switch to the other taskbar item.
(4) Now attempt to reclick back anywhere within the Mozilla window.  While 
everything will work normally, no clicks on anything inside the browser will 
cause focus to be restored to the window (or perhaps focus *is* being restored, 
but the titlebar is remaining inactive).  As of now, the only way I've found to 
restore true focus to the window is either to switch applications and then 
return to Moz, or resize/maximize/minimize/restore.

Let me know if you have trouble repro'ing this, I'll try to make the steps more 
clear.

This could very well be pp to win32 since its taskbar functions differently 
than other OS's.

Also...pretty sure this has nothing to do with XPMenus, but I'll let someone 
who knows about this reassign.  Event handling, perhaps?  cc'ing joki
(Reporter)

Comment 1

19 years ago
btw, you may want to write down/print/remember the reproducing directions, 
since you can't switch to the window to find out once you begin to repro 
(unless, of course, you're looking at the instructions in the window you're 
testing it on).
i can't dupe this. i need a better description.
(Reporter)

Comment 3

19 years ago
Hmm..I can still repro on 2000050308.  Are you sure you're doing step 3 right? 
It's a little confusing.

Try this:

(1) Open Windows Notepad
(2) Open Mozilla
(3) Click "Bookmarks" in the menubar
(4) While the Mozilla window has the focus, left mouse-down on the "Notepad" 
item in the taskbar.  However, instead of releasing the mousebutton over the 
item, which would cause focus to switch to Notepad, release it elsewhere on the 
screen (i.e over the system clock).  Now, the bookmarks menu should have 
disappeared and the inactive titlebar (gray by default) of Mozilla should 
indicate that the window does not have the focus - this is all standard win32 
behavior up until now.
(5) Now try to click anywhere within the Mozilla window.  This *should* 
restore "focus" to the window (indicated by an active titlebar, blue by 
default).  Instead, while everything within the window works normally, the 
titlebar doesn't regain the "active" (blue by default) status; it 
stays "inactive" (gray by default), which is confusing to the user.

The titlebar will again indicate focus upon resizing the window, switching 
applications and switching back, or if another modal window returns focus to it 
(i.e. opening then closing the prefs window)

Hopes this helps a bit?

One more question - am I absolutely *insane* or did there not used to be a 
comment here, from dark@c2i.net I believe or perhaps from someone else, that 
this could also be repro'd on Linux?  I could've sworn...
this works fine on NT. can anyone verify if it's 98 only?

Comment 5

19 years ago
i cannot reproduce on win98 and 2000050408 mozilla build.

reporter - do other programes shwo this behaviour as well?
(Reporter)

Comment 6

19 years ago
All other programs correctly activate the titlebar again when clicking within 
them. Mozilla doesn't.  Are you sure you *printed* the instructions and 
followed them _exactly_?

Don't mark this as wfm, it's reproducable on two different computers in my 
house and two friends' computers, all running win98se
(Reporter)

Comment 7

19 years ago
Still seeing this with 2000050608 win98.

I've also found an easier (and more likely to occur) way to reproduce it:

(1) Click Go to drop down the Go menu
(2) With the Go menu still dropped, click the Start button
(3) Now attempt to reactivate the Mozilla titlebar by clicking anywhere within 
the window, or even on its item in the taskbar.

Expected Results: like every other win32 app, focus is restored to the window 
in which you're clicking.

Actual Results: everything works within the mozilla window, but the titlebar 
does not reactivate until you resize the app, open/close a modal dialog (to 
restore focus), or switch applications normally.

This also occurs with XP dropdowns:

(1) Go to File | Open Web Location...
(2) Click the dropdown (next to Open in which window)
(3) Click Start button

Results are the same [focus now can't be restored back to the Open Web Location 
window]

Resummarizing for clarity.
Summary: Click menu, temp. lose focus = can't restore focus until repainting window → Drop menu, Click Start: titlebar won't reactivate in usual manner
ok, i see this on 98, works fine on NT. not sure where the problem is. since it 
also has to do with dialogs, i'm tempted to say this isn't a menu bug. 

oh danny boy?
Assignee: pinkerton → danm

Updated

19 years ago
Target Milestone: --- → M18

Comment 9

19 years ago
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21

Comment 10

19 years ago
This is probably a general popup problem, I was able to reproduce it with
comboboxes as well.
(Tested build 2000-05-26-20 on Win98SE)
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.
QA Contact: sairuh → jrgm

Comment 12

19 years ago
With 2000070608 win32 build: occurs on win95, does not occur on win2k(nt5.0)

(Per request: no, this is a very minor bug -- no loss of functionality, just
a small loss of user feedback).
(Reporter)

Comment 13

19 years ago
Yup, still occurring with 9x, but not with NT or 2K...which is somewhat strange...

And I agree that there's absolutely no loss of functionality here (but who
requested that?)
Keywords: pp

Comment 14

19 years ago
I was asked in email whether this should make the beta2 train.
(Reporter)

Comment 15

19 years ago
must be something that the NS OS does automatically (wrt focus) but 9x doesn't. 
odd...don't even know where to begin looking for this problem

Comment 16

19 years ago
Oy, nice bug. I don't have 98 installed, so this might be a little tricky.

Are you running a debug build by any chance?
(Reporter)

Comment 17

19 years ago
nope -- normal optimized nightly.

(btw, I meant 'NT OS' before, not 'NS OS'...of course...we don't make operating 
systems [yet] )

Comment 18

18 years ago
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: M21 → Future

Comment 19

18 years ago
Bug 31146 shows a similar problem on linux.

Comment 20

17 years ago
*** Bug 103475 has been marked as a duplicate of this bug. ***

Comment 21

16 years ago
A different way to reproduce the bug:
1. Open any menu or drop down list
2. With menu/list sitll open, click on empty area of the taskbar
3. Click on the window again. Everything works normally except the
   titlebar stays dimmed
Summary: Drop menu, Click Start: titlebar won't reactivate in usual manner → With menu open and click on taskbar/start button, titlebar stays dimmed/inactive/gray-out when window is focused

Updated

14 years ago
Assignee: danm.moz → nobody

Comment 22

13 years ago
*** Bug 310151 has been marked as a duplicate of this bug. ***

Comment 23

13 years ago
I found this bug in windows 98se. Sorry for reporting the dupe. Didn't know it
was already reported.
QA Contact: jrgmorrison → xptoolkit.menus

Updated

10 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.