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

VERIFIED FIXED in Firefox 57

Status

()

P1
normal
VERIFIED FIXED
2 years ago
a year ago

People

(Reporter: marcia, Assigned: mstange)

Tracking

Trunk
mozilla58
Unspecified
macOS
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox57+ verified, firefox58 verified)

Details

Attachments

(4 attachments, 3 obsolete attachments)

Created attachment 8908385 [details]
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.
Does this persist after a restart of Firefox?
Blocks: 1379811
(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.
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
(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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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!
Flags: needinfo?(mozillamarcia.knous)
Created attachment 8909811 [details] [diff] [review]
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.
Assignee: nobody → spohl.mozilla.bugs
Status: REOPENED → ASSIGNED
Attachment #8909811 - Flags: review?(mstange)
(Assignee)

Comment 8

a year ago
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];
Attachment #8909811 - Flags: review?(mstange) → review+
Created attachment 8909843 [details] [diff] [review]
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.
Attachment #8909811 - Attachment is obsolete: true
Attachment #8909843 - Flags: review+
This should track for 57.
tracking-firefox57: --- → ?
(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.
Flags: needinfo?(mozillamarcia.knous)
(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?
Flags: needinfo?(mozillamarcia.knous)
(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...
(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.
(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?
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.
Flags: needinfo?(mozillamarcia.knous) → needinfo?(andrei.vaida)
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
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.
(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?
Flags: needinfo?(andrei.vaida) → needinfo?(spohl.mozilla.bugs)
(In reply to Stephen A Pohl [:spohl] from comment #10)
> This should track for 57.

Tracking 57+
tracking-firefox57: ? → +
Blocks: 1391790
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(spohl.mozilla.bugs)
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.
Flags: needinfo?(whmountains)
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(charlie.siegel)
Flags: needinfo?(cadeyrn)
(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

a year ago
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

a year ago
(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
Flags: needinfo?(charlie.siegel)

Comment 25

a year ago
Created attachment 8910882 [details]
nightly-title-bar.png
(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.

Updated

a year ago
Flags: needinfo?(cadeyrn)
(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

a year ago
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.
Flags: needinfo?(whmountains)
Priority: -- → P1
Comment on attachment 8909843 [details] [diff] [review]
Patch

This landed in bug 1401297 since it didn't fix the issue reported here.
Attachment #8909843 - Attachment is obsolete: true
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!
Flags: needinfo?(cadeyrn)
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.
Flags: needinfo?(cadeyrn)

Comment 33

a year ago
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?
(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

a year ago
(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.
(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 hidden (mozreview-request)
(Assignee)

Updated

a year ago
Attachment #8913854 - Attachment is obsolete: true
Attachment #8913854 - Flags: review?(spohl.mozilla.bugs)
Comment hidden (mozreview-request)
(Assignee)

Comment 39

a year ago
Created attachment 8913861 [details]
main-with-vibrancy.mm (reduced standalone testcase)
(Assignee)

Comment 40

a year ago
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.
(Assignee)

Updated

a year ago
Duplicate of this bug: 1404506

Comment 42

a year ago
mozreview-review
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!
Attachment #8913860 - Flags: review?(spohl.mozilla.bugs) → review+

Comment 43

a year ago
Pushed by mstange@themasta.com:
https://hg.mozilla.org/integration/autoland/rev/2ea9c4738449
Override _wantsFloatingTitlebar to return NO in order to avoid titlebar glitches on 10.13. r=spohl
https://hg.mozilla.org/mozilla-central/rev/2ea9c4738449
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years agoa year ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58

Comment 45

a year ago
Yeah!  Thanks for the fix.
(Assignee)

Comment 46

a year ago
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
Attachment #8913860 - Flags: approval-mozilla-beta?
(Assignee)

Updated

a year ago
Assignee: spohl.mozilla.bugs → mstange
(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.
Flags: qe-verify?
I will wait until we have the verification until I take this patch in beta.
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.
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.
status-firefox58: fixed → verified
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
Attachment #8913860 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment 52

a year ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/ba626b811d73
status-firefox57: affected → fixed
Flags: qe-verify? → qe-verify+
QA Contact: alexandru.simonca
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).
Status: RESOLVED → VERIFIED
status-firefox57: fixed → verified
You need to log in before you can comment on or make changes to this bug.