Open Bug 780726 Opened 12 years ago Updated 2 years ago

Window Shadow Incorrect

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect

Tracking

()

People

(Reporter: zpao, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [10.8 only])

Attachments

(2 files)

Screenshot
282.18 KB, image/png
Details
Screen shot that shows the shadow is not fully covering the window
403.07 KB, image/png
Details
Attached image Screenshot — 
I haven't figured out steps to repro, but I've now seen it a few times so it's not a fluke. I can't remember if it happened on Lion, but I'm on MoLo now, latest nightly, with my MBA in clamshell using Apple Cinema as my display (via thunderbolt).

Sometimes, my browser window just doesn't draw the window shadow correctly. What I've noticed is that the shadow is missing from the left side of the window and along much of the bottom, but then it starts partway along and is correct on the right side.

STR:
1. Open App (eg, Rdio), set it to be fullscreen
2. Open Nightly, non-fullscreen
3. Switch to other app (triggers animation to other 'space')
4. Switch back to Nightly.
5. Focused window has broken shadow.

To Fix: anything to triggers the window to lose focus (but stay in that space). switch apps, focus different Nightly window.

Graphics info just in case:
Vendor ID: 0x8086
Device ID: 0x 166
WebGL Renderer: Intel Inc. -- Intel HD Graphics 4000OpenGL Engine -- 2.1 APPLE-8.0.51
GPU Accelerated Windows: 5/5 OpenGL
AzureCanvasBackend: quartz
AzureFallbackCanvasBackend: none
AzureContentBackend: none
Is this a recent regression in Firefox?

Does it also happen with other browsers (or programs)?
(In reply to Steven Michaud from comment #1)
> Is this a recent regression in Firefox?
A quick check... it's not happening in Beta (15) but it is in Aurora (16).

> Does it also happen with other browsers (or programs)?
Not that I've seen.
Keywords: regression, regressionwindow-wanted
I have now seen this on 14.0.1 and on 17.0 nightly. Not sure yet how to reproduce. It happens when switching back to Firefox. Spaces are possibly involved.
I just tried to find a regression range but no luck. This is happening in back to at least Firefox 10 and I stopped there.

Steven, if you haven't upgraded to Mountain Lion yet, can you test it there? Based on the timing and never noticing it before, it's quite likely it's Mountain Lion specific.

Easiest steps to repro: open a window, toggle maximized then back, switch to app in fullscreen (iTerm2 is my go to), then switch back to Firefox.

Given that it's been shipping and there are few reports, it's probably safe to not block on this, but it's a pretty ugly bug that I see every day.
Keywords: regression, regressionwindow-wanted
Paul, I can repro (with FF 15.0.1, following your STR from comment #0) on Mountain Lion, but not on Lion.
Any ideas what might be the issue? If I find some more time I'll try to investigate myself, but somewhere to start may help :)
Blocks: mountain-lion-compat
Whiteboard: [10.8 only]
I haven't a clue :-(

Though I suspect this is at least partially an OS bug.
I changed my desktop background to plain white and now I see that the shadow seems to be partially applied to the window - only on the right side. Does that area mean anything to anyone?
In comment #7 Paul asked for somewhere to start.

I couldn't (and still can't) think of anything very specific.  But, before we can understand (or fix) this problem, we'll probably need to know how the OS generates window shadows:  To find what documentation is available on this subject (probably very little), and to eke out the rest through reverse-engineering.
One of the things I tried was to simply not set the delegate of the window. The result is pretty bizarre: only a window title bar is drawn and that is the whole window.

What kind of crazy magic are we doing here? It is now clear to me that a Firefox window is not simply a window with a specific width and height in which we have content. Are we maybe actually composing a window by putting together multiple borderless windows or views?

Does anyone have a good idea how this actually all works? :-)
I don't have a good idea, but my guess is it's a 1 or more nsChildViews and by not hooking up the delegate, we aren't getting/handling events right.
I tried a few things today but no luck... One oddity: if I call [mWindow setHasShadow:NO] in CreateNativeWindow, that doesn't seem to stick... [window hasShadow] in windowDidBecomeMain says YES :(

Further, invalidateShadow (and in turn our deferredInvalidateShadow) doesn't seem to have any effect, though the size we get back when I check [[window contentView] frame].size looks to be correct. So at this point with my limited knowledge, I'm out of ideas.
Markus, Josh - any ideas?
Not yet, no. Does this also happen if hardware acceleration is off?

The invalidateShadow / hasShadow setup we have in nsCocoaWindow shouldn't have any bearing on this because we only use it for popup windows (context menus, tooltips, panels). We leave normal top-level windows completely alone regarding their shadow, we only get OS-native behavior for them.

Since this seems to be a regression in 10.8, can you file an Apple radar about this?
https://bugreport.apple.com/
(In reply to Markus Stange from comment #16)
> Not yet, no. Does this also happen if hardware acceleration is off?

How do you turn off hw acceleration? Is that in the OS or in Firefox?
In Firefox: Preferences -> Advanced -> General -> uncheck Use hardware acceleration when available, restart Firefox
(In reply to Markus Stange from comment #18)
> In Firefox: Preferences -> Advanced -> General -> uncheck Use hardware
> acceleration when available, restart Firefox

Well that seems to get rid of the problem :-) What does that tell us?
Not much, but at least we now know that we'll have to include an OpenGL view in a reduced test case, in case we want to attach one when submitting the bug to Apple.
If it is of any use, I repro this issue just by switching desktops.

I have FF as active app in one desktop and when I switch to another desktop (with an open app on it) and switch back to the desktop where FF was, it loses its shadow.

When I tab apps on the same desktop or hide/show FF, the shadow comes back.
(In reply to comment #21)

I can't reproduce the issue from the steps you've given.  But see bug 908533, which has more detailed STR.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: