1400057 - [10.13] Left portion of browser window is white in the upper corner

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[Marcia Knous [:marcia]]

Attachment: Screenshot of issue on latest Mac 10.13 nightly

Seen while running Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0, 20170914100122

I just noticed this when I switched from a light theme to a dark theme. Does not reproduce on 10.12 using latest nightly

Screenshot attached.

Comment 1

[Stephen A Pohl [:spohl] (OOO until 9/9)]

Does this persist after a restart of Firefox?

Comment 2

[Marcia Knous [:marcia]]

(In reply to Stephen A Pohl [:spohl] from comment #1)
> Does this persist after a restart of Firefox?

Yes, and it occurs using a new profile as well.

Comment 3

[Marcia Knous [:marcia]]

I just updated to 17A362a and I don't see this issue any more using the same Nightly profile, and 20170915100121. Resolving as WFM for the time being.

Comment 4

[Marcia Knous [:marcia]]

(In reply to Marcia Knous [:marcia - use ni] from comment #3)
> I just updated to 17A362a and I don't see this issue any more using the same
> Nightly profile, and 20170915100121. Resolving as WFM for the time being.

Reopening - while it doesn't happen on my existing profile, it can be seen with a newer profile using 20170918100059. So still an issue.

The other thing to mention is I now it on both sides of the browser corner, using the dark theme.

Comment 5

[Stephen A Pohl [:spohl] (OOO until 9/9)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a72326b22b16d3266a9c9595c093758d15576e89

Comment 6

[Stephen A Pohl [:spohl] (OOO until 9/9)]

Marcia, could you test this again with the try build from comment 5 once it becomes available? I haven't been able to reproduce the issue reported in this bug, but believe that the build from try should fix it. Thank you!

Comment 7

[Stephen A Pohl [:spohl] (OOO until 9/9)]

Attachment: Patch

This patch hides titlebars when necessary. One example where the effects of this change can be seen is when returning from native fullscreen mode. Steps:
1. Click the green fullscreen button in the top left corner of the browser window.
2. Move the mouse towards the top of the screen to reveal the native titlebar.
3. Click on the green button again to exit native fullscreen mode.

Before this patch, the native titlebar would now show on top of the tabs. This change properly hides the titlebar again. I believe this same change may fix the bug reported here. If not, I will move this patch into a separate bug and land there.

Comment 8

[Markus Stange [:mstange]]

Comment on attachment 8909811 [details] [diff] [review]
Patch

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

::: widget/cocoa/nsCocoaWindow.mm
@@ +3157,5 @@
>      [self reflowTitlebarElements];
>      if (nsCocoaFeatures::OnYosemiteOrLater()) {
>        [self setTitleVisibility:mDrawsIntoWindowFrame ? NSWindowTitleHidden :
>                                                         NSWindowTitleVisible];
> +      [self setTitlebarAppearsTransparent:mDrawsIntoWindowFrame ? YES : NO];

let's make this just
[self setTitlebarAppearsTransparent:mDrawsIntoWindowFrame];

Comment 9

[Stephen A Pohl [:spohl] (OOO until 9/9)]

Attachment: Patch

Thank you for the fast review! Addressed feedback, carrying over r+. Waiting to see if the issue here is fixed before landing with this bug number.

Comment 10

[Stephen A Pohl [:spohl] (OOO until 9/9)]

This should track for 57.

Comment 11

[Marcia Knous [:marcia]]

(In reply to Stephen A Pohl [:spohl] from comment #6)
> Marcia, could you test this again with the try build from comment 5 once it
> becomes available? I haven't been able to reproduce the issue reported in
> this bug, but believe that the build from try should fix it. Thank you!

Stephen: I just tested the debug build in Comment 5 and I still see the issue using the default theme.

STR:
1. Download try build
2. Launch with a new profile
3. On both sides of the browser, the white portion is visible in the upper corner.

When I switch to the dark theme, I don't see the issue.

Comment 12

[Stephen A Pohl [:spohl] (OOO until 9/9)]

(In reply to Marcia Knous [:marcia - use ni] from comment #11)
> (In reply to Stephen A Pohl [:spohl] from comment #6)
> > Marcia, could you test this again with the try build from comment 5 once it
> > becomes available? I haven't been able to reproduce the issue reported in
> > this bug, but believe that the build from try should fix it. Thank you!
> 
> Stephen: I just tested the debug build in Comment 5 and I still see the
> issue using the default theme.
> 
> STR:
> 1. Download try build
> 2. Launch with a new profile
> 3. On both sides of the browser, the white portion is visible in the upper
> corner.
> 
> When I switch to the dark theme, I don't see the issue.

Thanks for testing. Could you point me to exactly what light theme you're using?

Comment 13

[Stephen A Pohl [:spohl] (OOO until 9/9)]

(In reply to Stephen A Pohl [:spohl] from comment #12)
> Thanks for testing. Could you point me to exactly what light theme you're
> using?

If this is referring to the built-in themes, I'm still unable to reproduce unfortunately...

Comment 14

[Marcia Knous [:marcia]]

(In reply to Stephen A Pohl [:spohl] from comment #12)
> (In reply to Marcia Knous [:marcia - use ni] from comment #11)
> > (In reply to Stephen A Pohl [:spohl] from comment #6)
> > > Marcia, could you test this again with the try build from comment 5 once it
> > > becomes available? I haven't been able to reproduce the issue reported in
> > > this bug, but believe that the build from try should fix it. Thank you!
> > 
> > Stephen: I just tested the debug build in Comment 5 and I still see the
> > issue using the default theme.
> > 
> > STR:
> > 1. Download try build
> > 2. Launch with a new profile
> > 3. On both sides of the browser, the white portion is visible in the upper
> > corner.
> > 
> > When I switch to the dark theme, I don't see the issue.
> 
> Thanks for testing. Could you point me to exactly what light theme you're
> using?

The theme it can be seen with is the "Default theme" by Mozilla. I also use "Dark Theme" and "Light Theme" by Mozilla, but it works OK with those themes.

Comment 15

[Stephen A Pohl [:spohl] (OOO until 9/9)]

(In reply to Marcia Knous [:marcia - use ni] from comment #14)
> The theme it can be seen with is the "Default theme" by Mozilla. I also use
> "Dark Theme" and "Light Theme" by Mozilla, but it works OK with those themes.

Unfortunately, I'm unable to reproduce with that theme. Does this reproduce on other systems, or only this particular one? Could you maybe post a screencast that shows the issue?

Comment 16

[Marcia Knous [:marcia]]

I only have on machine running 10.13 at the moment. Another user in Bug 1401175 also reported seeing it. We can ni on Softvision to see if they can reproduce it as well on their 10.13 machine.

I can try a screencast - will have to get something to record my screen.

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

I see this also with the Default Theme, and Normal + Compact densities.

Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0

Comment 18

[Oana Botisan, Desktop QA]

I managed to reproduce the problem with the white corners on both sides when the browser has the default theme by using the latest Nightly (2017-09-21) on macOS 10.13 (MacBook Pro). I have to mention that this is the way the browser opened with a clean profile. When you change the themes the problem disappears, but as soon as you select the default theme, the corners turn transparent again. Also there are two different colors that mark the top part of the browser. 

Also trying to reproduce this bug I've noticed another issue. The close ('x'), minimize '-' and maximize '<>' buttons are not perfectly round. This link https://docs.google.com/document/d/1OiLwz4x-YR9T4NeO-ErLWJn5mJr1_xBXNJagfWR--xw/edit# will show you the comparison between another window (left) and Firefox (right).This problem doesn't depend on any theme, but I believe that it appears because the default theme has two colors.

Comment 19

[Andrei Vaida [:avaida]]

(In reply to Oana Botisan from comment #18)
> I managed to reproduce the problem with the white corners on both sides when
> the browser has the default theme by using the latest Nightly (2017-09-21)
> on macOS 10.13 (MacBook Pro). I have to mention that this is the way the
> browser opened with a clean profile. When you change the themes the problem
> disappears, but as soon as you select the default theme, the corners turn
> transparent again. Also there are two different colors that mark the top
> part of the browser. 
> 
> Also trying to reproduce this bug I've noticed another issue. The close
> ('x'), minimize '-' and maximize '<>' buttons are not perfectly round. This
> link
> https://docs.google.com/document/d/1OiLwz4x-YR9T4NeO-ErLWJn5mJr1_xBXNJagfWR--
> xw/edit# will show you the comparison between another window (left) and
> Firefox (right).This problem doesn't depend on any theme, but I believe that
> it appears because the default theme has two colors.

Thank you for investigating this, Oana! Stephen, could you please take a look at Oana's notes?

Comment 20

[Marcia Knous [:marcia]]

(In reply to Stephen A Pohl [:spohl] from comment #10)
> This should track for 57.

Tracking 57+

Comment 21

[Stephen A Pohl [:spohl] (OOO until 9/9)]

I'm still unable to reproduce this. Does anyone have additional steps that could help reproduce this? Do you use internal or external monitors? I'm about to set up another macOS 10.13 system to try and reproduce there.

Comment 22

[Stephen A Pohl [:spohl] (OOO until 9/9)]

(In reply to Oana Botisan from comment #18)
> Also trying to reproduce this bug I've noticed another issue. The close
> ('x'), minimize '-' and maximize '<>' buttons are not perfectly round. This
> link
> https://docs.google.com/document/d/1OiLwz4x-YR9T4NeO-ErLWJn5mJr1_xBXNJagfWR--
> xw/edit# will show you the comparison between another window (left) and
> Firefox (right).This problem doesn't depend on any theme, but I believe that
> it appears because the default theme has two colors.

Filed bug 1402054.

Comment 23

[whmountains]

I have an external monitor, but the bug persists even I launch Firefox with my monitor disconnected.

I'm using a MacBook Pro 15" 2012 with a 2.6 GHz Intel Core i7  The resolution of the internal display is 1680 x 1050 (upgraded from default.)

Dual GPU:

* NVIDIA GeForce GT 650M 1 GB
* Intel HD Graphics 4000 1536 MB

I would test on a blank profile but I can't find any information on how to do that on mac.  Could someone point me in the right direction?

Comment 24

[charlie.siegel]

(In reply to Stephen A Pohl [:spohl] from comment #21)
> I'm still unable to reproduce this. Does anyone have additional steps that
> could help reproduce this? Do you use internal or external monitors? I'm
> about to set up another macOS 10.13 system to try and reproduce there.

I have a 5K iMac - it's just the internal monitor.  I don't have to do anything special to produce it.  A clean profile with the latest nightly makes it occur.  I'll attach my screenshot of what I'm seeing.  Does this bug cover both the white notches and grey bar?

Thanks

Comment 25

[charlie.siegel]

Attachment: nightly-title-bar.png

Comment 26

[Sören Hentzschel]

(In reply to Stephen A Pohl [:spohl] from comment #21)
> I'm still unable to reproduce this. Does anyone have additional steps that
> could help reproduce this? Do you use internal or external monitors? I'm
> about to set up another macOS 10.13 system to try and reproduce there.

The issue is always present with the default theme, not with the both other themes. The issue also disappears with the default theme after enabling the title bar and appears again after disabling the title bar.

It's a MacBook Pro Late 2013 with Retina display, no external monitor. Operating system is macOS 10.13 Beta.

Please note that the white corners are not the only problem, the full tab bar looks broken because the bottom has another color than the top. After enabling additional drag space it looks even more worse because the bottom of the three icons in the upper left corner is hidden.

Comment 27

[Marcia Knous [:marcia]]

(In reply to whmountains from comment #23)
> I have an external monitor, but the bug persists even I launch Firefox with
> my monitor disconnected.
> 
> I'm using a MacBook Pro 15" 2012 with a 2.6 GHz Intel Core i7  The
> resolution of the internal display is 1680 x 1050 (upgraded from default.)
> 
> Dual GPU:
> 
> * NVIDIA GeForce GT 650M 1 GB
> * Intel HD Graphics 4000 1536 MB
> 
> I would test on a blank profile but I can't find any information on how to
> do that on mac.  Could someone point me in the right direction?

https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles has instructions on how to manage profiles in Firefox.

Comment 28

[whmountains]

Thank you Marcia.  I can now confirm that the problem persists with a clean profile.

I also noticed this in Firefox's stdout:

*** WARNING: Textured window <ToolbarWindow: 0x10f648f80> is getting an implicitly transparent titlebar. This will break when linking against newer SDKs. Use NSWindow's -titlebarAppearsTransparent=YES instead.

Probably has nothing to do with the problem at hand, but it's there anyway.

Comment 29

[Stephen A Pohl [:spohl] (OOO until 9/9)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0ead0dc47fb96dc29d9b8f68f15729f6b43644a0

Comment 30

[Stephen A Pohl [:spohl] (OOO until 9/9)]

Comment on attachment 8909843 [details] [diff] [review]
Patch

This landed in bug 1401297 since it didn't fix the issue reported here.

Comment 31

[Stephen A Pohl [:spohl] (OOO until 9/9)]

I set up a new system and I'm finally able to reproduce at least some of the reported visual artifacts. Looking into it. One question for Sören:

(In reply to Sören Hentzschel from comment #26)
> The issue is always present with the default theme, not with the both other
> themes. The issue also disappears with the default theme after enabling the
> title bar and appears again after disabling the title bar.

What specifically do you mean by "enbaling and disabling the title bar"? What are the steps that you take to do this? Thanks!

Comment 32

[Sören Hentzschel]

Menu > Customize(In reply to Stephen A Pohl [:spohl] from comment #31)
> What specifically do you mean by "enbaling and disabling the title bar"?
> What are the steps that you take to do this? Thanks!

Menu button > Customize > check/uncheck the checkbox "Title Bar". With title bar the design looks different but doesn't have the problem.

Comment 33

[charlie.siegel]

I just wanted to let you know, I am still seeing this in the beta version of 57 & the shipping version of High Sierra.

Is this slated to be fixed prior the release of 57?

Comment 34

[Stephen A Pohl [:spohl] (OOO until 9/9)]

(In reply to charlie.siegel from comment #33)
> I just wanted to let you know, I am still seeing this in the beta version of
> 57 & the shipping version of High Sierra.
> 
> Is this slated to be fixed prior the release of 57?

This bug is still open, which means it isn't fixed and you will continue to see this bug. The bug is tracking for 57, which means that a fix will be uplifted to 57 if there is enough time left in the beta cycle.

Comment 35

[charlie.siegel]

(In reply to Stephen A Pohl [:spohl] from comment #34)
> (In reply to charlie.siegel from comment #33)
> > I just wanted to let you know, I am still seeing this in the beta version of
> > 57 & the shipping version of High Sierra.
> > 
> > Is this slated to be fixed prior the release of 57?
> 
> This bug is still open, which means it isn't fixed and you will continue to
> see this bug. The bug is tracking for 57, which means that a fix will be
> uplifted to 57 if there is enough time left in the beta cycle.

Thanks sounds good.  Sorry to bug you.  I'm new to reporting bugs, I just wasn't sure how this works.

Comment 36

[Stephen A Pohl [:spohl] (OOO until 9/9)]

(In reply to charlie.siegel from comment #35)
> Thanks sounds good.  Sorry to bug you.  I'm new to reporting bugs, I just
> wasn't sure how this works.

No worries at all. Happy to explain things and I appreciate your filing bugs against macOS 10.13 and Firefox! :-)

Comment 37

[Markus Stange [:mstange]]

Attachment: Bug 1400057 - Assemble vibrancy views in a container view that is placed below the window's content view, as a child view of the frame view.

This seems to avoid vibrancy glitches in the titlebar on 10.13.

These glitches seem to be caused by a combination of the following:
 - We're overriding methods on NSWindow that cause the window's contentView to
   be sized to the full window size, including the titlebar.
 - The NSVisualEffectViews are descendants of the window's contentView.
 - The NSVisualEffectViews intersect the titlebar.
 - Our window does not use the "full size content view" window style mask.

Review commit: https://reviewboard.mozilla.org/r/185254/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/185254/

Comment 38

[Markus Stange [:mstange]]

Attachment: Bug 1400057 - Override _wantsFloatingTitlebar to return NO in order to avoid titlebar glitches on 10.13.

Review commit: https://reviewboard.mozilla.org/r/185258/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/185258/

Comment 39

[Markus Stange [:mstange]]

Attachment: main-with-vibrancy.mm (reduced standalone testcase)

Comment 40

[Markus Stange [:mstange]]

Returning NO from _wantsFloatingTitlebar seems to make the titlebar behave as on previous versions of macOS in many respects. Vibrancy in the titlebar works again (without having to use the "full size content view" window style mask): there is no black bar and the corners aren't transparent. It also affects the NSView hierarchy, in that the titlebar controls become direct subviews of the frame view again. So it also fixes bug 1402054.

I stumbled over this workaround accidentally. When I tried to put the vibrancy views into a different place in the window's NSView hierarchy, I called addSubView on the window's frame view. This "fixed" the rendering. However, when I changed that "addSubview" call to an "_addKnownSubview" call, the glitches were back. So I took a look at -[NSThemeFrame addSubview:], and found that it triggers an asynchronous call to -[NSThemeFrame _unfloatTitlebarAndToolbarIfNeeded], which checks -[NSThemeFrame _wantsFloatingTitlebar]. And -[NSThemeFrame _wantsFloatingTitlebar] returns NO if it finds an extraneous NSView in the window's frame view or a titlebar accessory view. So one way to get _wantsFloatingTitlebar to return NO would be to add a dummy NSView as a titlebar accessory view. However, I think overriding _wantsFloatingTitlebar explicitly is preferable, because it explicitly states our intentions and is just as brittle (or maybe a little less brittle). So that's what I went with.

This is not a real fix, it's only a workaround, but it seems to work well. It buys us time so that we have a chance to rework our NSWindow setup properly, which will involve:
 - Using the "full size content view" window mask, and removing the overrides of frameRectForContentRect & friends
 - Making our main view layer-backed. This probably requires compositing into an IOSurface which then gets displayed by the view's layer, because attaching the NSOpenGLContext to the view directly seems to cause serious glitches in combination with NSWindowStyleMaskFullSizeContentView.
 - Relying on the CoreAnimation layer ordering to get the titlebar buttons to show on top of our content, and removing our manual extra compositing of those buttons.

Comment 42

[Stephen A Pohl [:spohl] (OOO until 9/9)]

Comment on attachment 8913860 [details]
Bug 1400057 - Override _wantsFloatingTitlebar to return NO in order to avoid titlebar glitches on 10.13.

https://reviewboard.mozilla.org/r/185258/#review190312

This looks and works like a charm! Thank you!

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2ea9c4738449
Override _wantsFloatingTitlebar to return NO in order to avoid titlebar glitches on 10.13. r=spohl

Comment 44

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/2ea9c4738449

Comment 45

[whmountains]

Yeah!  Thanks for the fix.

Comment 46

[Markus Stange [:mstange]]

Comment on attachment 8913860 [details]
Bug 1400057 - Override _wantsFloatingTitlebar to return NO in order to avoid titlebar glitches on 10.13.

Approval Request Comment
[Feature/Bug causing the regression]:
This was caused by the switch to 10.11 SDK (bug 1324892).

[User impact if declined]:
Serious rendering problems on 10.13, which was released last week.
This patch fixes all known problems with the window appearance on 10.13.

[Is this code covered by automated tests?]:
No.

[Has the fix been verified in Nightly?]:
Yes, by myself.

[Needs manual test from QE? If yes, steps to reproduce]:
It would be nice to get confirmation that all states of the titlebar work correctly on 10.13 now. I.e. { default theme, light theme, custom background theme } x { titlebar disabled, titlebar enabled } x { before fullscreen, after fullscreen } x { before minimizing, after restoring from minimized state }

[List of other uplifts needed for the feature/fix]:
none

[Is the change risky?]:
It's a little risky, but not too much. The sooner we can get it out to our Beta audience, the better.

[Why is the change risky/not risky?]:
It accesses a private API, which does carry a small amount of risk because it means that it could work differently in a future macOS update. But the purpose of the API is to make things work very much like they worked in the previous macOS version, and in that way, it's not very risky because it returns us to a known-good state.

[String changes made/needed]:
none

Comment 47

[Stephen A Pohl [:spohl] (OOO until 9/9)]

(In reply to Markus Stange [:mstange] from comment #46)
> [Needs manual test from QE? If yes, steps to reproduce]:
> It would be nice to get confirmation that all states of the titlebar work
> correctly on 10.13 now. I.e. { default theme, light theme, custom background
> theme } x { titlebar disabled, titlebar enabled } x { before fullscreen,
> after fullscreen } x { before minimizing, after restoring from minimized
> state }

To add to Markus' comments above, we should also verify that this continues to behave as expected on all versions of macOS that we currently support, starting with 10.9.

Comment 48

[Sylvestre Ledru [:Sylvestre]]

I will wait until we have the verification until I take this patch in beta.

Comment 49

[Sören Hentzschel]

I can verify that the fix works on macOS 10.13 and that I can't see any regression on macOS 10.11.4. I don't have any other version of macOS.

Comment 50

[Oana Botisan, Desktop QA]

I managed to reproduce the bug on an old Nightly 58.0a1 from 2017-09-29 using macOS 10.13. I retested everything on the latest Nightly, but the bug is not reproducing anymore. I tried different themes: default, dark, light, high contrast, low contrast and a few of the popular themes from https://addons.mozilla.org/en-US/firefox/themes/?sort=popular. 

I tested everything using an old version of Nightly 58.0a1 from 2017-09-29 and latest Nightly (2017-10-02) on Mac OS 10.9, Mac OS 10.10, Mac OS 10.11 and macOS 10.12, but I couldn't reproduce the bug. As it was said before, I think only macOS 10.13 was affected. But just to be sure, I tested with every theme that I mentioned before.

Comment 51

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8913860 [details]
Bug 1400057 - Override _wantsFloatingTitlebar to return NO in order to avoid titlebar glitches on 10.13.

Ok, let's take it then. Thanks for the verification

Comment 52

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ba626b811d73

Comment 53

[Alexandru Simonca [:asimonca], Release Desktop QA]

I have just reproduced this issue using Beta 57.0b4 and I can confirm that it is fixed in 57.0b5. 
I used a 2013 MacBook Pro with macOS 10.13.1 Beta (17B25c).