Closed Bug 80222 Opened 23 years ago Closed 14 years ago

Need to indicate Security status for sidebar vs Document Security status

Categories

(SeaMonkey :: Sidebar, defect)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: briansmith, Unassigned)

References

Details

The fix for Bug 43797 caused the status bar to be re-positioned underneath the
sidebar. Before, it was only underneath the document's content. It needs to
revert back to its previous behavior. Here are some reasons:

1. By putting the status bar under the sidebar, you are implying that the
security lock applies to the sidebar, when in fact the sidebar and the document
content could very well have different security properties. This is a security
problem. See news://news.mozilla.org/3936C184.F5FF18F7@netscape.com which is
from June of 2000. Also, see the same comments re-iterated in Bug 43797. 

2. There is room for one less tab in the sidebar, for which vertical space is at
a premium.

3. The sidebar might eventually need to have its own status bar (for example, to
display its own security lock).

I think the reason that this change was made was to fit in the component bar.
Perhaps the component bar should be temporarily removed until a better place can
be found for it, so that the status bar can go back to its original position
without losing any space to it.
I filed Bug 80222 before I found Bug 44731. Bug 80222 is basically asking to do
the opposite of this what this Bug 44731 is for. If you think that the status
bar should go underneath the sidebar, then perhaps the status bar is not the
place for the security lock? In particular, won't you want to know the security
settings of the sidebar eventually? So it will need its own security icon
(perhaps on the tab next to its name?).
suggest wontfix, because the new layout saves a lot of space compared to the old
layout. 

I created bug 80228 that adds some polish to the new layout and would allow for
the security icon to always be to the right of the sidebar. Actually, my bug
would fix this bug - sort of :)

BTW, the security icon is on the far right in windoze, so it's not an issue there.
<q class="Bah">We should just put a lock icon into each tab's tab region and be 
done w/ this stupid bug.</q>

Would that satisfy your concerns?
I think adding security status indicators to tabs is needed if supporting 
secure sidebar tabs is a requirement for mozilla, which I would think it will 
be. 

Firstly, keep in mind that I am not a trained UI designer. I am just going off 
my intuition as a user, although I am an application developer as well. So, I 
am just making a suggestion. It is up to the Mozilla UI design team to create a 
specification for the Mozilla UI that is appropriate. The "old" one is at 
http://www.mozilla.org/projects/ui/communicator/framework/screenlayout/ and 
this change is obviously not inline with that spec. According to those pages, 
the specs need to be updated. I am not sure what the process is for updating 
the spec, but I think the spec should be updated before things are moved 
around. That will ensure that changes are made with proper motivation and 
without conflicting with the UI goals.

In particular, the issue of the position of the status bar W.R.T the sidebar 
needs to be spec'ed out. Similarly, the issue of what to do with the component 
bar needs to be planned. In Bug 43797, people raised concerns about moving the 
status bar and raised the possibility of eliminating the component bar.

Here are some more thoughts:

I think that there still wouldn't be enough visible link between the document 
and the lock icon if the status bar is still underneath the sidebar. Plus, if 
we don't move the status bar back to its original position, then we are still 
wasting vertical space in the sidebar.

When one looks at the status bar, most of the time it is to get some 
information, not to click on the component bar. The component bar gets in the 
way in this situation because it is at the "beginning" of the status bar. I am 
guessing that it wouldn't get in the way if it was moved to the right side of 
the status bar (if it must be on the status bar). However, if you move the 
component bar to the right or hide the component bar, then the primary status 
information for the document is then going to be underneath the sidebar, not 
underneath the document.

If the component bar is moved off the status bar then there isn't any advantage 
to having the status bar under the sidebar, especially when the progress 
indicator becomes auto-hidden.

There was a mention that eventually the bookmarks sidebar tab will show the URL 
of the bookmark in the status line. However, I think that newer applications 
are placing such mouse-position-sensitive information in tooltips to reduce eye 
movement, which, IMO is the preferred way to go.
Confirming altered summary. More thoughts (all offtopic)

you'll notice that the toolbar 
http://www.mozilla.org/projects/ui/communicator/framework/screenlayout/blox.gif 
does not extend over the sidebar.  Which would be correct except that no one 
could tolerate it =).

Since the sidebar only supports one or two active items (one tab, one special) 
all other tabs are wasted, a listbox + active tab would be much more efficient. 
No sympathy from me to people who have 100 tabs and expect something useful 
from showing all of them.  For now, just add all and then uncheck all from the 
tabs menu.  Check one tab, that's the one you're using. To switch, check the 
one you want and uncheck the one you were using.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Status bar should not be under sidebar → Need to indicate Security status for sidebar vs Document Security status
I think the distinction between secure content and (possibly) insecure sidebar 
is defined well enough by having the lock icon at the far right of the status 
bar.

As for loading progress -- if loading progress of sidebar panels is not being 
shown in the status bar, as loading progress of Web pages is, that should be 
filed as a separate bug.
Depends on: 44731
.
Assignee: mpt → sgehani
Component: User Interface Design → Sidebar
QA Contact: zach → sujay
Product: Browser → Seamonkey
Assignee: samir_bugzilla → nobody
QA Contact: sujay → sidebar
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.