Closed Bug 29851 Opened 25 years ago Closed 24 years ago

clicking on an item in a context menu causes the window to de-activate for a split second (title bar)

Categories

(Core :: XUL, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: dean_tessman, Assigned: saari)

References

()

Details

(Whiteboard: [nsbeta3-])

Attachments

(3 files)

Right-click to open a context menu. Either left-click or right-click a context menu. The easiest one to click is a disabled item, such as Copy. You can click it repeated times without the menu dismissing. Expected Results: - action (if applicable) is performed - browser window owning context menu retains active state through duration of the click Actual Results: - action (if applicable) is performed - browser window owning context menu flashes inactive for a split second This only seems to happen with context menus. Popup menus off the main menu don't do this and neither do popups off the toolbar (eg. Bookmarks menu). Note: this is unrelated to the fix for bug 17159 as I could duplicate it with an M14 release, which is before that fix was implemented. ps. Mike, sorry about giving you another bug.
adding to saari's stress...
Assignee: pinkerton → saari
This isn't an overly important bug, so I'm changing the severity to trivial.
Severity: normal → trivial
Confirmed with the 2000-03-01-08-M15 nightly binary on WinNT 4.0, exactly as reported. The titlebar greys out momentarily as if a modal dialog had been activated for a split-second.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: clicking on an item in a context menu causes the window to de-activate for a split second → clicking on an item in a context menu causes the window to de-activate for a split second (title bar)
Sounds like popup windows are being created with the wrong OS flags.
Status: NEW → ASSIGNED
Target Milestone: M16
I think it has to do with the WS_POPUP for eWindowType_popup in StandardWindowCreate(). Popup windows can receive focus, and take it away from the parent when this happens. Not sure how to get around this... yet...
Shouldn't this solve this problem? Guess it's not working quite right. http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#641
Mass-moving all M16 non-feature bugs to M17, which we still consider to be part of beta2
Target Milestone: M16 → M17
Adding 'patch' keyword, something that I should have done back in March.
Keywords: patch
Doh, sorry, this got lost on the radar!
Target Milestone: M17 → M16
Cool. I'm kinda greedy to get my patches in!
Please get patch in by 5/16, doubt PDT will take it after.
Priority: P3 → P1
Moving all bugs that are not dogfood+, nsbeta2+,features, or nsbeta2- to M21
Target Milestone: M16 → M21
*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
nsbeta3 since we have a patch...
Keywords: nsbeta3
won't hold nsbeta3 for this, but you can still take the external patch.
Whiteboard: [nsbeta3-]
It's a quick and painless patch that won't affect anything else.
I'm not seeing this in the 2000081404 build. Looked at lxr and my patch isn't in. Perhaps it was fixed as a result of a change to something else...?
Definitely works for me with builds of the past coupla weeks. Something else musta fixed it.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Verified Platform: PC OS: Windows 98 Mozilla Build: 2000101020 M18 Trunk Build
Status: RESOLVED → VERIFIED
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

Creator:
Created:
Updated:
Size: