Closed Bug 159233 Opened 22 years ago Closed 14 years ago

Can't Hide Status Bar

Categories

(Camino Graveyard :: Toolbars & Menus, enhancement, P3)

PowerPC
macOS
enhancement

Tracking

(Not tracked)

RESOLVED FIXED
Camino2.1

People

(Reporter: syrreg, Assigned: stuart.morgan+bugzilla)

References

Details

(Whiteboard: 1.9.1)

Attachments

(3 files, 4 obsolete files)

Can we have the ability to show/hide the Status Bar?
Target Milestone: --- → Chimera0.5
->pinkerton
Assignee: saari → pinkerton
Summary: Can't Hide Status Bar → [RFE] Can't Hide Status Bar
Is this really a good idea? I don't think so.
Severity: normal → enhancement
Target Milestone: Chimera0.5 → Chimera0.9
QA Contact: winnie → sairuh
Summary: [RFE] Can't Hide Status Bar → Can't Hide Status Bar
Yes please...
A standard aqua status bar can always be shown or hidden, but we don't use a
standard one, and we (arguably) display more important information in ours.
OTOH, I think it would be easy enough to put the secutiry information somewhere
else, and I would like to see a standard status bar (bug 169838).
Target Milestone: Chimera0.9 → Future
Would it be so hard to give people an option to show or hide the staus bar. It's
been possible in almost every browser I know of.

Sure it show the user important info, but a user should be able to tell if he or
she want's to se it or not, just like any other toolbar.

Pop-ups are alread able to show or hide the status bar, why not the user?
Mike?
we'd have to find another place for the popup blocked icon and the security
lock. also, there would be no visible indicator of progress. 
I think we should just leave the user with two options: show or hide the status
bar. Hiding it means that they will not benefit from all the status indicators
located in the status bar (popup, process, security, etc.), which would be their
decision and responcibility. Since we already do this by accepting popups to not
show a status bar I don't really see a big problem accepting this request.

If we where really to find alternate locations and solutions for all of the
status bar indicators we could just ass well just remove it all together?

Possible solutions?
- the popup indicator could be transformed into a toolbar item.
- the security icon could also be put in the toolbar or we could place it in the
title bar on the left/right side of the title.
- process indicator could be placed in the url field (copying Safari) but we
also have a throbber that would finally have a great use.
- as for the text status indicator I think we could just skip searching for an
alternate location since it's not vital to not have it visible. perhaps a
tooltip enhancement could solve this partialy!
> - the popup indicator could be transformed into a toolbar item.

no, would waste too much space and we can't hide/show it easily on the toolbar
so it will always be in the user's face.

> - the security icon could also be put in the toolbar or we could place it in the
> title bar on the left/right side of the title.

again, big space waster and i'm not doing any custom titlebar drawing code.

> - process indicator could be placed in the url field (copying Safari) but we
> also have a throbber that would finally have a great use.

i can't stand that about safari, i always think it's messing with the selection.

> - as for the text status indicator I think we could just skip searching for an
> alternate location since it's not vital to not have it visible. perhaps a
> tooltip enhancement could solve this partialy!

agreed, that is not vital.
As I said before let's just keep the solution simple. Hiding the status bar
means that those users will not benefit from all the status indicators located
in the status bar, which would be their decision and responcibility. Since we
already do this by accepting popups to not show a status bar I don't really see
a big problem accepting this request.

But I do agree that it would be NICE if there where alternate opions to keep
those usres informed anyway. Does anybody else have solutions? But I don't
really see why we should do that.
(In reply to comment #9)

> > - the security icon could also be put in the toolbar or we could place it in the
> > title bar on the left/right side of the title.
> 
> again, big space waster and i'm not doing any custom titlebar drawing code.

I think the way Firefox handles this now--with the security icon in the URL bar--works pretty well. We 
could even just overlay a lock icon on the normal page proxy to save space.
Now that mike checked in the code that displays the security icon in the url
field we have the oppertunity to add this feature.

The patch in Bug 246112 has code that allows us to hide the status bar.
We use popups via window.open to display additional information when a link is
pressed. We have always used status=no and location=no to hide the status bar in
the popup. They are apparently ignored by Mozilla. Still work ok in IE.
No longer depends on: 246112
The only thing that seems to be left is the pop-up blocker. How about doing
something similar to Firefox *only* when the status bar is hidden (and have an
option to turn it off). Any thoughts?
Housekeeping: the popup notification stuff (bug 272171) is the only piece of
critical functionality left that really blocks giving the user the hiding option.  

Also, in bug 185170, Jasper points out that bug 246112 contains some useful code
for this (can't hide) bug.
Depends on: 272171
I concur that this feature should be added. You can do it in safari, firefox,
and I think IE, too. Not only that, but a LOT more people hide it than you'd
think. The reason? To regain screen real estate. The little bar takes up space
at the bottom. Remove it and you get more screen space to display sites. Plus,
it's kind of annoying having it there after having turned it off in all the
browsers I've used before. Most of the information displayed there is pretty
useless anyway. I don't really ever need to know what file it's trying to load
at any given time, nor do I care.

For "popup blocking working", "secure" and all of that other stuff, you can put
small icons at the right end of the url bar, like in firefox. 
When fixing this, make sure that the status bar can be toggled back on in
windows where it's been hidden by chrome flags (see bug 176421).
Mike, since you checked in a fix that moves the pop-up notification, care to fix this bug as well?
We will have to make sure that the feed detection icon will be placed in the url bar if we make the statusbar hide-able.
(In reply to comment #19)
> We will have to make sure that the feed detection icon will be placed in the
> url bar if we make the statusbar hide-able.

Shouldn't that depend on whether the statusbar is actually hidden? And don't forget that the url bar also is hide-able (but this really belongs in bug 287705).
Re-targeting for 1.1.
QA Contact: bugzilla → toolbars
Target Milestone: Future → Camino1.1
This patch contains a traditional patch-file for the source-code and a binary "keyedobjects.nib" for the MainMenu.nib. Content type is tar.gz.

This patch implements a new MenuItem View->Hide/Show Status Bar to toggle the status bar on/off.

There is a minor issue with the source. To hide the status bar, I set the height of the status bar NSView to zero. But I do not know how to figure out the original NSView frame height of 18. So, for the time being the code contains a hardwired 18.
Hi, thanks for the patch!

2 quick notes: we prefer patches and nibs separate, i.e., the patch as a patch to the source files in one attachment and the entire nib, zipped, as a separate attachment.  And we tend to miss Localizable.strings additions, so it's nice to state clearly that a patch requires them ;)

I tried to apply this to my trunk tree and I got several hunks failed...I think maybe pink's checkins yesterday afternoon clash, but I haven't had time to investigate :-(
> 2 quick notes: we prefer patches and nibs separate
Sorry for that! I'm new to camino-development. I've searched for infos about it, but found nothing that gaves me some details about the rules.

> And we tend to miss Localizable.strings additions, so it's nice to
> state clearly that a patch requires them ;)
Can you explain this?

> I tried to apply this to my trunk tree and I got several hunks failed...
I've used the CAMINO_1_0_BRANCH. Maybe that's the reason.
As requested, the patch to the source separatly.
Attachment #216091 - Attachment is obsolete: true
As requested, the complete MainMenu.nib (english).
CAMINO_1_0_BRANCH is a dead-end; little or nothing will be added to it.  MOZILLA_1_8_BRANCH is the interesting branch.
(In reply to comment #24)
> Sorry for that! I'm new to camino-development. I've searched for infos about
> it, but found nothing that gaves me some details about the rules.

Yes, we need to make our docs better in this regard.

> Can you explain this?

Regarding Localizable.strings, he means list what changes need to be made here, in the bug. Doing it as a patch doesn't work quite right since diff isn't a good friend of UTF-16. :)

> I've used the CAMINO_1_0_BRANCH. Maybe that's the reason.

This is where our docs should be updated saying that Camino patches should be made for the trunk and ported to the various branches we may take it on (in this case, MOZILLA_1_8_BRANCH as Stuart said in comment 27).
Rather than set the height to 0 (which may cause mispositioning of subviews), I think we should remove the status bar view from its superview. This code would live in BrowserContentViews.mm.
Assignee: mikepinkerton → nobody
Target Milestone: Camino1.1 → Camino2.0
I have this coded up, but I ran into bug 56488; without fixing that it doesn't seem realistic for us to include this in Camino.
Depends on: 56488
This is everything but the menu item and the menu validation code. I'd like to go ahead and submit that part for a few reasons:
- Supporting the user defaults means that users who want this functionality badly enough to live with bug 56488 can do so without resorting to a hack.
- Hacks that do want to provide UI (e.g., UnifyCamino) can do so in a more stable way.
- It makes the status bar hiding much more like the new bookmark bar hiding code.
- I've already written and tested it, and throwing it away means having to write it again later.
- It's unlikely to rot, but if something does perturb it this will let us fix it as we go, rather than having a patch sit here and become useless.
Attachment #216099 - Attachment is obsolete: true
Attachment #216101 - Attachment is obsolete: true
Attachment #268916 - Flags: review?
Attachment #268916 - Attachment is patch: true
Attachment #268916 - Attachment mime type: application/octet-stream → text/plain
Attachment #268916 - Flags: review? → review?(murph)
Comment on attachment 268916 [details] [diff] [review]
core functionality [checked in]

Nice code, and behavior works as expected; r=me.
Attachment #268916 - Flags: review?(murph) → review+
Attachment #268916 - Flags: superreview?(mikepinkerton)
Comment on attachment 268916 [details] [diff] [review]
core functionality [checked in]

-      mProgress = nil;
-      mStatus = nil;

why is this no longer necessary?

sr=pink
Attachment #268916 - Flags: superreview?(mikepinkerton) → superreview+
(In reply to comment #33)
> why is this no longer necessary?

Because they are no longer invalid dangling pointers, since the view hierarchy is never destroyed, and because if we switch them back and forth between nil and not, then when the status bar is unhidden it would have whatever state it happened to have when it was hidden, rather than current information.
Comment on attachment 268916 [details] [diff] [review]
core functionality [checked in]

Landed on trunk and MOZILLA_1_8_BRANCH. Leaving open for UI work once bug 56488 is fixed.
Attachment #268916 - Attachment description: core functionality → core functionality [checked in]
Since the blocker doesn't appear to be happening for Gecko 1.9, pushing off the 2.0 list. As soon core will let us do this, we'll add the UI.
Target Milestone: Camino2.0 → ---
Bug 56488 is now fixed. Does it need to be checked-in into the 1.9 branch in order to be useful for Camino?
It does, yes, so a cvs trunk checkin would be great.
hendy and smorgan both mentioned maybe getting to the UI hookup for 2.1, although it's probably not near the top of the list in terms of things we need to fix (P3 = if it's done before feature freeze).
Priority: -- → P3
Target Milestone: --- → Camino2.1
Attached patch add the UISplinter Review
Adds the wiring for a menu item. While I was modeling it after the bookmark bar I discovered that BWC's encapsulation on the bookmark bar sucked, so I fixed that at the same time.

I also added the status bar to the things handled by session restore (and broke out a couple of helper methods in the session mananger to make things clearer).
Assignee: nobody → stuart.morgan+bugzilla
Status: NEW → ASSIGNED
Attachment #448400 - Flags: superreview?(mikepinkerton)
Attached patch new nib (10.6) (obsolete) — Splinter Review
Nib with the new menu item. This is based on the nib from bug 569130 to lower the chances of having to recreate it.
Attachment #448401 - Flags: review?(alqahira)
Comment on attachment 448400 [details] [diff] [review]
add the UI

+- (void)createBrowserWindowFromSerialization:(NSDictionary*)state

is there any error handling necessary here? seems like if something can go wrong, it will (look at bookmarks!), and I'd hate to break the user's ability to launch the app because their restore state is hosed.

sr=pink
Attachment #448400 - Flags: superreview?(mikepinkerton) → superreview+
Here's the new nib for this bug, resaved in IB2.5.  I verified that Show/Hide still work.
Attachment #448401 - Attachment is obsolete: true
Attachment #448401 - Flags: review?(alqahira)
I guess I could check that all the keys are present; most would work out if they were missing, but creating an NSRect from a call to nil could get ugly.
Landed 3109:e76f5e71f63d
(I didn't think about the fact that the NIB ordering means this isn't CVS-able. If it ever becomes important, we can make a new NIB and land it there.)
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: