Closed Bug 575487 Opened 10 years ago Closed 8 years ago

Page title should be displayed on title bar in new Windows theme

Categories

(Firefox :: General, defect)

All
Windows 7
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: tetsuharu, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100628 Minefield/3.7a6pre
Build Identifier: 

There is the empty area on the right side of Firefox button, and do not display the current page's title on latest mockup.

I think this inhibit user's cognition.

First, tab's width is a little small to display full page title.

Second, user don7't set any elements in the area of right side of Firefox button. So the area is dead and screen loss. It should use and set some purpose to the area.

Reproducible: Always
Blocks: 544820
Version: unspecified → Trunk
So are you saying we should show the page title beside the firefox button?
(In reply to comment #1)
> So are you saying we should show the page title beside the firefox button?

Yes. I think it.
Steven, what is the general design direction here for the titlebar text?
when the window pop up in a small window, the firefox 4 never show the page title nor the tab, it may confuse user to find where the title is.
Duplicate of this bug: 576242
Duplicate of this bug: 577404
I'd like to see that same space become available for customization.  I would love to move my personal bookmarks there.  I would be disappointment if it was reserved exclusively for displaying the page title.

Maybe a customizable (removable/relocatable) page title widget would satisfy everyone.
I would be happy with that kind of an option.  From the suggestion in Bug 578611, we could have three title bar modes: full title, trimmed title, and no title; this would allow the user to select whatever fit their needs best.
Duplicate of this bug: 578611
Component: Theme → General
QA Contact: theme → general
+1. A page title widget could work, or, if the devs decide to enable users to reposition status bar icons in the title bar, it could shorten as needed, eventually disappearing if there is no space left.

FYI, neither Chrome 6.x nor Opera 10.60 offer this.  IE 8, however, does.
I believe status bar is going to be replaced by a add-on bar. 
Putting Page title in the title bar is good, however, we need to think how to do it. Even if a page title widget is implemented, there will still be problems. 
Bug 571785 and 572160 out tabs into title bar, making the title bar space little if not none at all.
Not sure if this is by design or not (Aero mockups don't have a title though), but seeing as it has a few votes and a duplicate (and I agree), confirming in the hopes that someone will confirm one way or the other.
Status: UNCONFIRMED → NEW
Component: General → Theme
Ever confirmed: true
QA Contact: general → theme
Summary: Not display the current page's title on title bar in Windows New Theme → Page title should be displayed on title bar in new Windows theme
Component: Theme → General
QA Contact: theme → general
Would be nice to have the title centered in the bar like Word 2010.
Dão: Sorry if Theme is the wrong component for this bug, but General can't be either. What component should this go into? Or is it as intended (in which case I guess it should be WONTFIX)?
(In reply to comment #13)
> Would be nice to have the title centered in the bar like Word 2010.

That would go against system settings. Not. At. All.

That's equivalent to putting the close button on the left hand side.
(In reply to comment #15)
> (In reply to comment #13)
> > Would be nice to have the title centered in the bar like Word 2010.
> 
> That would go against system settings. Not. At. All.
> 
> That's equivalent to putting the close button on the left hand side.

Hmm... for some reason I thought apps with the quick access toolbar have their title centered. Disregard the centered part.
(In reply to comment #15)
>(In reply to comment #13)
>> Would be nice to have the title centered in the bar like Word 2010.
> That would go against system settings. Not. At. All.

This new theme has a Firefox button, which is against system settings. No one
raised a complaint over there. Even though office 2010 stopped it. But title in
center, which was standard for all ribbon apps in windows 7, is "against"
windows settings? (I must have misunderstood your comment)
Well, I'm just saying. If you want my window titles centered, I'll make them centered. If I DON'T want them centered, I put them NOT centered. Firefox should respect system settings. It's the same exact thing as with the titlebar height. As it stands now, it doesn't respect system settings bug #576960
A few different considerations:

1) The page title is part of the active tab, so should be visually grouped with the tab itself, and not placed on the background browser level
2) In maximized mode, the tabs will be placed on the screen edge for the fitt's law win, so there is no longer a title bar in which to draw the title
3) On Vista and 7, the title would need to appear on glass.  This is commonly done by Microsoft with a white glow around the text, but it is nonetheless very messy and hard to read.
4) We are working very hard to eliminate all redundancy in the UI

This will likely be a very popular Firefox extension, but in terms of the default UI, the page title should be displayed in the tab itself.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Re #1: If you want to push the distinction between the active tab and the content, that's fine.  But to take that stance while also offering a top-level option to break the grouping (toggling Tabs on top) strikes me as a conflicting UX message.

Re #2: You say that it will be possible for extensions to draw in the title bar. Will the status bar icons also be placed there? How will these be handled when the window is maximized and the tabs displace them?

Re #3: That's opinion. Depending on the color of your glassing and how much translucency you assign to active and inactive windows, text in the title bar can be very readable. (See http://aru.acm.jhu.edu/share/ie_glass_title.png)

Re #4: Sacrificing functionality for form? Right now with a 631px wide window I have 14 tabs open, several of which are from forums where the forum name precedes the individual page title. Text on the tabs becomes totally pointless at this resolution.  If I jump between bugzilla pages, short of memorizing the bug number, taking my hands off the keyboard to trigger the tooltip on the tab title or breaking my thought process to scroll up, there's no way to see the title.

I understand that there are many tough decisions that have to be made during the design process, but it saddens me to see Mozilla so readily aping a deficiency from Chrome/Opera.  If I don't have tabs on top, can I have a title in the *title* bar?
I'm confused Alex. First (in another bug) you categorically say tabs won't go into the title bar, now you say "In maximized mode, the tabs will be placed on the screen edge for the fitt's law win, so there is no longer a title bar in which to draw the title" What about if the user has bars above the window when maximized? What about the inconsistency between maximized and minimized states (where you force the user to manually expand the window instead of maximizing it)? What about the reduce room for tabs in the title bar? Specially if you have add-on icons there, or Sync menus or profile managers and so on?
>Tiago: you categorically say tabs won't go into the title bar

I meant for the non-maximized case

>Tiago: What about if the user has bars above the window when maximized?

If the user has a menu bar instead of a Firefox button, then this will be placed against the top screen edge.

>Aru: to take that stance while also offering a top-level
>option to break the grouping (toggling Tabs on top) strikes
>me as a conflicting UX message.

If tabs are not on top, we may want to keep the title (my impression of this bug was that it was to specify the title regardless of tab position).  I need to check with Stephen and the rest of the team.

>Re #2: You say that it will be possible for extensions to draw in the title
>bar. Will the status bar icons also be placed there? How will these be handled
>when the window is maximized and the tabs displace them?

We previously considered allowing users to customize their title bars (although we likely will not recommend that extensions place anything there on their own).  In this case if the user doesn't like the limited space remaining for their tab strip, they would need to continue to customize their layout.

>Re #3: That's opinion. Depending on the color of your glassing
>and how much translucency you assign to active and inactive windows

It's a subjective opinion, but I think that glow around the IE title looks awful.

>Re #4: Sacrificing functionality for form?

I don't understand why everyone is so quick to discount form in terms of a product's success.

>several of which are from forums where the forum name
>precedes the individual page title.

We need to consider removing preceding redundant text to help in this case, I've filed bug 583890
(In reply to comment #22)
> >Tiago: What about if the user has bars above the window when maximized?
> 
> If the user has a menu bar instead of a Firefox button, then this will be
> placed against the top screen edge.
Not what I meant. I meant if the windows toolbar, for example, is at the top edge of the screen instead of at the bottom. And I'm saying the windows toolbar because it's easiest thing to get there, but there is other software (like sound board drivers, media players and whatnot) that places ever visible toolbars at the top of the page. Even when the window is maximized. Is Firefox able to detect when the top edge of its maximized window is the top edge of the screen? If not, that's something you need to consider, at least you need to allow the user to not have tabs on title bar when maximized (and have Firefox button and all that too!!!). But I'm thinking, myself, that tabs on title bar when maximized, by default, is an all-in-all bad idea, not only from a design standpoint, but also from a popularity standpoint, as Firefox will surely loose a big chunk of users with that. Not that it won't gain a big chunk, but the kind of user who wants tabs on title bar tends to be a user that knows how to toggle an option in the Customize tab...

In any case, the question stands: is it possible to detect if the top edge of Firefox's maximized window is the top edge of the screen? Fitt's law doesn't apply if it isn't.

As a side note, I'm looking at this and am very displeased with this direction. Not that it matters, but I am.
And by "windows toolbar", I mean "windows' toolbar", the "thing" where you have the start button and all those things. Just making it clear.

Opera is completely unusable in maximized mode when you have stuff above the window (whatever it is), and they end up enticing the user to manually stretch the window to the edges of the screen. Chrome is completely unusable anyway, whether you have stuff up there or not.

I believe no application should check if it's maximized or not. It should simply work, and allow the user to choose where it is, how large it is and all that. The maximized state is about the system's settings, not the application. It's simply bad design to change the application's behavior between those states, and will definitely scare away plenty of people. It's not too rare to see people complaining that Chrome is ugly (it is) and it doesn't have a title bar and stuff like that. And back on topic with this one: I believe we should have the currently viewed page title on the title bar if the firefox button is disabled. I don't think it's good to have the title there if the firefox button is there too.

(will we really be able to treat the title bar as a normal toolbar if we want? That'd be fantastic, and we'd just need to put the tabs on the toolbar bellow the titlebar, and all would be well for those who want the title bar for other things)
(In reply to comment #23)
> As a side note, I'm looking at this and am very displeased with this direction.
> Not that it matters, but I am.

Hopefully, work will continue in bug 583905.
Depends on: 583959
(In reply to comment #24)
> And by "windows toolbar", I mean "windows' toolbar", the "thing" where you have
> the start button and all those things. Just making it clear.
> 
> Opera is completely unusable in maximized mode when you have stuff above the
> window (whatever it is), and they end up enticing the user to manually stretch
> the window to the edges of the screen. Chrome is completely unusable anyway,
> whether you have stuff up there or not.
> 
> I believe no application should check if it's maximized or not. It should
> simply work, and allow the user to choose where it is, how large it is and all
> that. The maximized state is about the system's settings, not the application.
> It's simply bad design to change the application's behavior between those
> states, and will definitely scare away plenty of people. It's not too rare to
> see people complaining that Chrome is ugly (it is) and it doesn't have a title
> bar and stuff like that. And back on topic with this one: I believe we should
> have the currently viewed page title on the title bar if the firefox button is
> disabled. I don't think it's good to have the title there if the firefox button
> is there too.
> 
> (will we really be able to treat the title bar as a normal toolbar if we want?
> That'd be fantastic, and we'd just need to put the tabs on the toolbar bellow
> the titlebar, and all would be well for those who want the title bar for other
> things)

When Firefox button is disabled, page title in the title bar is viewable. It was there the whole time, no one change anything about it. The problem is more of how to show the page title when Firefox Button is turn on and when Tabs are in title bar. Hope bug 583905 get accepted.
Duplicate of this bug: 612290
Sorry, I'm late to the game here, but that won't stop me from commenting...

(In reply to comment #19)
> This will likely be a very popular Firefox extension, but in terms of the
> default UI, the page title should be displayed in the tab itself.

See the attached screenshot.  How am I supposed to tell the titles of my pages when everything starts with "Bug" or "CNN".  You have to consider people that browse with more than two or three tabs open.

(In reply to comment #24)
> And by "windows toolbar", I mean "windows' toolbar", the "thing" where you have
> the start button and all those things. Just making it clear.

The term you're looking for is the Windows Taskbar.
I think that "Tab on Top" mode is set tabs to top of stratum by look & feel.
In this mode, tabs are treated as traditional window which the smallest unit of web page. And tab-bar means like title bar.

But in old style (tab-bar on the position before Firefox 3.6), tabs are treated as descendent window of Application window.

Should it provide page's title in title bar by default in the old position before Firefox 3.6?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I agree that in tabs-on-bottom page title should be displayed as per usual.
However, in tabs-on-top, page title can still be found in a tooltip by hovering over the tab (at least in Windows...), which is quite expected UX for Windows users. Perhaps the delay in the tooltip appearing can be reduced?
Another solution is to increase the tab length on hover, which might be a UI WIN...? But again, from a UX point of view, I'm not sure everyone will agree that by default you have tabs expanding and contracting all over the place.

I'm happy with the tooltips on tabs.
Titlebar is not related to the tab title, as Faaborg pointed out. Tabs on bottom is also going away soon.
Status: REOPENED → RESOLVED
Closed: 10 years ago8 years ago
Resolution: --- → WONTFIX
+1
Please display the page title in the title bar, where users expect it to be. Many page titles are too long for a tab's width.

I understand the (broken) logic behind it. But it really hurts nobody to add an about:config parameter for that.
You need to log in before you can comment on or make changes to this bug.