If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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




11 years ago
7 years ago


(Reporter: Daniel Stodden, Unassigned)


2.0 Branch

Firefox Tracking Flags

(Not tracked)




11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Ubuntu/edgy Firefox/
Build Identifier:

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

11 years ago
i just noticed the same applies to the passphrase dialog opening the saved passwords storage.
Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!
Whiteboard: CLOSEME 07/05
Version: unspecified → 1.5.0.x Branch

Comment 3

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

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


10 years ago
Whiteboard: CLOSEME 07/05
Version: 1.5.0.x Branch → 2.0 Branch
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
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.
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.