After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 770513 - MainToolbar in full-screen mode has rounded corners, which show video pixel bleed-thru underneath it
MainToolbar in full-screen mode has rounded corners, which show video pixel b...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Themes
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-08-28 13:19 UTC by Daniel Boles
Modified: 2017-05-31 18:12 UTC
See Also:
GNOME target: ---
GNOME version: 3.19/3.20


Attachments
screenshot demonstrating issue (870.61 KB, image/png)
2016-08-28 13:39 UTC, Daniel Boles
  Details
CSS Selector info for the TotemMainToolbar in fullscreen/overlay mode (23.66 KB, image/png)
2016-09-25 18:07 UTC, Daniel Boles
  Details
themes: Square corners on fullscreen win headerbar (1.72 KB, patch)
2017-05-27 12:52 UTC, Daniel Boles
none Details | Review

Description Daniel Boles 2016-08-28 13:19:47 UTC
In which case, as seen in the attached screenshot, when in full screen, the TotemMainToolbar is made into a pop-down widget, for revealing its controls on-demand. This toolbar has rounded corners, which in full-screen mode:

 (A) seems to contradict what happens with e.g. partially tiled windows and full-screened windows' titlebars - I would expect any such 'top bar' to be fully square in such a case, and anyway:
 (B) in this implementation, having rounded corners looks very bad with certain videos - i.e. those whose non-black content extends right to the top-left/-right corners - because the Toolbar is just overlaid above the video content, leaving said content to 'bleed through' and show in the transparent pixels at the corners

Can the Toolbar be made square in full-screen mode? (That seems preferable to e.g. keeping it round but artificially blacking out the pixels of the video below it.)

HTH and thanks.
Comment 1 Daniel Boles 2016-08-28 13:23:09 UTC
possibly related bug discussing expectation of non-rounded corners in maximised/fullscreen modes
https://bugzilla.gnome.org/show_bug.cgi?id=765038

... note however that if you have the Top Bar visible (which I normally do not, but tested both for this report), in the maximised case the window _seems_ to be rounded because it is stacked underneath the corners of the top bar. I'm not certain whether that's intentional as it seems kinda weird to me,
Comment 2 Daniel Boles 2016-08-28 13:39:42 UTC
Created attachment 334309 [details]
screenshot demonstrating issue

I tried to find something that wasn't stupid, but
Comment 3 Bastien Nocera 2016-09-16 15:44:09 UTC
I can't reproduce this. Does this still happen? Please state the exact versions used.
Comment 4 Daniel Boles 2016-09-16 18:24:11 UTC
(In reply to Bastien Nocera from comment #3)
> I can't reproduce this. Does this still happen? Please state the exact
> versions used.

Thanks for the reply. It does still happen for me. The totem package is:
> 100354 Sep  4 15:53 /var/cache/apt/archives/totem_3.21.91-1_amd64.deb

what other versions do you want? Do you need any hardware info? If so, let me know what to run, and I'll add it here.
Comment 5 Daniel Boles 2016-09-21 20:17:32 UTC
This still happens on 3.22.

I couldn't get it to replicate initially and then, after some luck, figured out why: The problem with the round corners and content bleedthru ALWAYS happens if you maximise by double-clicking on the video content. If you maximise by double-clicking on the headerbar, then SOMETIMES corners are square as they should be.

Hope this helps debug it?
Comment 6 Daniel Boles 2016-09-21 20:29:33 UTC
Sorry, never mind. Of course those do 2 different things:
 * double clicking on the titlebar maximises the window
 * double clicking on the content puts the app into fullscreen mode

So I confirm the bug IS present on fullscreen views, but not on maximise (regardless of how either is achieved).
Comment 7 Daniel Boles 2016-09-25 08:26:17 UTC
On my system this can be fixed by adding this CSS rule in the Inspector:

  overlay headerbar {
      border-radius: 0;
  }

(I'm sure this should probably be made more specific, but for the purposes of proving the concept, it does the trick.)

Then the HeaderBar has square corners in maximised mode as it should.
Comment 8 Daniel Boles 2016-09-25 08:34:03 UTC
CCing Lapo as this seems to be the weekend where he discovers all the weird CSS things :)
Comment 9 Daniel Boles 2016-09-25 18:07:14 UTC
Created attachment 336228 [details]
CSS Selector info for the TotemMainToolbar in fullscreen/overlay mode

This should be useful in figuring out a CSS fix, whether it's on the Totem side or Adwaita generally.

The latter assumes my overlay headerbar selector is not too broad - does it make sense to have a HeaderBar within an Overlay that's _not_ fullscreen? I dunno.

This should be text, but the Inspector doesn't currently allow copying that (so I filed bug 771950)... I might transcribe it later.
Comment 10 Daniel Boles 2016-09-25 18:10:49 UTC
Other possible solutions off the top of my head:

 * just give the MainToolbar the "titlebar" class - assuming that won't come with unwanted effects.

 * select on .fullscreen headerbar, or .fullscreen overlay headerbar, or etc. - assuming these aren't too broad and wouldn't wreck headerbars elsewhere that _should_ be round.
Comment 11 Daniel Boles 2016-10-03 19:52:30 UTC
btw, this doesn't happen if you first tile or maximise the window, as then it gets the appropriate styles for square corners and when fullscreened, the header bar looks ok.

it's only if the window is non-maximised and non-tiled first, then fullscreened up - then the corners are rounded off when they shouldn't be.

basically, the headerbar's corners don't change between normal and fullscreen modes, so they pick up whatever the window had before it was fullscreened.
Comment 12 Daniel Boles 2017-05-18 18:58:15 UTC
Having actually looked into the code now, I see two obvious ways around this:

 * Just make Totem put the .maximized class on the window when entering fullscreen mode (from a not-already-maximized state) and remove when leaving

 * or update GTK+ itself so the themes also select on window.fullscreen headerbar to apply border-radius: 0

Which do you want? I'll provide a patch for either.
Comment 13 Daniel Boles 2017-05-27 12:52:50 UTC
Created attachment 352687 [details] [review]
themes: Square corners on fullscreen win headerbar

Totem uses a fullscreen window with a headerbar at the top, and without
this change, that headerbar has rounded corners, which look different
from a maximised window and let video content show through beneath.
Comment 14 Lapo Calamandrei 2017-05-30 22:09:43 UTC
Sorry, the bugmail got lost in the noise for this one, yep, totally a theme fault, the patch looks good also (modulo the missing generated css), feel free to push in case you have commit rights.
Comment 15 Daniel Boles 2017-05-31 07:19:25 UTC
Thanks - done!

https://git.gnome.org/browse/gtk+/commit/?id=796f9b5bfb0f356b06515d25203e3bcd00c80687

For HighContrast I had to restore the parse files from gtk-3-22; I think they probably need updated to match Adwaita:

https://git.gnome.org/browse/gtk+/commit/?id=fc96fce4624b7a50a395fb17831126350754c783
Comment 16 Daniel Boles 2017-05-31 07:40:28 UTC
Hm, I may have to reopen this, as on a super quick test it didn't seem to work. When I have more time I'll make sure I built and linked the right thing. :S
Comment 17 Daniel Boles 2017-05-31 17:38:37 UTC
The problem is the presence of a stack between the window and headerbar nodes, which causes the rule for that case (on line 669 of gtk-contained-dark.css) to kick in, which includes 7px borders at top-left and top-right:

https://git.gnome.org/browse/gtk+/tree/gtk/theme/Adwaita/gtk-contained-dark.css?h=gtk-3-22#n669

Lapo, what would be your preferred way to ensure we get enough specificity to apply the 0 radius borders in this case?
Comment 18 Daniel Boles 2017-05-31 17:41:51 UTC
/reminds self to read for a minute more before posting

It just needs another exclusion added for :not(.fullscreen)
Comment 19 Lapo Calamandrei 2017-05-31 17:51:57 UTC
:-)
Comment 20 Daniel Boles 2017-05-31 18:12:29 UTC
https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=385057414669d660e0fa92eb8a809f7cbcfea6d2

> Adwaita: Add missing rule for fullscreen headerbar
> 
> Another selector forces round corners for headerbars in a stack, and it has
> higher priority than the selector covering the non-stack case from commit
> 712a8adbd9a11fcebce0269562e9a028a17fa862. Totem’s MainToolbar happens to be in a
> stack, and we should maintain symmetry here anyway. So, as window classes
> .maximized and .tiled are excluded from this other selector, the newly handled
> .fullscreen case must be excluded here also.