Typo above for the live link. Here it is corrected:
https://www.pressero.com/files/subscribers/be686231-fbe3-4bea-9f91-e58ea1e60499/Webfiles/demo1.htm

Clarification: even though using contentWindow.postMessage from the outer document can tell the inner iframe that the mouseup happened, there is nothing I can do inside the iframe to make the browser itself aware of the mouseup. Dispatching a new mouseup event will be caught by attached javascript handlers but the built-in behavior of keeping the insertion point under the mouse pointer will not receive the dispatched mouseup event.

Seems it is out of scope from TE end as it is related to javascript handlers , adding TE-NeedsTraige-help label to move this out of our triaging bucket.

Could someone from dev team please take a look into this issue.
Thanks..!

I disagree that it is related to javascript handlers. Look at my demo. There is *no* javascript at all in the iframe and yet the problem happens.

Sadrul, could you take a look at this? I believe there was some code that was capturing mouse on down to a frame in OOPIF as well.

Just ran into this issue, When an iframe is hosted on the same domain, then it works. The weirdness happens when the iframe is hosted on another domain, then all pointer events get lost.

All other browsers as expected, just chrome is in this weird state.

I am hitting this on Chrome Canary - v.71 from today 

I am going to repost my demonstration links. They were down for several days, as we had redeployed the parent application. Here they are again:

bug happens:
https://www.pressero.com/files/subscribers/be686231-fbe3-4bea-9f91-e58ea1e60499/Webfiles/demo1.html

bug doesn't happen, iframe slightly larger in outer document:
https://www.pressero.com/files/subscribers/be686231-fbe3-4bea-9f91-e58ea1e60499/Webfiles/demo1a.html

Video with audio commentary, demonstrating problem:
https://www.screencast.com/t/eFtDaOlhV

Just discovered that the bug can happen if the mouse leaves the browser area completely (i.e. your browser wasn't occupying your whole screen). (Simulated red mouse pointer because my capture program doesn't capture mouse pointer.)
https://www.screencast.com/t/WafGWmdhP

And even if the iframe completely fills the width of the browser, but the browser doesn't fill the screen.
https://www.screencast.com/t/mNGm8YQq

No pointerup (Pointer Events) event as well...

I can repro on 69.0.3497.100 stable, Win and Linux, using the first link in #10.  Appears fixed by the site isolation opt-out in chrome://flags/#site-isolation-trial-opt-out, so adding the site isolation label.  I also couldn't repro on Win canary 71.0.3567.0 or on ToT, so I'm curious what's different and why #9 can still repro there.

It's interesting that the isolation opt-out appears to fix the bug; however, telling all my customers they have to change their Chrome browser settings and use an undocumented flag (or at least, an obscure one) in order to avoid a bug that just doesn't happen on any non-Chromium browser ... this is not the answer I was hoping for.

#14: I mentioned the flag mostly for triaging purposes, in fact we highly discourage using the opt-out since it makes Chrome less secure and the flag itself might be removed at some point.  We intend to fix this asap.

Chatting with creis@ and kenrb@ yesterday, Ken fixed a similar bug with text going backwards in  issue 876662 , and that fix is in M70, which is currently in beta and will go out to stable around Oct 16.  Can you see if you are still hitting your issue with the current Chrome beta (or Dev, or Canary) release?

There are a couple of mouse capture bugs that Ken is working on fixing in issues  888342  and  878007 , which might be related to this, but I'll let Ken confirm.

Here is a reduced test case, check the inspector:

1) Open the attached file. 
2) Do a pointer down on the red square, and drag it outside it.
3) You will not see any pointerup event happening.
4) You will see no pointermove event happening either.
5) You will see a lostpointercapture when you enter the red box again.

Deleted: crbug882491.html 346 bytes

crbug882491.html 346 bytes View Download

I verified in Chrome 71, the events fire correctly. Chrome 69 it doesn't.

I verified in Chrome Beta (70.0.3538.45) that our sites will be free of this bug.  Thank you so much for the great news.

(Next time I have any bug I suspect is Chrome's fault, I will definitely try Beta before reporting anything.)

@creis and @alex, for my experience, there seems to be a weirdness, when you add "user-select: none" to the iframe. I updated the crbug882491.html 

Every other browser works for user-select:none, when I opt-out of chrome://flags/#site-isolation-trial-opt-out it works again.

Here is the reduced test case to reproduce this (I am using M71):

0) Use M70+ (Current M69 doesn't work)
1) Open https://m0interactive.com/sandbox/crbug882491/index.html
2) Launch DevTools in Console Tab
2) Do a pointer down on the red square, and drag it outside it.
3) You will not see any pointerup, pointermove, or lostpointercapture event happening.
4) Drag back in the box, the lostpointercapture will fire. Pointerup is lost.

Now, in the html > body > iframe > html, disable "user-select: none" and try the steps above again. It will work as expected. Pointer Up fires again.

Now, opt out of site isolation in chrome://flags/#site-isolation-trial-opt-out and it works as well.

Something is happening to user-select for site isolation in M70+

I found that the issue reproduces in all *freshly* installed versions starting with v.67.
The issue reproduces also when one upgrades from these fresh installs to any version thereafter (in other words, they have an flag/settings upgrade bug when one upgrades from a version < v.67).

See https://bugs.chromium.org/p/chromium/issues/detail?id=888342

Here are several broken scenarios in Office Online apps, e.g. Excel Online that resides in an iframe.
1) Press the left mouse button (and keep it pressed)
   1.1) Selection: Having pressed the button within a column/row header.
   1.2) Selection: Having pressed the button within a cell.
   1.3) Fill: Having pressed the button on a corner of the current selection.
   1.4) Drag: Having pressed the button on the border of the current selection.
2) Move the mouse off the browser window.
3) Release the mouse button.
4) The result - The mouseup/pointerup events are not sent to the iframe.
   4.1) Selection, Fill: the selection keeps growing (and the document keeps scrolling).
   4.2) Drag: the dragged range is `awaiting` for mouse events.

I'm going to close this bug because the original report was fixed along with  issue 876662  and that fix will ship in Chrome 70.

#20: The fact that user-select CSS doesn't propagate to cross-origin iframes is a different bug, and I think we hadn't noticed that. Do you want to file a new bug for that?

#23: I have a fix in progress for  issue 888342 , hopefully that will land soon and resolve those problems.

I created a new bug for the user-select https://bugs.chromium.org/p/chromium/issues/detail?id=893703

 Issue 893703  has been merged into this issue.

I am still seeing this issue with Chrome v70. I created a screen share so you can see: https://drive.google.com/file/d/1ExyUF6dLWuokfBfFbMBme6WtXNiykK_A/view

To reproduce:

1. Go here: https://www.pressero.com/files/subscribers/be686231-fbe3-4bea-9f91-e58ea1e60499/Webfiles/demo1.html
2. Use this for "Final URL": https://html.com/input-type-text/
3. In a text field, enter some text
4. Double click text and on second click, click and hold while moving cursor outside of iframe
5. Start typing and notice it types backwards

I am using Chrome Version 70.0.3538.110