plugin prompt is parented to wrong window

While reviewing older bug comments (see ticket:18937#comment:35), brade and I reproduced a problem: the confirm prompt for disabling plugins is attached to a dialog which is in the process of closing rather than being attached to a browser window. On OSX, this results in the dialog having a black background before closing (closing the prompt without user interaction). On Windows the prompt never appears.

Steps to reproduce: Open Torbutton's Privacy and Security Settings dialog Uncheck "Disable browser plugins" Click OK

We will post a patch in a few minutes.

added TorBrowserTeam201607 component::applications/tor browser owner::mcs priority::medium resolution::fixed severity::major status::closed type::defect labels

Trac:
Summary: prompt is parented to wrong window to plugin prompt is parented to wrong window

Here is a patch: https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19689-01&id=6dc6475c1772528a6c8da56dade8bb85c7e52d79

Trac:
Keywords: N/A deleted, TorBrowserTeam201607R added
Status: new to needs_review

Okay, this is merged as commit 2146d7700159bb1d836be14a96f9f3b335398056 and f5fa0465dfa666b0bdbfc7e1d0cc51be68680245 on master and maint-1.9.5.

However, this feature seems to be broken on Linux (at least) in general as xpcom-category-entry-added does not seem to get fired and thus torbutton_confirm_plugins() is never called. Or did I miss something? That's the same issue for Windows I guess?

Trac:
Status: needs_review to needs_information
Keywords: TorBrowserTeam201607R deleted, TorBrowserTeam201607 added

Replying to gk:

However, this feature seems to be broken on Linux (at least) in general as xpcom-category-entry-added does not seem to get fired and thus torbutton_confirm_plugins() is never called. Or did I miss something? That's the same issue for Windows I guess?

We did not test on Linux but we did test on Mac OS and Windows. After applying our fix, the prompt was displayed on Windows. We will test on Linux. One confusing thing is that once the prompt is displayed, it is not displayed a second time until the browser is restarted (xpcom-category-entry-added does not fire a second time). I wonder if there is another ticket already open for that issue? It did not seem too important because the prompt was always displayed for us the first time plugins were enabled on Mac and Windows.

A quick follow up: On Linux, Mark and I did not see the prompt because no plugins were actually installed on our Linux system in a place where Tor Browser could find them. After we set plugins.load_appdir_plugins = true and placed libflashplayer.so in tor-browser_en-US/Browser/browser/plugins/, the prompt was correctly displayed (a side note: I am not sure where Tor Browser looks for plugins by default; it did not load libflashplayer.so when we placed it in /usr/lib64/firefox/browser/plugins).

Should we file a new ticket, e.g., "plugin warning not displayed if no plugins available"?

Replying to brade:

A quick follow up: On Linux, Mark and I did not see the prompt because no plugins were actually installed on our Linux system in a place where Tor Browser could find them. After we set plugins.load_appdir_plugins = true and placed libflashplayer.so in tor-browser_en-US/Browser/browser/plugins/, the prompt was correctly displayed (a side note: I am not sure where Tor Browser looks for plugins by default; it did not load libflashplayer.so when we placed it in /usr/lib64/firefox/browser/plugins).

Should we file a new ticket, e.g., "plugin warning not displayed if no plugins available"?

Yes, please. Maybe showing an adapted text message would make sense in this case.

Trac:
Resolution: N/A to fixed
Status: needs_information to closed

Replying to gk:

Yes, please. Maybe showing an adapted text message would make sense in this case.

This is #19719 (moved).

#11287 (moved) is a duplicate.

closed

moved to tpo/applications/tor-browser#19689 (closed)