safari doesn't draw the window - only a hollow transparent shell

[totaam]

It's almost impossible to bisect because it occasionally displays correctly!
Disabling the offscreen decode worker and even the decode worker does not help.
I think that the decoding part works, it is the draw_pending_list that's not doing its thing?

[TijZwa]

Let me see if I can find my macbook :) and investigate this.

[TijZwa]

I've tested witj Safari 15.6.1 on macOS 12.6.3 and it works with both SSL and non-SSL context.
Do I miss something?

[totaam]

Well, that's interesting. It means that perhaps Xpra-org/xpra#3769 is also a false positive.
Either a problem with VirtualBox or Apple's software OpenGL driver.

Do you have a newer MacOS to test with?
Can you try the latest MacOS beta with --opengl=force?

[heinosasshallik]

I don't think it's a problem with VirtualBox, since I believe I was able to replicate this on a physical Macbook. I applied the workaround mentioned in #226, but instead of xpra drawing my application, I just got an empty window.

[totaam]

I modified the draw function to just put some text on the canvas, then call the draw function after creating the window in various ways:

win.draw("new window done");
window.requestAnimationFrame(function() {win.draw("new2");});
window.requestAnimationFrame(function() {win.draw("new3");});
setTimeout(function() {win.draw("new4");}, 100);
setTimeout(function() {window.requestAnimationFrame(function() {win.draw("new5");})}, 100);

And only the first 3 show up, nothing after that.
Safari is broken, use a better browser.

So I've already spent too much time on this and I have no idea what's broken with Safari.
Unless someone else takes a look at it, this won't be fixed.
Safari is the new Internet Explorer

[ojasookert]

@TijZwa could you share the builds/commits you had this working on?

[beren12]

Safari on iOS/iPadOS 14 is broken as well. I only get the blue background image. If we could use a different browser engine it would be wonderful but it's not possible on iOS.

[dexion]

Client:
Safari 16.5
MacOS 13.4

Server:
The latest public xpra-4.4.5 from packages

[taradaidv]

It's almost impossible to bisect because it occasionally displays correctly!
Disabling the offscreen decode worker and even the decode worker does not help.
I think that the decoding part works, it is the draw_pending_list that's not doing its thing?

I'm also looking for what the problem is, there are a couple of sketches.
Now the easiest way is to disable offscreen decoding, but this is a crutch and not a solution

tmp fix:
echo -e "\noffscreen = false" >> /usr/share/xpra/www/default-settings.txt

[totaam]

Now the easiest way is to disable offscreen decoding, but this is a crutch and not a solution

Last time I tried, that was not enough - at least with the Safari versions I had access to.

echo -e "\noffscreen = false" >> /usr/share/xpra/www/default-settings.txt

That would disable offscreen for all browsers, including the ones that aren't buggy!
57d1c2a should disable it only for Safari.
Does that work for you?

[taradaidv]

Yep, that defines it well.
Now in Safari it disables offscreen and draws on the canvas, in other browsers offscreen works and draws too.

[totaam]

@taradaidv which versions of Safari have you tested?

[taradaidv]

latest
Safari on Mac
Version 16.5 (18615.2.9.11.4)

[jhgoebbert]

This bug-report might be of interest: https://bugs.webkit.org/show_bug.cgi?id=253927#c0
This shouldn't happen often, but can happen if you draw to an OffscreenCanvas, call "commit()", and then draw again quickly (not waiting for rAF).
A pull-request was merged in March but might not have been included in current Safari browsers, yet: WebKit/WebKit#11534

[totaam]

Just discovered at the last minute that Google Chrome now requires https to enable offscreen: 52742e3
It doesn't complain, doesn't give any warnings, but doesn't paint the window either!