Status

()

defect
P5
normal
RESOLVED DUPLICATE of bug 1283299
6 years ago
2 years ago

People

(Reporter: marco, Unassigned)

Tracking

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
It should be just a matter of setting the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property.
(Reporter)

Updated

6 years ago
Blocks: 513159
I was wondering why this would be a per-application property rather than a window manager configuration.  [1] explains that an application may use the titlebar to convey useful information.  We don't have to worry about that in Firefox because the information is duplicated in the tab.

I wonder whether window managers will provide different UI for restore/minimize/close/window-menu, or if applications are expected to provide that.

It seems [2] that chromium now only sets _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED when using its custom frame, which I guess provides some window controls.
I skimmed that bug but didn't work out what "when the user explicitly
wanted it" meant.  Perhaps that was something to do with themes, or window manager configuration.

[1] https://git.gnome.org/browse/gtk+/commit/gdk/x11?id=4f8f8fe828dbb5b1a2e54a26a58149e437cd5820
[2] http://code.google.com/p/chromium/issues/detail?id=137447
(Reporter)

Comment 2

6 years ago
(In reply to Karl Tomlinson (:karlt) from comment #1)
> I was wondering why this would be a per-application property rather than a
> window manager configuration.  [1] explains that an application may use the
> titlebar to convey useful information.  We don't have to worry about that in
> Firefox because the information is duplicated in the tab.

Yes, I agree.
I've been using Firefox without a titlebar on GNOME Shell and I feel like nothing is missing.

> I wonder whether window managers will provide different UI for
> restore/minimize/close/window-menu, or if applications are expected to
> provide that.

I think that depends. For example on Unity you get the controls in the top-left corner, in GNOME Shell there are no controls when the window is maximized.
(Reporter)

Comment 3

6 years ago
http://blogs.gnome.org/mclasen/files/2013/08/headerbar.png

Looks like for some GNOME applications they've decided to use header bars for maximized windows: http://blogs.gnome.org/mclasen/2013/08/23/gnome-3-10-sightings/
Since gdk_x11_window_set_hide_titlebar_when_maximized is in gtk3 only, this can be depend on 627699.
Depends on: gtk3

Comment 5

6 years ago
Note that not all people who use GTK3 also use GNOME.
GTK3 is not GNOME3!

Some people will use Firefox with GTK3 on GNOME.
Others will use it on Unity, Cinnamon, MATE, KDE, LXDE, Xfce, Openbox, etc.
(In reply to Eldmannen from comment #5)
> Note that not all people who use GTK3 also use GNOME.
> GTK3 is not GNOME3!
> 
> Some people will use Firefox with GTK3 on GNOME.
> Others will use it on Unity, Cinnamon, MATE, KDE, LXDE, Xfce, Openbox, etc.

Sure. By documentation [1] the gdk_x11_window_set_hide_titlebar_when_maximized only set a hint for window manager to hide titlebar. It's up to window manager how it handles this request. At least I hope so.

[1] https://developer.gnome.org/gdk3/3.4/gdk3-X-Window-System-Interaction.html#gdk-x11-window-set-hide-titlebar-when-maximized
(Reporter)

Comment 7

6 years ago
(In reply to jhorak from comment #4)
> Since gdk_x11_window_set_hide_titlebar_when_maximized is in gtk3 only, this
> can be depend on 627699.

Actually we could set the hint manually with GTK2.
No longer depends on: gtk3

Comment 8

5 years ago
Can blocks 627699 ?
(Reporter)

Comment 9

5 years ago
Posted patch WIPSplinter Review
Attachment #8415888 - Flags: feedback?(karlt)
Comment on attachment 8415888 [details] [diff] [review]
WIP

This could be the best approach available, but it could have some awkward
consequences.

One difficult thing is that the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property has
no corresponding way to detect whether the window manager will honour this, so
it is hard to know whether to show a titlebar or not.  This could lead to 2
titlebars being shown.

  I wondered about using MWM_DECOR_TITLE (aka GDK_DECOR_TITLE) instead as that
  is likely more widely supported, but GDK docs say "The hint must be set
  before mapping the window" and I don't know that it would be a good idea to
  unmap and re-map the window every time it is maximized or restored.

  If browser.tabs.drawInTitlebar is set then perhaps it is not a big problem
  if there are extra close/restore/minimize buttons, because the extra
  titlebar will still serve a purpose.  However if drawInTitlebar is not set
  then there could end up being two mostly empty titlebars.  Is this
  preference exposed in the UI?  Perhaps window managers known to support
  _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED can be detected individually and the
  client-side title bar only added there, or perhaps the preference can be
  used to decide whether to show a titlebar.

Another difficulty is that this is removing the titlebar from all maximized
windows (on some systems), but only adding buttons to the browser main window.
There are other toplevel windows such as the "Library" (History) window, and
other non-browser applications.

  It seems there should be a way to specify that the title bar is hidden, and
  only specify this on windows which will provide their own buttons.

  I don't know whether other platforms have an existing means to indicate
  which windows will have system-drawn title bars, or whether they are always
  client-drawn.  Even if they have a means, I guess this may not depend on
  maximized state, so a new mechanism may be required.  Or perhaps
  hidechrome/nsIWidget::HideWindowChrome() is suitable.

There are many problems with client side decorations [1].  These may not
matter so much if only applied to maximized windows because the user can at
least restore the window to get all the functionality back.  However, if some
platforms don't have context menus on the decorations etc., perhaps an
alternative to consider might be to use client side decorations only on these
platforms so that this need not depend on whether the window is maximized.

[1] http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/

> #ifdef CAN_DRAW_IN_TITLEBAR
>-#ifdef XP_WIN
>+#ifdef XP_MACOSX
>+        chromemargin="0,-1,-1,-1"
>+#else
>         chromemargin="0,2,2,2"
>-#else
>-        chromemargin="0,-1,-1,-1"
> #endif
>         tabsintitlebar="true"
> #endif

What is the purpose of the 2s here?

>+#main-window[tabsintitlebar][sizemode="maximized"] > #titlebar {
>+  -moz-appearance: -moz-window-titlebar;
>+  min-height: calc(@tabMinHeight@ + 9px - @tabToolbarNavbarOverlap@);
>+}
>+
>+#main-window[tabsintitlebar][sizemode="normal"] > #titlebar {
>+  display: none;
>+}

Is there a titlebar when tabsintitlebar is unset?

What ensures that tabs are not in the hidden titlebar when not maximized?

I don't know what the 9px here represents, but better to get a front end
person to review these changes - perhaps Dão.

>+  case NS_THEME_WINDOW_TITLEBAR:
>     return !IsWidgetStyled(aPresContext, aFrame, aWidgetType);

DrawWidgetBackground() should support this drawing if ThemeSupportsWidget()
can return true.  I don't know that DrawWidgetBackground() knows what to do
here.

>+    guint32 hide = 1;

"If the specified format is 32, the property data must be a _long_ array."
That makes a difference on big endian systems with 64-bit longs.

>+                    (guchar*)&hide,

Please use unsigned char* for Xlib parameters.

This property should be set only on toplevel, non-popup windows.
Attachment #8415888 - Flags: feedback?(karlt) → feedback+
What about adding "hidechromewhenmaximized" attribute to windows? It shouldn't broke anything, but it can help to add-ons authors.

I just copy/pasted "hidechrome" attribute and added logic for setting "_GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED" property to "nsWindow::HideWindowChromeWhenMaximized" method. I am not sure, that it works correctly with no-gtk builds.

// Sorry for my bad English.
Any plan to continue this? I think adding a pref to switch this feature is enough to address the difficulity mentioned in comment 10. I guess most systems should work fine, and we can suggest the users who do use an odd system to switch off this pref themselves.
Flags: needinfo?(mar.castelluccio)
(Reporter)

Comment 13

4 years ago
I don't have time to work on this right now.
Flags: needinfo?(mar.castelluccio)
Gtk3 provides gtk_window_set_hide_titlebar_when_maximized() and even gtk_window_set_titlebar/gtk_window_get_titlebar for this.
Priority: -- → P5
Whiteboard: tpi:+
Let's target his at Bug 1283299.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: gtktitlebar
You need to log in before you can comment on or make changes to this bug.