347376 - Certificate check dialog on command-line invocation takes wrong or at least inconvenient browser window as parent

Status: RESOLVED INCOMPLETE

(Firefox :: Security, defect)

Description

[Daniel Stodden]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Ubuntu/edgy Firefox/1.5.0.4
Build Identifier: 1.5.0.4

The 'inconvienience'-part is probably only applies on desktop systems sporting virtual desktops to switch in between. Most notably Linux. Different systems may be affected differently. I'm not currently using anything else for most of my time.

Consider two virtual desktops D1, and D2.
Consider running Firefox in D1 and some arbitrary other program, here a mail user agent, on D2.

We're currently watching D2.

Program on D2 exposes a URL to click on. Let's mentally do so. Program calls firefox binary to open the link.

Consider the link to be https://.., pointing at a TLS-secured site. Furthermore, consider the certificate consistency check to fail, resulting in an additonal, although entirely justified, dialog window to pop up, requesting the user to examine the situation and how to proceed in that matter.

The problem is that it appears to prefer popping up in D1, where your open browser windows are situated. Not on D2, where yourself remains to spend quite a number of potential minutes to wait for something acknowledging that URL-click activity to happen.

I'd suggest that the TLS support where the dialog window originates is suffering from some misconceptions.

By the way, I'm using a fairly standard GNOME desktop on a recent and frequently-upgraded Ubuntu Linux system, i.e. Metacity as window manager in case someone suspects this to make a difference.

Reproducible: Always

Steps to Reproduce:
Run Linux/X11 with virtual desktops.

1. start firefox on you 'www'-desktop. don'
2. start something calling firefox (e.g. gnome evolution) on your 'email'-desktop. stay there.
3. open some mail containing a https://-link provoking a certificate check dialog
4. click it
5. wait until the cows come home for something to happen
6. switch back to you 'www'-desktop
7. discover the above dialog window you've been missing.
Actual Results:  
dialog window does not occur on the current desktop, but associates with a fairly unrelated browser window on a totally different desktop.

Expected Results:  
dialog windows for external openURL()-requests should not be associated with any existing browser window, but should appear right where you've been.

Comment 1

[Daniel Stodden]

i just noticed the same applies to the passphrase dialog opening the saved passwords storage.

Comment 2

[Steve England [:stevee]]

Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!

Comment 3

[Daniel Stodden]

Yes, it still applies. No changes whatsoever on that front.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20061201 Firefox/2.0.0.4 (Ubuntu-feisty)

Comment 4

[Tyler Downer [He/Him]]

This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode

Comment 5

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.