popping out hangouts windows from gmail are blocked by Chrome's popup blocker |
||||||||||||||||||||||||
Issue descriptionChrome Version: 70.0.3501.2 (Official Build) canary (64-bit) (cohort: Clang-64) OS: Win10 What steps will reproduce the problem? (1) visit gmail.com and login to an account. (2) Open a hangouts chat mole with someone (3) Click the "pop-out" button in top right (looks like an arrow at 45deg) What is the expected result? Chat pops out What happens instead? Chat does not pop out and a popup blocker alert appears. Please use labels and text to provide additional information. If this is a regression (i.e., worked before), please consider using the bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help us identify the root cause and more rapidly triage the issue. Works in stable 68.0.3440.75 (Official Build) (64-bit) (cohort: 68_75_win)
,
Jul 25
okay I groked that command line and the only thing vaguely related to blocking is BlockTabUnders/Enabled experiment, but even with --enable-features=BlockTabUnders I can't repro on latest build 577525. I'm out of ideas.
,
Jul 25
My gut check says this is UserActivationV2, can you see if this repros with --enable-features=UserActivationV2?
,
Jul 25
Yikes! I can repro the bug with --enable-features=UserActivationV2 on 68.0.3440.68.
,
Jul 25
yes, I can repro too. I am doing a bisect now.
,
Jul 25
repro is flaky - something strange going on. also, once the "pop-out" button fails to load, then the "X" button on the same mole breaks... very odd.
,
Jul 25
hmm yes my range is wrong. I can also repro on 68.0.3440.0 with that feature being enabled - I need to expand my bisect range.
,
Jul 25
I can repro this all the way back to 65.0.3325.0 - so something else has broken here, not sure it's worth going back any further on the Chromium end. Perhaps something changed in hangouts client? To get a reliable repro you need to "pop-out" a second chat mole.
,
Jul 26
I was able to repro on 68 too, it looks like a breakage caused by the model change with UAv2. It repros only behind UAv2, making it unlikely to discover. Do you mean by "second chat mole"?
,
Jul 26
I found that the first mole would often just work, but it was only the second attempt (e.g. pop out a mole, pop it back in, then try to pop it out again). This should probably be a release blocker for UserActivationV2?
,
Jul 26
,
Jul 26
,
Jul 27
Able to reproduce the issue on reported chrome version 70.0.3501.2 and on the latest canary 70.0.3504.0 using Windows 10, Mac 10.13.1 and Ubuntu 14.04 by enabling flag --enable-features=UserActivationV2 Tried checking older versions for regression/non-regression, the mentioned flag wasn't available till M63, it was introduced in mid/later versions of M64, so checked on 64.0.3282.186 where issue is reproducible, hence considering it as Non-Regression and removing Needs-Bisect label. Thanks!
,
Aug 13
This is still happening. Can the finch be turned down while a fix is being landed? Makes hangouts on canary quite painful to use, as moles still can't be popped out.
,
Aug 15
Still not sure why UAv2 is causing this. As per #c14, I will disable the finch trial for now.
,
Aug 15
,
Oct 3
Looks like this is related to UAv2 state propagation to the browser process. With UAv2, we don't use the renderer's state at RenderViewImpl::CreateView: https://cs.chromium.org/chromium/src/content/renderer/render_view_impl.cc?rcl=f088b1eab73afb7e1f716e000b22f785ebe41a85&l=1390 Looks like the browser is not always updated about the activation at the moment the popup call reaches there. For ref, there is a related discussion: https://chromium-review.googlesource.com/c/chromium/src/+/967260/16/content/browser/frame_host/render_frame_host_impl.cc#3053
,
Oct 4
Now I have the full explanation: UAv2 model change limits the visibility of activation to ancestor frames only. The hangout iframe is a sibling of the iframe that calls window.open, hence the window.open gets blocked. Looks like we need to reach out to gmail team.
,
Oct 12
Had a chat with local Gmail FE lead, got pointers to people working on chat window. I just confirmed that two other popout cases in gmail works as expected with UAv2: compose window (which is not really a popup), and shift-click on email list.
,
Oct 16
I just had a prototype implementation that allows activation propagation to a specific subframe, and it fixes the problem. Looks like it's time to revive Ian's earlier proposal: https://docs.google.com/document/d/1yZQjK7Q_BsyJ74Vj7Xpm3QzhDyDXB8kGdk3aESEYtSg/edit#
,
Oct 16
Let me first confirm with the gmail team, hopefully adding an "allowBlah" attribute to a single <iframe> is something feasible for them.
,
Oct 17
,
Oct 22
,
Oct 22
,
Oct 22
,
Oct 31
One point we missed to mentioned before: this affects only the old hangout app in gmail. The new hangout UI, which regular users use already, doesn't have this problem.
,
Nov 19
We have UserActivation.Consumption.FrameResult histogram data available, looks like a very small fraction of the activation consumption calls succeed today (w/o UAv2) from a sibling frame: - M71 Beta (71.0.3578.45): 0.01% - M72 Dev/Canary: 0.03% Note that the fractions above are w.r.t to number of consumption calls. Since now all pages call popups, an even smaller fraction of users would be affected. So it doesn't look like a big issue.
,
Nov 19
To have a better estimate of what fraction of users are affected, UserActivation.AvailabilityCheck.FrameResult shows how many times user activation status is checked, which is several orders of magnitude higher than UserActivation.Consumption.FrameResult. So the fraction of users affected should be smaller by a similar magnitude.
,
Nov 26
We have more data from M71 beta: - 71.0.3578.55: 0.01% - 71.0.3578.62: 0.03% - 71.0.3578.54: 0.01% This is negligible since this shows the fraction of successful consumption from sibling frames over all consumptions (not all pages try to consume).
,
Nov 26
We shouldn't block UAv2 for this old hangout/gmail specific problem that is being fixed already (see #c26), and already affects so few use cases.
,
Dec 6
this has started happening again as of very recently (today, or yesterday?) 72.0.3625.0 (Official Build) canary (64-bit) (cohort: Clang-64) c134752e-70ea8f25 2c707b42-5940ee21 411b6d4e-f23d1dea d01ab0d3-1a42b3de b0271b40-36090015 1a0d11d4-2f9febdf b1dd1b0c-3f4a17df 16e0dd70-3f4a17df 5bee2d7d-f23d1dea 2b6ab552-ca7d8d80 66df3e9d-e7f62c8 2b6b7805-f23d1dea b7e2524c-c92d551c 411c711e-f23d1dea a6674cf-1e5d42aa 788ec52f-3f4a17df da89714-4ad60575 6c18ba9d-f23d1dea 1d411afe-ca7d8d80 9041608a-3f4a17df 241fff6c-fc65ed87 6025934e-3f4a17df c27fec31-c982d8da 7c1bc906-b5809d46 9def365c-f23d1dea cb599aac-f23d1dea 2342e907-f23d1dea d442dfb7-ca7d8d80 41e765a5-f23d1dea ab3d6cfd-f23d1dea 735958b0-f23d1dea a582a1b8-ad75ce17 8f4db35c-3f4a17df e27776-3f4a17df 495970ba-bad9b0d5 59ef37b8-3f4a17df 7f7844ec-f34e292e 31e1328a-ca7d8d80 e56c5101-7d60f345 249dd49a-27a0c3c6 8e66b915-859cee29 36115667-f23d1dea 55a3035a-3f4a17df 764fc084-f23d1dea 66c8e28a-2f675a7f 334aa58d-f23d1dea f719c9bd-4701dc4f 345b5b61-f23d1dea edbcf7c5-adf3d98f 5485fc4d-3d47f4f4 1beda558-f23d1dea 93731dca-e702d8c4 87a01a8d-ca7d8d80 e111fcd-803f8fc4 41f007f9-41f007f9 9b4c4257-8caf1b09 1b558915-3f4a17df 9874ae0-3f4a17df c992f345-ca7d8d80 165e16d1-3f4a17df 9e5c75f1-b73c6342 2594bdf4-3e4b89c4 350fabdd-34b13816 6fa07eb4-efa92713 913f596c-f23d1dea 4934552d-f23d1dea 2fccc5d5-855be3dd 2b08b14-f23d1dea 7a5ba892-3f4a17df d1cd70a5-a4c9d066 b7e5dbe8-703d9bb4 4ea303a6-e2ca4846 b0a2e23d-f23d1dea 95876445-ca7d8d80 d92562a9-65bced95 7aa46da5-c946b150 b363a81f-671dcda8 67246da1-f23d1dea fc7fb3f6-1410f10 58a025e3-36e97b2c d4d220f9-1c10ba89 ad6d27cc-7075cd8 2a32876a-70ea8f25 8576baf1-3f4a17df f3ea30a0-3f4a17df f094e378-ebf2b7c2 2e7f6029-614709d9 51af0496-5a44b38a d840bbac-803f8fc4 1fcbb124-92ef5cc8 4bc337ce-87ea0e5e 603d4940-efad1e7f 494d8760-52325d43 3ac60855-3ec2a267 f296190c-9ce370dd 4442aae2-6e597ede ed1d377-e1cc0f14 75f0f0a0-d7f6b13c e2b18481-6e597ede e7e71889-4ad60575 d91d40b-ca7d8d80 fcdd9ed9-f23d1dea b0ea13bc-dab9d9d 3a8217c1-f23d1dea 94e68624-3f4a17df cc73f8a1-1776d9e 10a311eb-cf4f6ead 7e91b7bd-8834fcca 6204e469-e3d9cd05 3f33c9bd-12538cab 81c6897f-741d8d64 ea0f933d-29e3c6de b77dc7f0-3f4a17df
,
Dec 6
Yeah, this is because we turned on UAv2 in M72. We are keeping an eye on UMA data, working on a temporary fix too. "Temporary" because Issue 728334 would take some time.
,
Dec 6
I disagree with #30 - if this is blocked on a gmail fix then the Chrome feature should not be enabled for any channel until gmail has fully rolled out the fix - otherwise it makes hangouts very painful to use. In general, we do not want to encourage users to have to stop using early channels, or use flags to disable features, to avoid issues like this.
,
Dec 6
,
Dec 6
,
Dec 6
Mustaq, is the Gmail issue limited to googlers who haven't had the new UI rolled out to them, or are there other users affected as well? On Thu, Dec 6, 2018, 2:35 PM mustaq via monorail < monorail+v2.2341872843@chromium.org wrote:
,
Dec 6
For posterity, here is our analysis that shows that Gmail-like use cases are rare (pre-UAv2):
Histograms are not linked to page loads, so there is no direct way to find a relative count of hangout-like use cases against page loads.
However, we have a good proxy for it in UserActivation.Consumption.FrameResult UMA data: since only places we ever "consume" activation are content-link-navigations and popups, which excludes navigation through omni-box, we know that
#_successful_consumption_in_top_or_ancestor_frame <= #_pages_opened
Therefore, using UserActivationFrameResultEnum raw data from 71.0.3578.64 on Nov 28 2018 we have:
#_successful_popups_from_sibling_frame / #_pages_opened
= OtherSuccess / #_pages_opened
<= OtherSuccess / (SelfSuccess+AncestorSuccess)
<= 0.009838163%
,
Dec 6
iclelland@: In our mid-October meetings, I learnt that only corp users are on old UI, and that the UI with a "colored +" compose button indicates the new UI. However, we are now seeing that that UI doesn't fix the problem. Clearly there was a miscommunication on the tested UI combination there: (Gmail vs Hangout) x (old vs new).
,
Dec 6
my personal account (a dasher account) also exhibits this issue on Canary, so perhaps the old UI is still running on dasher?
,
Dec 7
,
Dec 7
,
Dec 7
I've been seeing this since updating to 73.0.3631.0 (Official Build) canary (32-bit) (cohort: Clang-32) this morning. I'm not a Google employee and I'm not using the old UI. I'm on Windows 10.
,
Dec 7
Additionally, once popping out is blocked, I can't exit or minimize the chat mole and have to reload Gmail.
,
Dec 7
Yeah, I can see that too. We have a fix under review now.
,
Dec 8
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1 commit a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1 Author: Mustaq Ahmed <mustaq@google.com> Date: Sat Dec 08 00:30:14 2018 Allow user activation propagation to same-origin frames. This is an intermediate measure to mitigate UAv2 regressions for apps that require same-origin visibility. It temporarily makes Chrome's implementation of UAv2 a bit closer to the old (v1) model, thus gives us time to work on an iframe attribute to declaratively allow user activation propagation to subframes (crbug.com/728334). We will remove this intermediate measure once the iframe attribute is ready. Bug: 867599 , 728334 Change-Id: I67557a873177edf20ef809b2a976a740f32ed1d7 Reviewed-on: https://chromium-review.googlesource.com/c/1366761 Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Cr-Commit-Position: refs/heads/master@{#614883} [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/content/browser/frame_host/frame_tree_node.cc [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/content/public/common/content_features.cc [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/content/public/common/content_features.h [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/third_party/blink/web_tests/fast/dom/Window/window-postmessage-user-gesture-expected.txt [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/third_party/blink/web_tests/fast/dom/Window/window-postmessage-user-gesture.html [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/third_party/blink/web_tests/fast/events/open-window-from-another-frame-expected.txt [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/third_party/blink/web_tests/fast/events/open-window-from-another-frame.html [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/third_party/blink/web_tests/fast/events/resources/open-window-from-another-frame-otherFrame.html [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/third_party/blink/web_tests/virtual/user-activation-v2/fast/dom/Window/window-postmessage-user-gesture-expected.txt [modify] https://crrev.com/a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1/third_party/blink/web_tests/virtual/user-activation-v2/fast/events/open-window-from-another-frame-expected.txt
,
Dec 10
,
Dec 10
,
Dec 10
Verified the fix in Windows Canary (73.0.3636.0). I will merge to M72 now.
,
Dec 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a64e643c515b09b0dfef6ed4f64778ed0086b734 commit a64e643c515b09b0dfef6ed4f64778ed0086b734 Author: Mustaq Ahmed <mustaq@google.com> Date: Mon Dec 10 18:56:42 2018 Allow user activation propagation to same-origin frames. This is an intermediate measure to mitigate UAv2 regressions for apps that require same-origin visibility. It temporarily makes Chrome's implementation of UAv2 a bit closer to the old (v1) model, thus gives us time to work on an iframe attribute to declaratively allow user activation propagation to subframes (crbug.com/728334). We will remove this intermediate measure once the iframe attribute is ready. Bug: 867599 Change-Id: I67557a873177edf20ef809b2a976a740f32ed1d7 Reviewed-on: https://chromium-review.googlesource.com/c/1366761 Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#614883}(cherry picked from commit a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1) Reviewed-on: https://chromium-review.googlesource.com/c/1370317 Reviewed-by: Mustaq Ahmed <mustaq@chromium.org> Cr-Commit-Position: refs/branch-heads/3626@{#220} Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437} [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/content/browser/frame_host/frame_tree_node.cc [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/content/public/common/content_features.cc [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/content/public/common/content_features.h [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/third_party/blink/web_tests/fast/dom/Window/window-postmessage-user-gesture-expected.txt [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/third_party/blink/web_tests/fast/dom/Window/window-postmessage-user-gesture.html [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/third_party/blink/web_tests/fast/events/open-window-from-another-frame-expected.txt [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/third_party/blink/web_tests/fast/events/open-window-from-another-frame.html [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/third_party/blink/web_tests/fast/events/resources/open-window-from-another-frame-otherFrame.html [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/third_party/blink/web_tests/virtual/user-activation-v2/fast/dom/Window/window-postmessage-user-gesture-expected.txt [modify] https://crrev.com/a64e643c515b09b0dfef6ed4f64778ed0086b734/third_party/blink/web_tests/virtual/user-activation-v2/fast/events/open-window-from-another-frame-expected.txt
,
Dec 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a64e643c515b09b0dfef6ed4f64778ed0086b734 Commit: a64e643c515b09b0dfef6ed4f64778ed0086b734 Author: mustaq@google.com Commiter: mustaq@chromium.org Date: 2018-12-10 18:56:42 +0000 UTC Allow user activation propagation to same-origin frames. This is an intermediate measure to mitigate UAv2 regressions for apps that require same-origin visibility. It temporarily makes Chrome's implementation of UAv2 a bit closer to the old (v1) model, thus gives us time to work on an iframe attribute to declaratively allow user activation propagation to subframes (crbug.com/728334). We will remove this intermediate measure once the iframe attribute is ready. Bug: 867599 Change-Id: I67557a873177edf20ef809b2a976a740f32ed1d7 Reviewed-on: https://chromium-review.googlesource.com/c/1366761 Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#614883}(cherry picked from commit a5dfa60b3ab28bde867a6a411c5c4fd0e28f1bc1) Reviewed-on: https://chromium-review.googlesource.com/c/1370317 Reviewed-by: Mustaq Ahmed <mustaq@chromium.org> Cr-Commit-Position: refs/branch-heads/3626@{#220} Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
,
Jan 18
(4 days ago)
|
||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||
Comment 1 Deleted