1649764 - pages do not render in Firefox ESR 68.10 on macOS Big Sur 11.0 Beta (20A4299v)

Status: RESOLVED DUPLICATE of bug 1648836

(Core :: Widget: Cocoa, defect)

Description

[Mark Smith [:mcs]]

Using Firefox ESR 68.10 on macOS Big Sur 11.0 Beta (20A4299v), regular web pages do not render. Page content is loaded over the network (the page title is shown on the tab and Inspector shows the DOM), but the content area only shows a spinner. Internal pages such as about:preferences do render correctly. Setting MOZ_FORCE_DISABLE_E10S=1 in the environment before starting Firefox fixes the problem; perhaps Big Sur is interfering with IPC or some other aspect of Firefox's multiprocess architecture.

On the same system, pages load and render correctly in Firefox 77.0.1. Either there is a patch that needs to be backported to ESR 68 or Apple has quietly added an exception for newer Firefox which is not in effect for 68.x.

This bug also affects Tor Browser since it is based on ESR 68.

Comment 1

[Timothy Nikkel (:tnikkel)]

Running mozregression to find out what patch fixed it would probably be helpful.

Comment 2

[Kathleen :Brade]

(In reply to Timothy Nikkel (:tnikkel) from comment #1)

Running mozregression to find out what patch fixed it would probably be helpful.

Mark and I found the first nightly build that works on Big Sur:
http://archive.mozilla.org/pub/firefox/nightly/2019/08/2019-08-22-09-54-39-mozilla-central/

We then tracked it down to this commit:
https://hg.mozilla.org/mozilla-central/rev/152bfc05a5091be5d366580d6cbdd1e6fd54eb79

Comment 3

[Markus Stange [:mstange]]

I'm very surprised. I'd expect that patch to make a difference in whether anything is displayed in the window at all, regardless whether it's from the parent process or the content process. But the fact that it makes content process rendering show up, when parent process content was already rendering successfully, is unexpected. The CoreAnimation path doesn't change anything inside content processes, and it only makes a difference at the point in the pipeline where pixels from all processes in the window have already been combined.

Comment 4

[Markus Stange [:mstange]]

Oh, can you post the graphics section from about:support before and after? Maybe we're failing to use BasicCompositor without CoreAnimation and falling back to main thread software rendering, which doesn't support remote content.

Comment 5

[Mark Smith [:mcs]]

Attachment: selections from about:support - no content rendered

Comment 6

[Mark Smith [:mcs]]

Attachment: selections from about:support - content rendered correctly

Comment 7

[Markus Stange [:mstange]]

Thanks! That confirms that, pre-CoreAnimation, you're getting "Compositing: BasicLayers (main thread, no OMTC)", and the "no OMTC" part there means that remote content won't be rendered.

Are you running Big Sur on physical hardware or in a VM?

Comment 8

[Mark Smith [:mcs]]

(In reply to Markus Stange [:mstange] from comment #7)

Are you running Big Sur on physical hardware or in a VM?

On physical hardware, specifically a late 2013 15" MacBook Pro. You can find tech info here, including info on the GPUs:
https://support.apple.com/kb/sp690?locale=en_US

Several Tor Browser users have also reported this problem but I do not know what kind of hardware they are using.

Please let me know if there is other info you need or an experiment you want me to undertake.

Comment 9

[Markus Stange [:mstange]]

Thanks.

We'll need somebody to reproduce this in a debugger, and step through GLContextProviderCGL::CreateForWindow and find out where things go wrong.

Comment 10

[Markus Stange [:mstange]]

Haik found the cause in bug 1648836.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:spohl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[Stephen A Pohl [:spohl]]

Closing as duplicate of bug 1648836 to make tracking easier.