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

Status: VERIFIED WORKSFORME

(Core :: XUL, defect, P1)

Description

[:deanis74]

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.

Comment 1

[Mike Pinkerton (not reading bugmail)]

adding to saari's stress...

Comment 2

[:deanis74]

This isn't an overly important bug, so I'm changing the severity to trivial.

Comment 3

[Sean Richardson]

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.

Comment 4

[saari (gone)]

Sounds like popup windows are being created with the wrong OS flags.

Comment 5

[:deanis74]

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...

Comment 6

[:deanis74]

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

Comment 7

[:deanis74]

Attachment: Fix attached. Wrong return value for WM_MOUSEACTIVATE.

Comment 8

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 9

[:deanis74]

Adding 'patch' keyword, something that I should have done back in March.

Comment 10

[saari (gone)]

Doh, sorry, this got lost on the radar!

Comment 11

[:deanis74]

Cool.  I'm kinda greedy to get my patches in!

Comment 12

[Peter Trudelle]

Please get patch in by 5/16, doubt PDT will take it after.

Comment 13

[Peter Trudelle]

Moving all bugs that are not dogfood+, nsbeta2+,features, or nsbeta2- to M21

Comment 14

[sairuh (rarely reading bugmail)]

*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.

Comment 15

[saari (gone)]

nsbeta3 since we have a patch...

Comment 16

[Peter Trudelle]

won't hold nsbeta3 for this, but you can still take the external patch.

Comment 17

[:deanis74]

It's a quick and painless patch that won't affect anything else.

Comment 18

[:deanis74]

Attachment: Updated the patch with the latest source. Confirmed that it works as expected.

Comment 19

[:deanis74]

Attachment: Whoops! Forgot to add myself as a contributor. Can't have that!

Comment 20

[:deanis74]

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...?

Comment 21

[:deanis74]

Definitely works for me with builds of the past coupla weeks.  Something else 
musta fixed it.

Comment 22

[Keyser Sose]

Verified
Platform: PC
OS: Windows 98
Mozilla Build: 2000101020 M18 Trunk Build