Closed Bug 1297879 Opened 3 years ago Closed 3 years ago

Sidebar turns black when in Mac OS X's full-screen mode

Categories

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

All
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla51
Tracking Status
firefox51 --- verified

People

(Reporter: apoliak, Assigned: mattwoodrow)

References

Details

(Keywords: regression, Whiteboard: tpi:+)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20160824030337

Steps to reproduce:

1. Open Thunderbird 51.0a1 (2016-08-23 Build) on a Mac running OSX El Capitan on a clean profile with all addons disabled.
2. Set up an account to have content on the folder list (RSS account will suffice)
3. Use the "Full Screen" title bar button to send the window to Full Screen or Split Full Screen views.
4. Attempt to navigate the folder list.


Actual results:

Between steps 3 and 4, the Background Color of the Folder List changes, making it hard to read folder labels (maybe impossible to read for some users--a possible a11y issue).


Expected results:

Thunderbird should've entered the Full Screen or Split Full Screen view without any changes to UI element color (or coordinate any color changes so that text remains easily readable).
Stefan, I don't see why the tree changes to black in full-screen mode. I tried also to move the -moz-appearance: -moz-mac-source-list; to the parent #folderPaneBox, like it's in FX, but this has the same effect. Please could you look why the tree changes to the black background and what is wrong in TB?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(stefanh)
OS: Unspecified → Mac OS X
Hardware: Unspecified → All
I'll look at it during the weekend. But iirc there are a few bugs about windows becoming black during certain circumstances. That said, I don't know if they're related to this one.

Btw, does turning off hardware accelaration makes any difference?
It happens with and without HW acceleration. Tested on a Mac Mini early 2009.
OK. I haven't played with this yet, but the thing is that the changes in bug 1192053 doesn't really change the way the widget code handles this compared to what it was before. So I think whatever problem this is it was there before. Does it makes any difference if you add back the background-color rules (mailWindow1.css) that you removed in https://hg.mozilla.org/comm-central/rev/2f26f0bd295d?
Re-adding the background colors didn't fix it. I tried then also to limit the -moz-appearance: -moz-mac-source-list; on normal and maximized sizemode what works but during size change the tree blacks out. The black background is also visible in fullscreen Address Book.
I figured it out. It's easy to reproduce in Nightly and I noticed that I coldn't see this in aurora/beta builds.

STR:
1) Launch Nightly
2) If you're not seeing the Sidebar: View: Sidebar --> Bookmarks
3) Set the window in fullscreen

--> Sidebar turns black.

This is a quite recent regression caused by https://hg.mozilla.org/mozilla-central/rev/bfc47d8a87ef from bug 1230641 (confirmed by local backout). The vibrancy effect doesn't play well with the opaque NSOpenGLContext in this case.
Blocks: 1230641
Component: Folder and Message Lists → Widget: Cocoa
Flags: needinfo?(stefanh)
Keywords: regression
Product: Thunderbird → Core
Summary: Folder List unreadable when thunderbird is in Mac OS X's full-screen mode → Sidebar turns black when in Mac OS X's full-screen mode
Matt, can you take a look? We can't set the context to opaque if we have vibrant areas in the window. And we also need to update the opaqueness state if we add / remove vibrant regions.
Flags: needinfo?(matt.woodrow)
Attached patch vibrancy-opacitySplinter Review
This almost works!

If you close the bookmarks sidebar while in fullscreen though, you see the broken background during the closing transition.

I tried adding a frame of delay before switching to opaque (since UpdateThemeGeometries doesn't go through IPC/Compositor thread and might be a frame ahead), but that hasn't fixed it.

Any ideas Markus?
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Attachment #8788308 - Flags: feedback?(mstange)
Comment on attachment 8788308 [details] [diff] [review]
vibrancy-opacity

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

(In reply to Matt Woodrow (:mattwoodrow) from comment #8)
> If you close the bookmarks sidebar while in fullscreen though, you see the
> broken background during the closing transition.
> 
> I tried adding a frame of delay before switching to opaque (since
> UpdateThemeGeometries doesn't go through IPC/Compositor thread and might be
> a frame ahead), but that hasn't fixed it.
> 
> Any ideas Markus?

The only solution I can think of would be to somehow force a sync paint + composite when a vibrant region changes. I think I've tried that before to fix bug 1154013, but was unsuccessful. I don't think the glitch is bad enough that it should prevent this patch from landing, though.

::: widget/cocoa/VibrancyManager.mm
@@ +15,5 @@
>                                       const LayoutDeviceIntRegion& aRegion)
>  {
> +  if (aRegion.IsEmpty()) {
> +    nsAutoPtr<ViewRegion> forget;
> +    mVibrantRegions.RemoveAndForget(uint32_t(aType), forget);

I think this can just be mVibrantRegions.Remove(uint32_t(aType)).
Attachment #8788308 - Flags: feedback?(mstange) → review+
Priority: -- → P2
Whiteboard: tpi:+
Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ebac182b4d27
Don't allow the cocoa GL context to be opaque if we vibrant regions within the window. r=mstange
https://hg.mozilla.org/mozilla-central/rev/ebac182b4d27
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Flags: qe-verify+
Managed to reproduce the issue on 51.0a1 (2016-08-27). The bug is verified fixed on 51.0b10 (20161222080852), using Mac OS X 10.11.6.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.