Sharing MS Word works on my Win10 desktop.
I guess what happens to you is there is overlap between your word and screen edge or other app window. Try to move the Word window or maximum it should solve it.

This isn't a one off problem.
We have observed it and recorded it as a reproducible issue as well as having people using our product report it (they are mainly running in a Citrix environment).

I have further recordings that show other similar problems with PowerPoint and Adobe.
Basically nothing is updated on receiver side until you do something that forces a full window refresh, like resizing the window or moving another window in front of the shared application. Those recordings are too big to be attached here unfortunately.

And yes, we haven't been able to reproduce it on every Windows 10 machine which leads us to believe that the screen capturer isn't working correctly in certain environments, this Dell laptop being one and Citrix being the other.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Oh, my Lenovo laptop also has MS Office installed and has not this problem when the Word window is away from screen edge.

Could you please help to do some tests on that Dell laptop as the position of Word window is still my major concern:

- If the Word window is set to full-screen by clicking the Maximum button, is this problem still happening?
- If the Word window is scaled down to be a small window and put in the middle of the screen far from any border of the screen, is this problem still happening?

As per comment#8 adding Needs-Feedback label.

@Reporter: Please follow the steps mentioned in comment#8 and report us back the behaviour.

Thanks!

- If the Word window is set to full-screen by clicking the Maximum button, is this problem still happening?
Yes
- If the Word window is scaled down to be a small window and put in the middle of the screen far from any border of the screen, is this problem still happening?
If it is super small in the middle of the screen the problem doesn't happen.

It doesn't have to be maximized for the problem to happen.
We tested various different sizes and it seems that when it is closer to the border of the screen (but not at the border and still in the middle of the screen) the problem returns.
So might be related to size of the window.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Yes, it has to be related to size/location of the window.
It's strange that maximizing the window on your Dell laptop doesn't work, while it works fine on my lenovo X1. Do you use some special theme on that laptop?

No, nothing special

Does this(fullscreen office window doesn't work) only happen to that specific dell laptop or all the machines of same model?

We only have one of these particular models.
We have customers that have the same problem and they are running our system using Citrix software (virtual desktops) and for them it happens for every user

We don't have Critrix environment. So I tried with Chrome Remoting. The interesting thing is if I try to share a maximized Word window in chrome Remoting window, it will fail to update in the beginning and will be back to work fine by itself after I leave it for dozens of seconds.

I wonder if this is similar to your problem with Citrix. And if you wait for a while, will the sharing work again at your side too?

OK. The problem at my side has nothing to do with remote desktop. The reason is the Chrome notification for the desktop sharing in Meeting, which is treated as a separate window overlapping the maximized Word window. (I disabled notification in most of my Chrome versions, except one in the last test.)

So this may be not the same reason at your side, unless there is any similar notification. Is there any?

We tried, and sharing never recovers.
And since it happens both for Chrome and Electron, where one has a notification and one doesn't if feels like that probably isn't related.

If you want to get some specific logs from the Dell laptop or need us to run anything special we are happy to assist.

That would be the final option to send you a customized chromium building to collect extra logs, which is way too hard. But I'm looking into it.

Before that, I noticed in the attached video in original report, the Word window on the left doesn't have the title bar and max/min buttons, which is not the case at my side. How is it like that? Any idea?

anumeet@, I shared a customized Chromium to you to collect some logs.

And the question in #20 is still valid. Please check.

@braveyao
Thanks for the build. Unfortunately it didn't work.
When we tried to setup a call nothing happened and we didn't see any errors in the log.

As for the maximize buttons, I think that this might just be the screen capturing software. They are there when we tried it.

I think you can also try this:

- maximum Word
- launch Chromium and open URL: https://www.webrtc-experiment.com/screen-sharing/#32685442571862986
- click Install button to install the extension.
- click "share your sceen" button to show the picker. select Word and start sharing.
- Word should be on top most now. (It doesn't matter that you can't see the Chromium window to verify the capture)
- click 'stop sharing" button on the chromium notification bar.
- close Chromium and collect the log file.

Let's see in this working scenario, if the Word window is thought as covered first.

Another way to test is to use https://appear.in/. Then you can monitor the sharing from peer.

Both methods work at my side with the Chromium building. Please give another try.

@braveyao
This is what we did in Appear.

In Appear.in
- created test room
- added chrome extension
- provided URL to colleague
- colleague joined the session
- opened the Word document (maximised)
- screen share --> application window --> Word application
- tried to scroll down and colleague could not see any movement.
- when windows smaller colleague could see scrolling.
- when resizing the height of the browser, there was tipping point when the screen sharing froze (windowed mode).

Deleted: User Data.zip 9.4 MB

User Data.zip 9.4 MB Download

Thanks for the test. But the log file, chrome_debug.log, is missing. Could you please try again by starting Chromium with command line flags "--enable-logging --v=1"? 
The chrome_debug.log should be right under \User Data.

Hi @braveyao

I have been able to enable the Chromium debug logging on the specific build of Chromium provided.

I have followed the specific steps using the URL: https://www.webrtc-experiment.com/screen-sharing/#32685442571862986

Once I 'shared the screen' using the 'Application' tab and opening the Word application maximised - the issue was present. The first page in Word was locked on the preview for the screen share - even when scrolling down the pages it was still showing the first page.

The mouse movement was actively shown - so it was not a frozen screen.

I un-maximised the Word and the screen share started to work from the page I was on at the time. When I re-maximise the window - the frozen screen was shown again and the scrolling stopped working.

In the Log file attached 'chrome_debug.log' - it clearly states an error when screen sharing and you will also notice when I made the window smaller and larger again.

Please let myself or Anumeet know if you require anything else. 
Happy to arrange a direct meeting with you if you fail to replicate the issue.

Deleted: User Data.zip 2.0 MB

User Data.zip 2.0 MB Download

Hi kaosar.ahmed@, thanks for the testing and the log file. And in the log file I can see that there are two problems will prevent sharing office documents:

(1)screen_rect (4920 x 1920, top_left (0, -1080)
   content_rect (1150 x 626, top_left (380, 3482)

It seems that Citrix environment provides an odd desktop layout. The full screen rect is a huge one with a non-[0,0] top_left. And the content rect, which is a target Word window, is located in another coordinate quadrant totally.
So we think the Word window is not within current screen.

(2) Enum windows and child windows:
    window title:
    140
    256
This means we found a window without title which intersected with the Word window. So we think the Word window is not on top-most.

Because the above two problems, we can't do the cropping work and have to switch to GDI method, which is not supported by Word(that's why you got a frozen content captured). 


As to the problem of relative location between screen and Word window, I don't think we can do anything. Citrix should provide correct info.

As to the unknown window, totally have no idea what it is, since it won't happen to regular Windows machines. Have to guess it's unique to Citrix environment too.


Also ome answer to your comments, "The mouse movement was actively shown - so it was not a frozen screen.": mouse and window content are captured separately. So mouse capturing/rendering has no problem here, but we can't get update from Word.

So generally, since this only happens to Citrix environment with the above two reasons, I suppose the solution must be from Citrix side and we can't do anything so far.

Hi @braveyao.
Although the problem occurs constantly in a Citrix environment (for others), Kaosar isn't running in a Citrix environment. He is running a regular Windows 10 environment on a Dell laptop

So the log in #26 is from Citrix environment or from that Dell laptop? (frankly it will be too odd if the log is from that Dell laptop.)

Could you please do the same test on each of them and collect the logs respectively?
Once you said you couldn't reproduce it on every regular Win10 machines, but that Dell laptop only. So it's better to know what's going on on that laptop.

The logs are from the Dell laptop without any Citrix environment.
It is harder for us to get logs from the Citrix environment since that means we have to get logs from our customers and have them install the special Chrome build.

Is there any external monitor connected to the laptop?
But no matter if there is external monitors connected to the Dell laptop, the full screen rect is reported at a weird location, while the Word window on that screen is be reported at another location without any intersection to the screen rect. That's not explainable. This should be an OS issue and most probably we can do nothing about it.

And about that untitled window on top of Word window, is there any visible window over the Word window you can observe? Another chance is it's an unexpected sibling/child window of Word itself but on another process id. But you can't reproduce it on other windows10 machines, can you? BTW: what's the Office version at your side?

I need more clue on how to identify that untitled window. Since it must be an visible window, maybe get some screenshots. Please get the screenshot on the Dell laptop when the problem happens with maximized Word window, and same one on another laptop without reproduction for a comparison. 

Hi

I have tested and replicated using one & two external monitor as well as having no monitors connected.

There is no visible window over the Word application when screen-sharing - though I have noticed a red outline when screen-sharing.

The Word Application itself is fully visible - the menu and the toolbar in the fullscreen screen-sharing, it simply does not show the document itself. This only is shown after the window is resized and it recaptures the current page the Word application is demonstrating. Going back to full size, either freezes the current page or creates streaky lines vertically on the document.

I have been able to reproduce on another Window 10 machine too. The Word application I used is Office 365 - however this is also replicable in Adobe and other applications. 


I am unsure which untitled window you are referring to as I could not see this window visibly... 

I am more than happy to schedule a WebEx or other form of screensharing should you wish to view the issue first hand.
Please let me know your availability - I am based in London.

A red outline when screen-sharing? Chrome won't draw that out line.
It sounds a problem to me. So the outline is always there, not matter word window is maximized or scaled down? I doubt that when the word window is in max, the outline might be drawn crossing word window border a bit.
Is there any way to remove the outline?

My word is MS office standard 2016. Is it possible for you to try that version?
Office 365 is not available to us. What's the Adobe app or other apps you mentioned? It may be better that we test with same app.

Hi @braveyao

After double checking - I can confirm the red outline is related to the Windows 10 theme that is applied - we can ignore the red outline.

I was able to reproduce on a colleague machine who did not have the red outline.

I would like to request to conduct a WebEx screen sharing call as this will highlight the ongoing issue that we've reported. Also it will also give you a the time to ask me any troubleshooting questions.

It would be incredibly helpful and will allow us all to progress to resolve the issue sooner.

The issue still remains with WebRTC screen sharing using the 'Application' method in full screen.

Please let me know your availability for next week or the following week for the WebEx meeting.

Hi kaosar@, frankly I don't think meeting will help anything. What I need now is:
 - debug info, e.g. chrome_debug.log, from the debugging chromium building I 
 shared with you, if only you can reproduce this issue.
Or
 - help me to reproduce it at my side, which will be more efficient.

So far, there are two reasons found at your side:
 - wrong window location reported, which we can't do anything to.
 - untitled invisible window on top of the shared window. That window marks itself as visible(chrome will filter out any invisible window), but you can't see it as in the report.

I shard you a newly built chromium today, please do the test and collect debug info again. There is more info logged about that window. Please do a simple test first:
1. maximum the office window.
2. start the chromium from commandline with flag "--enable-logging"
3. start to share the office window.
4. stop sharing and close chromium.
5. check the logging in log file or in terminal contains log as "context.is_top_window 0".
6. send me back the chrome_debug.log file.

If it catches that window on top of the office window, it's process id will be logged as "This is from process id xxxx". See if the process xxxx is in the TaskMananger.


To help me to reroduce it at my side, if it's a common issue, check my comment #34. Try to find out some common free Apps that I can get and install here.

I can confirm I see the same problem.

1. Start Hangouts meeting on Chrome.
2. Share Powerpoint.
3. Change a slide in Powerpoint
->  Slide change is not seenn on Hangouts. 
4. Resize Powerpoint (e.g., go from full screen to reduced window)
-> Slide will update

some of our open source projects based on chromium opened the bug because of this bug. The problem is just same.Check the below discussion about the issue.
https://github.com/electron/electron/issues/13536 

steven@ and alex.breen@, please check my comment#8.

At present on Win10, the shared window must on top of the desktop without any covering, either by other app window or screen edge, e.g. you should be able to see all its content within the current screen.
The common problem is the target window goes off screen, even if there is only 1 pixel out of screen, the capture may fail too. So please try to start the capturing by maximizing the target window, or scaling down the app window and locating it in center of the screen, which can guarantee the target window won't go out of screen. 

Yes, this is a solution. But I think we shouldn't have this limitation. We hope chromium can improve this limitation in the future. Thanks.

That's the best thing we can do on Win10 for now, due to the limitations of Windows APIs. No one likes the compromise here...

I agree with you about Windows API limitation. But When I test this on MS Office 2010. It works well. So precisely, this is the limitation of new Windows API.

Finalizing all discovered: the problem is in the Windows API. But will it be "won't fix" in chromium, or there is a chance for any solution for this one?

I have to add an observation though.
We can reproduce this issue.
What we observed when testing with other applications is that Hangouts and Ubserconference (both using Chrome and hence WebRTC) has the problem.

WebEx and Skype For Business doesn't have the problem.
So it seems that it is not only related to the Windows API since the other applications work.

Has there been any update on a solution for this bug? I've tried the steps from comment 38 and 40 and can confirm we are seeing similar behavior. 
My follow up question though, after resizing the windows for a UI update, should the screen sharing continue to update? I'm seeing it (for powerpoint) update the current slide. Then, when the sender updates the slides again, the receivers do not see any UI update. 

To comment #44: What is the problem discovered? I need the detailed info to see if there is anything we can do.

To comment #47: Office 365 application freeze when I share with WebRTC in chrome.

To comment 48: what version of chrome are you using? I'm seeing the behavior with our electron app (build off of chrome version 66) but not seeing the issue with latest versions of chrome (72).