807774 - nsILocalFile.reveal() does not close autohide panels.

Status: NEW

(Core :: Widget: Gtk, defect, P5)

Description

[Mike Conley (:mconley) (:⚙️)]

STR:

1) Create an autohiding panel, and insert a button or link that responds to a click event by calling nsILocalFile.reveal(); on some local file.
2) Open the panel, and click the button.

What happens?

On Ubuntu at least, Nautilus opens, but the panel remains open as well - what's more, it will appear *on top* of Nautilus.

What's expected?

When another application like Nautilus takes focus, autohide panels should close.

Comment 1

[Karl Tomlinson (:karlt)]

Are you sure nautilus is taking focus?
Normally popups rollup on focus-out.

Is CaptureRollupEvents being called on the panel?

NSPR_LOG_MODULES=Widget:5,WidgetFocus:5 could be helpful.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Ah - you're right - on a second look, Nautilus doesn't have window focus - but it does appear overtop of Firefox. I'll post a screenshot.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Attachment: Screenshot of Firefox focused, but in the background

The window chrome indicates that Firefox is in focus...but Nautilus is clearly being displayed overtop. Firefox still responds to mouse events - I can scroll, for example - but Nautilus remains on top.

Comment 4

[Karl Tomlinson (:karlt)]

I'm guessing that nautilus is not taking focus because the timestamp in DESKTOP_STARTUP_ID is not being set properly (assuming we want reveal to pass focus to the new app).

Comment 5

[Marco Bonardo [:mak]]

so we should do something like invoke gdk_app_launch_context_set_timestamp before g_app_info_launch_default_for_uri to tell we want to give focus?
If it's not any harder than this, we may take the platform fix and avoid the workaround in bug 807709

Comment 6

[Karl Tomlinson (:karlt)]

Yes, I expect so, but a default GdkAppLaunchContext will use gdk_x11_display_get_user_time() automatically, and I'd guess that is the best info we have at the callsite.

gtk_show_uri() looks the best option as that will create a GdkAppLaunchContext and pass it to g_app_info_launch_default_for_uri() for us.

However, perhaps you still may want to close the panel explicitly.  Think about:

Do you want the panel to close on click of the button or link, or do you want it to stay open until the new app has started?

Do you want to allow clicking on multiple links sequentially? (in which case the last app started will eventually take focus.)

If the app fails to start, do you want the panel to stay open?

Comment 7

[Marco Bonardo [:mak]]

(In reply to Karl Tomlinson (:karlt) from comment #6)
> However, perhaps you still may want to close the panel explicitly.  Think
> about:
> 
> Do you want the panel to close on click of the button or link, or do you
> want it to stay open until the new app has started?
> 
> Do you want to allow clicking on multiple links sequentially? (in which case
> the last app started will eventually take focus.)
> 
> If the app fails to start, do you want the panel to stay open?

Good point, the common behavior of our panels is to close on blur, though your point about multiple clicks made me think to the feel of unresponsiveness that may give clicking on something and seeing that nothing happens (if the system is busy). So maybe just closing the popup would at least be an immediate reaction, better than having the user repeatedly clicking on the item and ending up with 4 or 5 opened files.
In the last case, having the panel open would make sense, though there would be no way for the user to distinguish an open fail to a non working click handler, so I suppose it's still better to close the panel.

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1552613