Closed Bug 31146 Opened 24 years ago Closed 24 years ago

Mozilla titlebar loses focus upon menu use

Categories

(Core :: XUL, defect, P4)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla0.8

People

(Reporter: snickell, Assigned: blizzard)

References

Details

(Keywords: platform-parity, polish, Whiteboard: patch, review)

Attachments

(2 files)

As one changes between main menus, or follows a menu, the Mozilla
titlebar repeatedly loses and gains focus, creating a very disturbing
(and extremely annoying) flashing. I think this actually contributes
in a major way to my perceptions of Moz's XP interface being clunky.
what window mananger are you using? i don't see this at all with kde.
h'm, i don't see this either using today's build [comm opt, 2000.03.09.09] on
linux (redhat 6.0, 2.2.12-20 kernel) using the Enlightenment wm (plus the Pixmap
theme) on gnome.

what build did you see this with? and could you pls provide specific steps for
this? what i did is just click on the File menu then mouseover the rest of the
menubar to bring up the other menus. also tried single-clicking each menu, one
at a time --didn't see the titlebar lose focus either way.
Whiteboard: [about to mark worksforme]
I haven't been able to produce this with Enlightenment. The behavior is

observed in Sawmill (which will probably be the "default" Gnome WM), which

uses sloppy pointer focus by default. The easiest example is to click on

the "Bookmarks" menu. Moving the cursor to "expand" any of the submenus

causes the titlebar to flash in and out of focus. I'll try this with other

Window managers later, but I haven't observed strange focus behavior in

Sawmill with any other app :-(

Sorry...forgot to mention that I'm using the latest nightly build.
pavlov, you use sawmill, d'you see this?

i tried the steps involving the Bookmarks menu, and still unable to repro...
ah, i use click-to-focus. could that be part of why i can't see this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
yeah.  i was meaning to file this bug.  i think it has something to dowith us
not setting the popup windows as transient of their parent window....  wwwthis
is probably my bug.
good!
Assignee: pinkerton → pavlov
accepting for M15
Status: NEW → ASSIGNED
Whiteboard: [about to mark worksforme]
Target Milestone: M15
I see this with Sawmill, too. Depending on the status of focus - it's a bit iffy

- the menu itself loses focus, and partially disappears - but is still selected.

There are strange focus interactions happening here...

Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
I'm not seeing this in the latest builds.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Damn. Its still there. I just had focus changed.

moving to m17. would take a fix, but might not hold PR2.
Target Milestone: M16 → M17
*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
*** Bug 45033 has been marked as a duplicate of this bug. ***
Target Milestone: M17 → Future
I would like to fix this, but i'm not really sure how.
*** Bug 48002 has been marked as a duplicate of this bug. ***
I'm seeing this bug as well (sawmill, sloppy focus, latest build). Mozilla
/correctly/ disallows focus of its own window or any other app without the menu
being closed, but /incorrectly/ communicates the focus state to the window
manager. In other words, the window manager thinks the app is defocused when it
isn't.

This could relate to slow menu performance in general (perhaps communication
with the window manager or X server is happening and simply shouldn't be?), so
nominating nsbeta3. This feels like it should be an easy fix...

Answering pavlov's helpwanted by reassignment :)
Assignee: pavlov → dr
Status: REOPENED → NEW
Keywords: helpwantednsbeta3
Annoying, yes, but I don't think it fits the profile, nor is this one of our top
perf problems.  nsbeta3-/helpwanted, we'll have to live with it unless someone
else contributes a fix.
Keywords: helpwanted
Whiteboard: [nsbeta3-]
Status: NEW → ASSIGNED
triaging for post-rtm
Severity: normal → minor
Keywords: 4xp, correctnesspolish
Priority: P3 → P4
Target Milestone: Future → mozilla1.0
-> pavlov, who convinced me that this is harder love than i can handle. it's
unlikely that this is a priority for embedding, btw, so future.
Assignee: dr → pavlov
Severity: minor → normal
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → Future
we should really fix this
Status: NEW → ASSIGNED
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Target Milestone: Future → mozilla0.9
This bug has an additional 'feature'. I can't switch desktops when a menu is
expanded.  (sawmill/sawfish, click-focus, helix-code gnome, Mozilla build:
2001012006)
-> blizzard@mozilla.org
Target Milestone: mozilla0.9 → mozilla0.8
Attached patch patchSplinter Review
-> blizzard@mozilla.org (really!)
Assignee: pavlov → blizzard
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Keywords: helpwanted
Whiteboard: patch, review
Attached patch patch 2Splinter Review
This patch fixes the problem with override redirect ( popup ) windows getting
focus when a grab is done on them.  If you put a keyboard grab directly on the
popup window the window manager will take focus from the parent transient.

Also, this patch keeps track of a popup window's transient parent window so you
can use it later for a grab.
r=pavlov
cool! sr=alecf
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: