308905 - "Security warning" dialogs change the focused tab

Status: RESOLVED DUPLICATE of bug 123913

(SeaMonkey :: UI Design, defect)

Description

[Xanthor Sccas]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050913 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050913 SeaMonkey/1.0a

When we open a new tab which raise a security warning, the dialog gives focus to
thsi new tab, even if we prefere loading tabs in background.

Reproducible: Always

Steps to Reproduce:
1. In Preference > Privacy & Security > SSL, check "SSL warnings : Loading a
page that supports encryption"
2. Try to open the link "Description" (just above this comment) in a new tab,
and in background

Actual Results:  
A new tab is created, with the linked page, but a security warning is raised,
which gives focus to this new tab, breaking the "load in background" pref.

Expected Results:  
The security warning shouldn't change the focused tab

It's a regression (I mean, this behaviour didn't occure in Moz 1.8b1 for example).

I understand that this behaviour may be considered as the valid one, in order to
show to the user which tab is concerned by the warning, but this is really
enoying for "power users" who know what they're doing, and who load lots of tabs
in background. So maybe a hidden pref (again ;¬þ) could allow us to choose...

Comment 1

[Andrew Schultz]

The purpose of the dialog is to inform the user of the page's security.  If the
user sets the pref, the user wants to know and the app /must/ show it.  There
won't be a hidden pref.

The correct solution is to not show the dialog until you focus the tab, and to
somehow indicate in the tab bar that the particular tab is blocked from
continuing to load.  That's bug 123913.

*** This bug has been marked as a duplicate of 123913 ***

Comment 2

[Greg Colyer]

Comment #1 is missing the point. The problem is not the warning dialog (which, as you point out, has been requested), it is the unwanted change of focus. It may well be that the correct solution is to fix bug 123913, but why was this behaviour changed in the meantime? As the reporter says, it's a regression (or probably a "new feature"). Background tabs should not acquire the focus permanently. If it was decided to make this change so that the user is sure which tab is generating the dialog, then it should return the focus afterwards.

Is there a preference, or could there be one, not for suppressing the dialog but for reverting to the previous behaviour where the focus was not grabbed?

A bug number for that change might help.

Comment 3

[Andrew Schultz]

The functionality you want doesn't exist.  It might or might not be easier to implement your suggestion than to fix bug 123913.  You'd need to file a new bug.

Comment 4

[Xanthor Sccas]

(In reply to comment #3)
> The functionality you want doesn't exist.
It was working with Moz 1.8b1...

> You'd need to file a new bug.
Isn't this bug enough ?
Should I reopen it then ?