Open
Bug 37540
Opened 24 years ago
Updated 2 years ago
With menu open and click on taskbar/start button, titlebar stays dimmed/inactive/gray-out when window is focused
Categories
(Core :: XUL, defect, P3)
Tracking
()
NEW
Future
People
(Reporter: bugzilla, Unassigned)
References
Details
(Keywords: platform-parity)
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•24 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).
Comment 2•24 years ago
|
||
i can't dupe this. i need a better description.
Reporter | ||
Comment 3•24 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...
Comment 4•24 years ago
|
||
this works fine on NT. can anyone verify if it's 98 only?
Comment 5•24 years ago
|
||
i cannot reproduce on win98 and 2000050408 mozilla build. reporter - do other programes shwo this behaviour as well?
Reporter | ||
Comment 6•24 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•24 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
Comment 8•24 years ago
|
||
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
Comment 9•24 years ago
|
||
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Comment 10•24 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)
Comment 11•24 years ago
|
||
*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•24 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•24 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•24 years ago
|
||
I was asked in email whether this should make the beta2 train.
Reporter | ||
Comment 15•24 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•24 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•24 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•24 years ago
|
||
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: M21 → Future
Comment 19•24 years ago
|
||
Bug 31146 shows a similar problem on linux.
Comment 20•23 years ago
|
||
*** Bug 103475 has been marked as a duplicate of this bug. ***
Comment 21•21 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
Comment 22•19 years ago
|
||
*** Bug 310151 has been marked as a duplicate of this bug. ***
Comment 23•19 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
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•