Thanks Forrest, just to clarify, you can reproduce the issue with vanilla Chromium OS but not Chrome OS devices correct?

Also, is the behavior the same whether you are using Hangouts Meet and Hangouts Classic?

https://support.google.com/a/answer/7303775?hl=en

- Yes, Chromium OS reproduces this (as does Chromium on Debian Linux) but Chrome OS does not show this problem in my testing (I have only tested v65 of official Chrome OS on a Pixelbook). 

- Yes, Hangouts (via hangouts.google.com) and Meet (via meet.googl.com) both reproduce this failure with the same error message.

For me classic Hangouts works on my G Suite account (Meet doesn't) but fails with my @gmail.com account. I also tried building with rtc_use_h264=true with no luck.

Forrest might be onto something about this possibly being a "server-side change".

Deleted: hangouts-screenshare.mp4 4.7 MB

	hangouts-screenshare.mp4 4.7 MB View Download

Hello, i'm also facing this issue with Chromium 65.0.3325.181-6 (Arch linux).

I've tried both meet (work account) and hangout (personal account) both of them fail to do a screensharing with error "Sorry, an error occurred when screensharig".

I also know at least two person who have the same issue.

Hangouts has never had supported Chromium on screensharing. Everything else should work as expected. Just not screensharing.

> Hangouts has never had supported Chromium on screensharing.

Why not? Is there some build option keying off is_chrome_branded?

So what browser is recommended for running Hangouts on Linux?  I've been using Chromium to run Hangouts since July when Hangouts stopped working on Firefox; screensharing has been working just fine until a week or so ago.

Clarification: hangouts has never supported sending screenshare on Chromium. The reason being it using a proprietary API to trigger the screen picker dialog, and that API is only available in Chrome, not Chromium. Receiving screenshares should work everywhere.

If at certain point in the past one can trigger the screenshare screen picker from hangouts on Chromium, which I highly doubt it's true, it was certainly not intended.

There's some discussion around moving away from the proprietary API but from the last I heard there was no resource allocated on that...

In comment #4, I showed that screen sharing works in Hangouts when using a G Suite account that has "New meeting experience" disabled in the Admin console. Other people also wrote that screen sharing (or "presenting") used to work in Meet a week ago.

Your response to the above is that this has never worked in Chromium and that you highly doubt someone has been able to trigger the screen picker (is that the one in my screencast above?).

IMO you can't blame a "proprietary API" (which you want to move away from) for something that broke a week ago.

Was #4 done in Chrome or Chromium? If it's Chrome, the error in the new hangouts would be a different issue -- please use the "report a problem" menu in the app so that we can take a look.

If #4 was in Chromium: hangouts has never expected the screen picker to work in Chromium. Adding some more people on why it appeared to work in #4.

I just checked again can confirm comment #4 finding:

In Meet or the "New Hangouts Experience" I am unable to use screenshare, but legacy Hangouts continues to work - any recurring meeting that was previously scheduled with legacy-Hangouts included still uses the legacy version and supports screenshare.

Can you point me to the private API you're referring to? The only similar thing I see at https://console.developers.google.com/apis/library?filter=visibility:private is the Chrome Remote Desktop API, which I don't believe is the same thing. 

As far as I can tell, the screenshare screen/window picker that works in legacy-Hangouts continues to work well there, and like third party services (like the ones I linked in my original bug report) look to be using the same thing.

The API itself (https://developer.chrome.com/extensions/desktopCapture) is not private, but you need an extension to invoke it. Chrome (not chromium) has an extension pre-installed that invokes the API for Hangouts/Meet. If Hangouts screensharing used to work for you on chromium it means you must have some extension side-loaded to enable this.

@#11: Yes, #4 is Chromium 65.0.3325.181 as packaged by Arch Linux. It has the following GN settings which might be relevant:

ffmpeg_branding="Chrome"
proprietary_codecs=true
enable_hangout_services_extension=true

Based on the strings in the picker dialog, it seems to be using chrome/browser/ui/views/desktop_capture/.

Hmm enable_hangout_services_extension=true would be relevant. Niklas, what's the expectation around that?

Figured it out after finding a clue in chrome://webrtc-internals/:

  Caller origin: https://meet.google.com
  Caller process id: 16806
  Audio Constraints
  Video Constraints
    {width: {max: 1366}, height: {max: 1366}, deviceId: {exact: ["w0a: Method: chooseDesktopMediaSource;
      Type: expected failure; Explanation: Operation ignored, no Hangout Extension expected."]},
      mediaStreamSource: {exact: ["desktop"]}, advanced: [{frameRate: {max: 5}}, {frameRate: {min: 5}}]}

Meet seems to use stubs for the methods provided by the hangout_services extension (which can be enabled in Chromium). So, instead of calling the actual methods and having them fail, it predicts in advance that it's going to fail and doesn't call it.

Looking around Meet's minified JavaScript code, it decides whether or not to use the actual methods based on:

  "Chrome"===CLa()?new XF(a):new w0a(a)

where w0a() will define stubs that do nothing.

CLa() returns "Chromium-based" for me, so that's why it thinks there's no Hangout Extension (even though it's enabled in my build).

Finally, it seems to distinguish between Chrome and Chromium-based by checking if "Chromium PDF Viewer" exists in navigator.plugins.

**TL;DR:** Chromium's screensharing can be fixed in Google Meet by using a better-targeted check for the hangout extension.

I have also confirmed that s/Chromium/Chrome/'ing the name of the PDF Viewer plugin name in chrome/common/chrome_content_client_constants.cc allows Chromium screensharing to work fine in Meet.

thenriod@, I assume this is by design to filter out missing extension errors from chromium?

Re. #16:

Like I said before, hangouts has never intended to support Chromium:
- Classic hangouts system requirements https://support.google.com/hangouts/answer/2944865 has always only included Chrome, IE, Firefox, and Safari.
- Meet system requirements https://support.google.com/meet/answer/7317473 is more restrictive:
  Meet supports the current version and 1 previous major release of these browsers:
    Google Chrome
  That means Chrome 64 and 65 as of today, however we are not actively enforcing this.

Chromium is a difficult case since most builds do not include the hangouts service extension, and there are too many variations of Chromium-derived browsers.

We do have a desire to support more browsers, but given limited resources, we have to prioritize that against everything else in the pipeline. Does anybody have stats on CloudReady builds? That may help us prioritize.

What Meet currently does is akin to blacklisting based on user agent. Surely there must be a better way to check if the hangout extensions exists, besides looking for "Chromium PDF Viewer" in navigator.plugins and assuming it's not.

(feel free to skip the rant below)

I can partly understand the reasons for not officially supporting Chromium and prioritizing Chrome over Chromium (which I've complained about in the past [1]), but I can't help being annoyed at the fact. All too often Chromium feels like a second-class citizen, whereas it should be treated in the same way with only one exception: when proprietary stuff is required to provide certain functionality (e.g. if the hangout extension wasn't part of the Chromium tree).

Sincerely, your 0.01% user base. :)

[1] https://groups.google.com/a/chromium.org/d/msg/chromium-packagers/ptgDQhdTpnM/TbSF4kdgAQAJ

From #16, it sounds as though the current check looks at an extension (PDF viewer) in order to infer whether a browser is supported. Since the actual functionality is simply tied to the availability of a different extension, I want to second the suggestion in #19. Regardless of the intended scope of support, it seems sensible sense to check for the actual dependency if at all possible.


I can certainly understand the desire to have a tighter group of officially supported browsers and versions, though. If functionality were added that was genuinely limited to official-builds, I might request changes but wouldn't view it as a bug.



As for the prevalence of CloudReady:
I think Chrome EDU and Enterprise teams keep their own numbers on CloudReady, so you can reference folks like jwong@google.com fopr that, but I can provide Neverware's rough numbers as well.

On a 90-day tail, we show ~90k active unique devices across EDU and Enterprise combined, and another ~100k active unique devices from Home users.

Hope that info helps - please let me know if any more info can be of use!

Any update on how the Meet/Hangouts team is looking at this? Hoping Neverware & CloudReady can avoid reaching the point where we have to consider shipping any kind of hack like the one described at the end of comment #16...

Thanks!

@thenriod@google.com: I would also like to confirm use of screen sharing on Chromium (gentoo, with hangouts compile option) with hangouts & meet.  I have been using that for a long time.  This includes chat more recently (we are gsuite customer).  I would sometimes share an individual window, other times share the entire screen.  It all worked flawlessly with Chromium.

And now suddenly it has stopped working.

rtvernam@, we have had difficulty determining the presence of the Hangout Extension. A while back, we decided to blacklist browsers we determined to be Chromium when it came to Hangout Extension functionality. We did so because Chromium is not officially supported for Meet. This was to be part of a progression to making a better experience for typical Chromium users who would not be able to screenshare.

In light of pushback to keep Neverware and Cloudready working, we made an _exception_ in this case to not remove support (but not necessarily support) this use case. This change went in on Monday and should hit prod in a few days. Things should go back to the way they were for you.

That all being said, I would like to reiterate that Chromium is not a supported browser for Meet at this time, and as such, not all functionality may be working or present.

thenriod@: That is fair and reasonable.  Thank you for this update!

Let me echo rtvernam@'s sentiment - thanks very much for the update and the effort to keep things working as well as they did previously. 

Please re-open if necessary.