404297 - drop down menus stick open when PDF is being viewed

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[adam tester]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

when viewing a PDF (not a web page), the File Menu sticks open and cannot be closed with "Esc" or clicking on the page. Only Clicking on teh menu bar closes the menu 

Reproducible: Always

Steps to Reproduce:
1.open some PDF
2.click "File
3. now try and close the menu with Esc or by clicking elsewhere
Actual Results:  
menu sticks open

Expected Results:  
menu closes

reproducible

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This is really a bug on Windows. So, this shouldn't be dup of bug 38484.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Perhaps, the actual cause is that even if we click menubar when the plug-in window has focus, the native focus isn't moved to our window. If I move the focus to our window first, e.g., clicked in location bar first, then, I cannot reproduce this bug.

So, I think that we should steal focus at WM_MOUSEACTIVATE (or WM_*BUTTONDOWN) only when non-our window has focus.

Ere and Kimura-san, do you have some ideas for this?

Comment 4

[Masatoshi Kimura [:emk]]

Our plug-in window needs to be grab focus from *our* windows.
When it failed, our focus management will be broken. It's the cause of 
bug 521951. In this case, Java applet grabs focus directly without notifying our plug-in window.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v0.1 (rough)

Kimura-san, this is my rough sketch of my idea. Looks like this also fixes bug 521951 too.

Comment 6

[Masatoshi Kimura [:emk]]

Why the focus manager won't give the focus to us? Isn't it a bug of focus manager?

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that the menubars and toolbars shouldn't take focus in normal cases even if they are clicked. So, it's not focus manager's job, I think.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v1.0

Probably, this is better. ESM should clear focus only when a windowed plug-in has focus even if the clicked element should suppress blur event.

Comment 9

[Neil Deakin]

This last patch doesn't look right. Clicking outside a plugin on a non-focusable area of the chrome should not blur the plugin.

The issue with menus not rolling up when clicking must be a bug in the rollup handling (nsWindow::DealWithPopups), especially likely if this bug really is Windows only.

Note that the Esc key not working to close the menu is bug 78414.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that the native focus movement is necessary at least on Windows especially when our popup window is opened.

First, we cannot use the global message hook for listening mouse events and keyboard events because it must be in a DLL. And it's pretty risky for the system (e.g., our hang-up becomes system hang-up).

When a plug-in has focus, but the user clicks on non-plug-in window (i.e., our window), doesn't the user want to operate our window? How do you think? I think that the user wants to switch the (pseudo) focus to us, involuntary.

Comment 11

[Neil Deakin]

(In reply to comment #10)
> First, we cannot use the global message hook for listening mouse events and
> keyboard events because it must be in a DLL. And it's pretty risky for the
> system (e.g., our hang-up becomes system hang-up).
> 

Are you saying that we don't get mouse events either? We should at least be getting mouse events when clicking on a non-plugin area.


> When a plug-in has focus, but the user clicks on non-plug-in window (i.e., our
> window), doesn't the user want to operate our window? How do you think? I think
> that the user wants to switch the (pseudo) focus to us, involuntary.

I don't think that content that happens to be in a plugin should behave differently than non-plugin content.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Do we have any update for this bug? Would the issue mentioned here also apply to the Firefox button menu? If yes, bug 649481 seems to be a dupe.

Comment 15

[baffclan]

Cannot reproduce with Nightly on Windows10 Pro

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Although, Gecko's widget doesn't fix this bug actually, by stopping supporting plugins (except Flash), you must not be able to reproduce this bug anymore. If you find STR to reproduce same symptom, please file a new bug.