Closed Bug 940093 Opened 6 years ago Closed 6 years ago

Offer UI pref to toggle titlebar back on

Categories

(Firefox :: Theme, defect)

28 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 29

People

(Reporter: rnewman, Assigned: Gijs)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [Australis:P1][strings])

Attachments

(8 files, 3 obsolete files)

1.16 KB, patch
Gavin
: review-
Details | Diff | Splinter Review
629.24 KB, image/png
Details
311.78 KB, image/png
Details
524.20 KB, image/jpeg
Details
538 bytes, image/png
Details
550 bytes, image/png
Details
317 bytes, image/png
Details
24.02 KB, patch
jaws
: review+
Gijs
: checkin+
Details | Diff | Splinter Review
Firefox's previous visual design displayed the page title in the title bar, and again in the selected tab in the tab bar. The latter is truncated by more open tabs; the former is not.

Open more than a handful of tabs, and you see this:

   _______________________________________________________________
   ° ° °    Amazon.com: Novelty Horse Head Mask Prop: Toys & Games
   Amazo…  Welcom…  Twitte…  …                                   +


Australis says "screw that, everyone has three tabs open on a widescreen display", and shows you this:

  _____________________________________________________
  ° ° ° + v <|Amazo…  Welcom…  Twitte…  …            |>


Your current tab has no more text space than any other open tab, perhaps isn't even visible in the tab chooser, and almost certainly doesn't have enough space to show the page title.

Regressing aspects of this:

* The ability to contextualize the current page/tab is removed. Rapidly shifting between tabs with a keyboard shortcut never reveals the page title, which -- believe it or not -- is actually sometimes useful, and is certainly much quicker than having to read the page to find out what's going on.

* The ability to contextualize the current *window* is removed. There's now no title for a Firefox window! Instead I have a stream of bug numbers and fragments of letters near where a title normally is. My ability to Cmd-~ between windows, scanning the titles -- "oh, that's an l10n bug, this is my l10n bug window" -- has been totally removed.


In short: at the risk of sounding all ZOMG CHANGE, this seems like a useful affordance has been removed to save vertical space.

Can we allow this to be customized, so that I can save my vertical space with Vertical Tabs and buy myself a page title again?
Does setting browser.tabs.drawInTitlebar to false give you what you need?
Flags: needinfo?(rnewman)
Yes it does. Thank you!

So then:

* Can we make that more visible than an about:config entry? I poked around in the very prominent Customize menu, but couldn't find anything.

* Is there a way to make it *directly* discoverable? What do users do when they say "gah, this horrible new Firefox version won't show me my title, ZOMG CHANGE"?
Flags: needinfo?(rnewman)
Or perhaps a SUMO page is the answer?
Don't I recall you sharing similar inclinations as comment 2's second point? Or was that for something else?
Flags: needinfo?(shorlander)
The tabs bit touches on bug 658467, but I tend to think the title-in-the-tab has long been a bit of a lost cause... We can tweak it, but unless you go with giant Safari-style tabs, you're still only going to improve "Amazo…" to the nearly-equally-useless "Amazon.com: Nove…".

Mobile got away with replacing the URL with the page title, but I'm afraid to even consider the flamewars from trying that on desktop. :/

So I think this bug distills down to wanting a titlebar again. Note that this is only novel for OS X -- Windows got rid of the text titlebar quite some time ago. Also note that current versions of IE and Chrome also have no window title.

I've been meaning to try a hack/addon to restore titlebar text, but with a much much smaller and non-obtrusive size. But then I realize I only really miss it on Bugzilla, and never get around to it.
Dupe of bug 924888?
I don't think it's an exact dupe, no. I think bug 924888 is about the min-width of the tabs and the tab labels being truncated. I think this one is the missing titlebar.
Clarifying bug name so people don't mistake it for one about tabs.

Sidenote:

I didn't mention in my original comment, only in an earlier bug, but I usually prefer to use Vertical Tabs.

Might I suggest that we default to showing the page title in the window title bar if the tab strip is hidden? Doesn't solve the general user's grab handle issues, but it sure would solve mine.
Hardware: x86_64 → All
Summary: Australis doesn't display current page title usefully if tabs are small → Australis doesn't display current page title in window titlebar
(In reply to Richard Newman [:rnewman] from comment #8)
> Might I suggest that we default to showing the page title in the window
> title bar if the tab strip is hidden?

Already the case:
http://hg.mozilla.org/mozilla-central/annotate/c335eaa4494a/browser/base/content/tabbrowser.xml#l3518

Sounds like Vertical Tabs needs an update.
(In reply to Dão Gottwald [:dao] from comment #9)
> Sounds like Vertical Tabs needs an update.

It definitely does. Seems like we should flip 'browser.tabs.drawInTitlebar' when VT is enabled.

Note that VT doesn't hide the tab strip, it just moves and restyles it.
FWIW this makes using websites such as Bugzilla extremely painful...  If you pay attention to this screenshot for example <http://grab.by/scc8>, the only useful information in the title bar is the favicon for pages.  I'm not sure what the point of showing the first 6-7 letters of a website title is.
I really hope this bug has better luck than https://bugzilla.mozilla.org/show_bug.cgi?id=583905

If OS X does get it back, could you please fix the Win bug linked above as well please ;-)
(In reply to Philipp von Weitershausen [:philikon] from comment #10)
> (In reply to Dão Gottwald [:dao] from comment #9)
> > Sounds like Vertical Tabs needs an update.
> 
> It definitely does. Seems like we should flip 'browser.tabs.drawInTitlebar'
> when VT is enabled.
> 

Regardless of VT, I think turning off browser.tabs.drawInTitlebar should be (at the very least) exposed as an option in the Preferences dialog (either the General or Tabs panels, I guess), not hidden in about:config.

I've been using a Nightly with Australis for the last few days, and have found this aspect of the new UI -extremely- annoying. (I know I can toggle the pref, but I doubt I'm alone in finding it a disturbing change, and we can't expect the average user to go delving in about:config if they dislike the update.)
Just how useless is the page title displayed in the tab? Well...right here on a Bugzilla page, for example, my active tab can't even display the full 6-digit bug number; it's truncated to "9400…". Inactive tabs can manage six digits ("941470…"), though once we reach bug 1000000 (not long now...) even inactive tabs will lose their last digit.
Whiteboard: [Australis:P5]
Piling up. I don't have the issue on Linux, but on Mac it definitely is. The use case has been made already in the comments. And yes I'm having it with bugzilla tabs right now, like in comment 14
Depends on: 943375
Seeing no obvious activity here, I'm posting a patch to turn the pref off by default on OS X, as this would at least address the most immediate usability concern here (as well as mitigating bug 941096, incidentally). I don't know what UX will decide about the design in the longer term, but for the time being I think we need to do -something- here to work around the issues with the current implementation.
Attachment #8341330 - Flags: review?(gavin.sharp)
(In reply to Jonathan Kew (:jfkthame) from comment #16)
> Seeing no obvious activity here, I'm posting a patch to turn the pref off by
> default on OS X, as this would at least address the most immediate usability
> concern here (as well as mitigating bug 941096, incidentally). I don't know
> what UX will decide about the design in the longer term, but for the time
> being I think we need to do -something- here to work around the issues with
> the current implementation.

We are looking into this. In the meantime people can flip the about:config pref if they want.
Assignee: nobody → shorlander
Flags: needinfo?(shorlander)
Comment on attachment 8341330 [details] [diff] [review]
turn off browser.tabs.drawInTitlebar by default on Mac OS X due to usability concerns.

I concur; this isn't a critical enough issue to warrant short-term hacks.
Attachment #8341330 - Flags: review?(gavin.sharp) → review-
(In reply to comment #17)
> (In reply to Jonathan Kew (:jfkthame) from comment #16)
> > Seeing no obvious activity here, I'm posting a patch to turn the pref off by
> > default on OS X, as this would at least address the most immediate usability
> > concern here (as well as mitigating bug 941096, incidentally). I don't know
> > what UX will decide about the design in the longer term, but for the time
> > being I think we need to do -something- here to work around the issues with
> > the current implementation.
> 
> We are looking into this. In the meantime people can flip the about:config pref
> if they want.

FWIW bug 942179 makes that impossible at least for me.
As discussed at the work week, we can add a UI pref to toggle the drawInTitlebar pref.
Assignee: shorlander → nobody
Component: Untriaged → Theme
OS: Mac OS X → All
Whiteboard: [Australis:P5] → [Australis:P2]
P1 because strings.
Summary: Australis doesn't display current page title in window titlebar → Offer UI pref to toggle titlebar back on
Whiteboard: [Australis:P2] → [Australis:P1]
Whiteboard: [Australis:P1] → [Australis:P1][strings]
Assignee: nobody → shorlander
Status: NEW → ASSIGNED
Expecting a design from Shorlander for this shortly, which will include a string, but given the urgency, I will suggest:

"Show Title Bar"
Attached image Where to put the pref
Since we have that nice control for showing/hiding toolbars now, that seems like a natural place to put this option as well.
(In reply to Philipp Sackl [:phlsa] from comment #23)
> Created attachment 8362584 [details]
> Where to put the pref
> 
> Since we have that nice control for showing/hiding toolbars now, that seems
> like a natural place to put this option as well.

The title bar isn't a toolbar, in case you're suggesting we add it to that dropdown.
(In reply to Dão Gottwald [:dao] from comment #24)
> (In reply to Philipp Sackl [:phlsa] from comment #23)
> > Created attachment 8362584 [details]
> > Where to put the pref
> > 
> > Since we have that nice control for showing/hiding toolbars now, that seems
> > like a natural place to put this option as well.
> 
> The title bar isn't a toolbar, in case you're suggesting we add it to that
> dropdown.

From the user's perspective I think it's close enough. I think putting it at the top with a separator below it would be enough of a distinction.
Depends on: 964300
(In reply to Philipp Sackl [:phlsa] from comment #23)
> Created attachment 8362584 [details]
> Where to put the pref
> 
> Since we have that nice control for showing/hiding toolbars now, that seems
> like a natural place to put this option as well.

Note also that this dropdown is hidden by default on OS X (as it only has the bookmarks toolbar, which can be toggled elsewhere already - per explicit request in the relevant bug which I don't have to hand).


Separately, it's now 1 week until 29 merges, and this has strings impact, as well as a bunch of unknowns about how this will work if users are toggling things from within customize mode (id est, it is quite risky). So, it'd be really great if we had more information about how this should be implemented soon. :-)
So is Australis going to ride the FF29 train to Aurora (and thence Beta and Release), or are we holding it back for another cycle?

If we aren't going to have a proper UI solution in place by the time Australis moves from Nightly towards the release channels, then IMO we should at least take the trivial patch here that changes the default setting, so as to reduce the disruption for users.

(Actually, I think we should toggle the default even if we do have that UI pref implemented; leave it for users to choose the more radical/disruptive option if they wish, instead of pushing it on them so that they have to discover how to opt out if they dislike it.)
Rather than the hard-to-find Toolbars dropdown, how about adding an item to the top-level View menu? This seems to me perhaps the easiest place for users to find it. (See attached screenshot.)
(In reply to Jonathan Kew (:jfkthame) from comment #28)
> Created attachment 8366061 [details]
> Screen Shot 2014-01-27 at 17.40.09.png
> 
> Rather than the hard-to-find Toolbars dropdown, how about adding an item to
> the top-level View menu? This seems to me perhaps the easiest place for
> users to find it. (See attached screenshot.)

That menu is hidden for a significant number of our users (Win > XP, Linux).
Depends on: 941831
Mockup up for adding a Title Bar toggle to the options footer. (Please ignore everything besides the footer ;))

Some of these might need to be separate bugs (?):

* Adds a Title Bar toggle before the Toolbars dropdown
  - Icon + "Show Title Bar" text while title bar is off
  - Icon + "Hide Title Bar" text when title bar is toggled on

* Add subtle visual differentiation for the options footer to separate it from the customizable UI
Assignee: nobody → gijskruitbosch+bugs
This implements the mockup. I've left out two things: one, I've not changed the label for the toolbars item. That was decided with UX input, and I don't know if changing it was actually desired or not. Stephen? Second, I've not changed the dropdown icon in the same button to match the mockup, because (a) I don't think we have a fitting icon, and (b) that seemed not to be necessary for this bug. If necessary we can deal with stuff in followups.
Attachment #8367392 - Flags: review?(jaws)
Styling the button pressed and changing the string at the same time is confusing. The button states act like a checkbox (and we actually have <button type="checkbox"> for that, which should probably be used here), so you basically end up with something like that:

[ ] Show Title Bar

[x] Hide Title Bar
Comment on attachment 8367392 [details] [diff] [review]
offer UI option in Australis' customization mode to toggle titlebar,

Review of attachment 8367392 [details] [diff] [review]:
-----------------------------------------------------------------

Please change to use <button type="checkbox"/> like Dao said.

::: browser/components/customizableui/src/CustomizeMode.jsm
@@ +994,5 @@
> +
> +  _updateTitlebarButton: function() {
> +    let drawInTitlebar = true;
> +    try {
> +      drawInTitlebar = Services.prefs.getBoolPref(kDrawInTitlebarPref);

Why do we need to guard getBoolPref here?
Attachment #8367392 - Flags: review?(jaws) → review+
This time with a single label and type='checkbox'
Attachment #8367457 - Flags: review?(jaws)
Attachment #8367392 - Attachment is obsolete: true
Oh, also, I had to add the define to the browser/components/customizableui/src/moz.build . Apparently defines aren't propagated to subdirs - having it higher up, or unifying with the one in browser/base/moz.build by putting it in browser/moz.build didn't work. Don't know why, didn't want to have it hold up this bug, but if someone can elucidate me that would be appreciated.
Comment on attachment 8367457 [details] [diff] [review]
offer UI option in Australis' customization mode to toggle titlebar,

Review of attachment 8367457 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/moz.build
@@ +34,5 @@
>  
>  if CONFIG['MOZ_WIDGET_TOOLKIT'] in ('windows', 'gtk2', 'gtk3'):
>      DEFINES['MENUBAR_CAN_AUTOHIDE'] = 1
>  
> +JAR_MANIFESTS += ['jar.mn']

What changed here? I'm guessing a newline was added?
Attachment #8367457 - Flags: review?(jaws) → review+
(In reply to Jared Wein [:jaws] from comment #41)
> Comment on attachment 8367457 [details] [diff] [review]
> offer UI option in Australis' customization mode to toggle titlebar,
> 
> Review of attachment 8367457 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/base/moz.build
> @@ +34,5 @@
> >  
> >  if CONFIG['MOZ_WIDGET_TOOLKIT'] in ('windows', 'gtk2', 'gtk3'):
> >      DEFINES['MENUBAR_CAN_AUTOHIDE'] = 1
> >  
> > +JAR_MANIFESTS += ['jar.mn']
> 
> What changed here? I'm guessing a newline was added?

Yup.

remote:   https://hg.mozilla.org/integration/fx-team/rev/481cc4221926


Stephen, can you file followup bugs once this is in Nightly, in terms of what still needs adjusting style-wise? I'm not sure how important the toolbars label and/or the dropdown marker there are, or if I've missed anything else (or got something dramatically wrong). Thanks!
Flags: needinfo?(shorlander)
Attachment #8367457 - Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/481cc4221926
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
This is very nice, I like it.
However, as I'm looking at this, I can't figure out, why is that you can re-add the Title Bar, but not the Add-on Bar, even though the Add-on Bar is used by more people, or at the very least is more useful?

On a related-to-the-bug note, I think the "Title Bar" button shown on the bottom left should be moved into the "Show/Hide Toolbars" drop-down menu, as it corresponds better with the "show less chrome" philosophy of Australis that way, and should be changed to a checkbox, so it looks more like a switch for toggling something rather than just a button.
Depends on: 966678
Depends on: 973694
QA Contact: cornel.ionce
Verified as fixed on latest Aurora (build ID: 20140309004003) using Windows 7 64 bit and Mac OS X 10.9.
The titlebar can now be toggled.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0		
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0
Status: RESOLVED → VERIFIED
Depends on: 1302759
You need to log in before you can comment on or make changes to this bug.