New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require a user gesture for a cross-origin frame to navigate the top-level page #16

Open
ojanvafai opened this Issue Apr 22, 2016 · 72 comments

Comments

Projects
None yet
@ojanvafai
Member

ojanvafai commented Apr 22, 2016

We are seeing a lot of ads that navigate the top-level page outside of a user gesture. We think this is user hostile and that we don't lose any important use cases by requiring a user gesture. Chrome has added formal measurement for this. Once we get the numbers back, we plan to make this change.

There is also the allow-top-navigation flag for iframe sandbox attribute. Once we make this change the plan is that sandbox disallows top navigation and allow-top-navigation allows the behavior described above (i.e. even with allow-top-navigation, you'd still need a user gesture to navigate the top-level page).

@ojanvafai ojanvafai added the Chrome-P1 label Apr 22, 2016

@MattMenke2

This comment has been minimized.

Show comment
Hide comment
@MattMenke2

MattMenke2 Aug 17, 2016

Any consideration of doing this for modal dialogs as well? When I saw the email about not opening "popups" except in response to a user gesture, was excited about this because I thought it included blocking that particular behavior as well. A lot of abusive pages use OnBeforeUnload dialogs, which are just annoying.

Any consideration of doing this for modal dialogs as well? When I saw the email about not opening "popups" except in response to a user gesture, was excited about this because I thought it included blocking that particular behavior as well. A lot of abusive pages use OnBeforeUnload dialogs, which are just annoying.

@hillbrad

This comment has been minimized.

Show comment
Hide comment
@hillbrad

hillbrad Sep 28, 2016

:( This breaks a thing I'm working on. I'm trying to expose a cross-origin API in an iframe via postMessage. The parent frame uses postMessage to request a service from the iframe. If the request can be fulfilled without user confirmation, the iframe navigates the parent to a "success" page specified by the caller. Otherwise it makes a POST that navigates the parent frame to a confirmation page, which takes the user back to the specified "success" page after the user gesture.

I like the iframe top navigation pattern for a couple of reasons.

Compare it to the traditional workflow for doing this (as with OAuth) which requires POSTing directly to the cross-origin resource or opening a popup:

  • If user consent isn't required the user is taken directly to the "success" page without incurring a synchronous additional round-trip and redirect in the top frame, giving better perceived performance, responsiveness and less drop-off.
  • Popups suck and are frequently blocked.

The parent could implement another listener for a postMessage reply and do the navigation itself, but that makes using this kind of API more complicated, and it is nice to be able to do the POST from the iframe and include, e.g. a CSRF token and trustworthy indication of the parent origin that triggered the request.

A click to the iframe doesn't make sense; it takes away control over the UX that the parent wants.

Since a page that doesn't want this behavior from an iframe already has the ability to block top-navigation with the sandbox attribute, I'm not sure why we need to break this behavior by default?

Could we count receiving a postMessage from the parent as enabling navigation? (in addition to a user gesture)

:( This breaks a thing I'm working on. I'm trying to expose a cross-origin API in an iframe via postMessage. The parent frame uses postMessage to request a service from the iframe. If the request can be fulfilled without user confirmation, the iframe navigates the parent to a "success" page specified by the caller. Otherwise it makes a POST that navigates the parent frame to a confirmation page, which takes the user back to the specified "success" page after the user gesture.

I like the iframe top navigation pattern for a couple of reasons.

Compare it to the traditional workflow for doing this (as with OAuth) which requires POSTing directly to the cross-origin resource or opening a popup:

  • If user consent isn't required the user is taken directly to the "success" page without incurring a synchronous additional round-trip and redirect in the top frame, giving better perceived performance, responsiveness and less drop-off.
  • Popups suck and are frequently blocked.

The parent could implement another listener for a postMessage reply and do the navigation itself, but that makes using this kind of API more complicated, and it is nice to be able to do the POST from the iframe and include, e.g. a CSRF token and trustworthy indication of the parent origin that triggered the request.

A click to the iframe doesn't make sense; it takes away control over the UX that the parent wants.

Since a page that doesn't want this behavior from an iframe already has the ability to block top-navigation with the sandbox attribute, I'm not sure why we need to break this behavior by default?

Could we count receiving a postMessage from the parent as enabling navigation? (in addition to a user gesture)

@ramanathanrv

This comment has been minimized.

Show comment
Hide comment
@ramanathanrv

ramanathanrv Sep 29, 2016

For payments security, we collect sensitive card information within an embedded iFrame. A lot of our clients depend on our iFrame for this. Once the card information is collected in the iFrame, the user is then navigated (by changing window.top) to a page in our domain for authentication of the card information. This proposed change will break our flow permanently.

If allow-top-navigation is mentioned in the <iframe> tag, then the parent window has provided the consent. Can I request that the control to navigate top window be granted when the top window has given that permission?

For payments security, we collect sensitive card information within an embedded iFrame. A lot of our clients depend on our iFrame for this. Once the card information is collected in the iFrame, the user is then navigated (by changing window.top) to a page in our domain for authentication of the card information. This proposed change will break our flow permanently.

If allow-top-navigation is mentioned in the <iframe> tag, then the parent window has provided the consent. Can I request that the control to navigate top window be granted when the top window has given that permission?

@manki

This comment has been minimized.

Show comment
Hide comment
@manki

manki Sep 30, 2016

This is breaking sign-in flow for CapitalOne (https://servicing.capitalone.com/c1/Login.aspx). I see the following message in console:

Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://servicing.capitalone.com/c1/Login.aspx' from frame with URL 'https://login2.capitalone.com/loginweb/login/postLogin.do'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture. See https://www.chromestatus.com/features/5851021045661696.

I presume Capital One will have to fix their site, and Chrome is working as intended?

manki commented Sep 30, 2016

This is breaking sign-in flow for CapitalOne (https://servicing.capitalone.com/c1/Login.aspx). I see the following message in console:

Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://servicing.capitalone.com/c1/Login.aspx' from frame with URL 'https://login2.capitalone.com/loginweb/login/postLogin.do'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture. See https://www.chromestatus.com/features/5851021045661696.

I presume Capital One will have to fix their site, and Chrome is working as intended?

@reginaldos

This comment has been minimized.

Show comment
Hide comment
@reginaldos

reginaldos Oct 6, 2016

We received user reports that this is breaking users of the Facebook SDK. https://developers.facebook.com/docs/games/gamesonfacebook/login explicitly encourages use of top level navigation.

We received user reports that this is breaking users of the Facebook SDK. https://developers.facebook.com/docs/games/gamesonfacebook/login explicitly encourages use of top level navigation.

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Oct 12, 2016

Member

@reginaldos thanks for the report. Can you point us to an example page? We considering changing behavior here and being able to verify the new idea works would be helpful. It's hard for me to follow in that SDK documentation where top-level navigation is used.

Member

ojanvafai commented Oct 12, 2016

@reginaldos thanks for the report. Can you point us to an example page? We considering changing behavior here and being able to verify the new idea works would be helpful. It's hard for me to follow in that SDK documentation where top-level navigation is used.

@jontonsoup

This comment has been minimized.

Show comment
Hide comment
@jontonsoup

jontonsoup Oct 13, 2016

@ojanvafai this also seems to break typeform redirection

@ojanvafai this also seems to break typeform redirection

@loganrosen

This comment has been minimized.

Show comment
Hide comment
@loganrosen

loganrosen Oct 18, 2016

This broke eBay checkout flow for me. It hung after adding a credit card in PayPal, and an error in the console pointed me to this new Chrome feature.

In the console:

main.js:21966 Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://mbuy.ebay.com/xo?action=view&sessionid=(redacted)&redirect=mobile' from frame with URL 'https://www.paypal.com/webapps/helios?action=addCard&payer_id=(redacted)…hod%3DPAYPAL%26redirect%3Dmobile#/checkout/pageAddCard/addCardFlow/addCard'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture. See https://www.chromestatus.com/features/5851021045661696.

findWindowAndRedirect @ main.js:21966

This broke eBay checkout flow for me. It hung after adding a credit card in PayPal, and an error in the console pointed me to this new Chrome feature.

In the console:

main.js:21966 Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://mbuy.ebay.com/xo?action=view&sessionid=(redacted)&redirect=mobile' from frame with URL 'https://www.paypal.com/webapps/helios?action=addCard&payer_id=(redacted)…hod%3DPAYPAL%26redirect%3Dmobile#/checkout/pageAddCard/addCardFlow/addCard'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture. See https://www.chromestatus.com/features/5851021045661696.

findWindowAndRedirect @ main.js:21966

@Krinkle

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle Oct 21, 2016

This seems to break the ability to log in on My3 (https://www.three.co.uk/My3Account/Login) in Chrome 56.0.2885.0 canary.

Error:

After submitting log-in credentials, the user stays on a (now partially blank) login page instead proceeding to the My3 home page.

It still works in Chrome 53.0.2785.143 stable.

Krinkle commented Oct 21, 2016

This seems to break the ability to log in on My3 (https://www.three.co.uk/My3Account/Login) in Chrome 56.0.2885.0 canary.

Error:

After submitting log-in credentials, the user stays on a (now partially blank) login page instead proceeding to the My3 home page.

It still works in Chrome 53.0.2785.143 stable.

@natechapin

This comment has been minimized.

Show comment
Hide comment
@natechapin

natechapin Oct 26, 2016

I just reenabled this experiment in Chrome 56+ builds (should be on the chrome canary in a day or two) with a few changes to try to make it less breaking:

  • Instead of requiring a current user gesture, a cross-origin iframe can navigation top if it has ever received a user gesture.
  • When setting the bit that indicates whether a given browsing context has received a user gesture, it is also set on all of that browsing context's ancestors.

I just reenabled this experiment in Chrome 56+ builds (should be on the chrome canary in a day or two) with a few changes to try to make it less breaking:

  • Instead of requiring a current user gesture, a cross-origin iframe can navigation top if it has ever received a user gesture.
  • When setting the bit that indicates whether a given browsing context has received a user gesture, it is also set on all of that browsing context's ancestors.
@hillbrad

This comment has been minimized.

Show comment
Hide comment
@hillbrad

hillbrad Oct 27, 2016

I still think that the parent frame sending a postMessage should also
"activate" the iframe, or there needs to be a way to explicitly allow a
child frame to top-nav so without a user gesture. This is an important
cross-origin API surface. Iframes are not just ads.

On Wed, Oct 26, 2016 at 12:25 PM natechapin notifications@github.com
wrote:

I just reenabled this experiment in Chrome 56+ builds (should be on the
chrome canary in a day or two) with a few changes to try to make it less
breaking:

  • Instead of requiring a current user gesture, a cross-origin iframe
    can navigation top if it has ever received a user gesture.
  • When setting the bit that indicates whether a given browsing context
    has received a user gesture, it is also set on all of that browsing
    context's ancestors.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcAuXVIvL28tXEv6TmKkWFK9WGncOks5q36kXgaJpZM4IN2IH
.

I still think that the parent frame sending a postMessage should also
"activate" the iframe, or there needs to be a way to explicitly allow a
child frame to top-nav so without a user gesture. This is an important
cross-origin API surface. Iframes are not just ads.

On Wed, Oct 26, 2016 at 12:25 PM natechapin notifications@github.com
wrote:

I just reenabled this experiment in Chrome 56+ builds (should be on the
chrome canary in a day or two) with a few changes to try to make it less
breaking:

  • Instead of requiring a current user gesture, a cross-origin iframe
    can navigation top if it has ever received a user gesture.
  • When setting the bit that indicates whether a given browsing context
    has received a user gesture, it is also set on all of that browsing
    context's ancestors.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcAuXVIvL28tXEv6TmKkWFK9WGncOks5q36kXgaJpZM4IN2IH
.

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Oct 28, 2016

Member

@hillbrad is it possible for your case to postMessage back to the parent page to do the navigation?

Having postMessage auto-grant this ability would take all the value out of this proposal since postMessage is so widely used.

Maybe we should consider adding a permission that we can delegate down via feature policy (e.g. via an enable attribute on the iframe) to allow the top-level page to say the iframe can navigate it without a user gesture. @hillbrad would that work for your use case?

Member

ojanvafai commented Oct 28, 2016

@hillbrad is it possible for your case to postMessage back to the parent page to do the navigation?

Having postMessage auto-grant this ability would take all the value out of this proposal since postMessage is so widely used.

Maybe we should consider adding a permission that we can delegate down via feature policy (e.g. via an enable attribute on the iframe) to allow the top-level page to say the iframe can navigate it without a user gesture. @hillbrad would that work for your use case?

@hillbrad

This comment has been minimized.

Show comment
Hide comment
@hillbrad

hillbrad Oct 31, 2016

@ojanvafai an explicit opt-in or callback could work, but there are 7 independent bug reports here, which seems to indicate reasonably wide legitimate use.

What does the data look like on the prevalence of legitimate vs. user-hostile occurrences?

@ojanvafai an explicit opt-in or callback could work, but there are 7 independent bug reports here, which seems to indicate reasonably wide legitimate use.

What does the data look like on the prevalence of legitimate vs. user-hostile occurrences?

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Nov 1, 2016

Member

@hillbrad these bug reports were on the less permissive version that required a user gesture for the navigation instead of any user gesture during the life of the frame. It's hard to test all of these because most of them don't link to pages, but I confirmed that the capitalone case does get a user gesture today.

It's very hard to get data on prevalence of legitimate vs. user-hostile at scale. If we could distinguish the two reliably, we'd do a different intervention. :)

If we get reports of real content that breaks with this more permissive solution, we'll need to reconsider.

Member

ojanvafai commented Nov 1, 2016

@hillbrad these bug reports were on the less permissive version that required a user gesture for the navigation instead of any user gesture during the life of the frame. It's hard to test all of these because most of them don't link to pages, but I confirmed that the capitalone case does get a user gesture today.

It's very hard to get data on prevalence of legitimate vs. user-hostile at scale. If we could distinguish the two reliably, we'd do a different intervention. :)

If we get reports of real content that breaks with this more permissive solution, we'll need to reconsider.

@hillbrad

This comment has been minimized.

Show comment
Hide comment
@hillbrad

hillbrad Nov 1, 2016

It seems that any use of hidden frames as an API surface that includes
automatic navigation will still break under the new approach because they
have no way to collect a user gesture? So I think there should be a way to
designate a frame at creation as capable of top navigating, or to decorate
a postMessage so it delegates a capability equivalent to a user gesture,
before intervening and requiring a larger redesign of these existing uses.
Setting up an event listener, parsing and navigating in response to a reply
message is not terribly difficult, but it is much more complicated than a
simple fire-and-forget postMessage.

On Tue, Nov 1, 2016 at 8:07 AM ojan notifications@github.com wrote:

@hillbrad https://github.com/hillbrad these bug reports were on the
less permissive version that required a user gesture for the navigation
instead of any user gesture during the life of the frame. It's hard to test
all of these because most of them don't link to pages, but I confirmed that
the capitalone case does get a user gesture today.

It's very hard to get data on prevalence of legitimate vs. user-hostile at
scale. If we could distinguish the two reliably, we'd do a different
intervention. :)

If we get reports of real content that breaks with this more permissive
solution, we'll need to reconsider.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcErrIcZj7CJk4PmxONoJp3niR9dyks5q51W9gaJpZM4IN2IH
.

hillbrad commented Nov 1, 2016

It seems that any use of hidden frames as an API surface that includes
automatic navigation will still break under the new approach because they
have no way to collect a user gesture? So I think there should be a way to
designate a frame at creation as capable of top navigating, or to decorate
a postMessage so it delegates a capability equivalent to a user gesture,
before intervening and requiring a larger redesign of these existing uses.
Setting up an event listener, parsing and navigating in response to a reply
message is not terribly difficult, but it is much more complicated than a
simple fire-and-forget postMessage.

On Tue, Nov 1, 2016 at 8:07 AM ojan notifications@github.com wrote:

@hillbrad https://github.com/hillbrad these bug reports were on the
less permissive version that required a user gesture for the navigation
instead of any user gesture during the life of the frame. It's hard to test
all of these because most of them don't link to pages, but I confirmed that
the capitalone case does get a user gesture today.

It's very hard to get data on prevalence of legitimate vs. user-hostile at
scale. If we could distinguish the two reliably, we'd do a different
intervention. :)

If we get reports of real content that breaks with this more permissive
solution, we'll need to reconsider.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcErrIcZj7CJk4PmxONoJp3niR9dyks5q51W9gaJpZM4IN2IH
.

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Nov 1, 2016

Member

I think a way to delegate top navigation to subframes is reasonable. It would probably build on top of feature policy: https://wicg.github.io/feature-policy/. When we ship feature policy, I don't see any downside to adding the ability to delegate down the ability to do top-navigation without a gesture. But, I'm hesitant to block shipping this until then due to:

  1. The large user benefit this has.
  2. (so far) no complaints of real-world web sites breaking.
  3. The restriction can be worked around via a postMessage to the parent.

I do think we might want to explore having a postMessage that happens during a user-gesture grant the messaged-frame the ability to top-navigate since we pass the user gesture bit with the postMessage already (e.g. the inner frame's message handler can open popups, etc). That'd probably be good for keeping the platform simple and consistent. But, I think that doesn't actually address your need @hillbrad, right?

Member

ojanvafai commented Nov 1, 2016

I think a way to delegate top navigation to subframes is reasonable. It would probably build on top of feature policy: https://wicg.github.io/feature-policy/. When we ship feature policy, I don't see any downside to adding the ability to delegate down the ability to do top-navigation without a gesture. But, I'm hesitant to block shipping this until then due to:

  1. The large user benefit this has.
  2. (so far) no complaints of real-world web sites breaking.
  3. The restriction can be worked around via a postMessage to the parent.

I do think we might want to explore having a postMessage that happens during a user-gesture grant the messaged-frame the ability to top-navigate since we pass the user gesture bit with the postMessage already (e.g. the inner frame's message handler can open popups, etc). That'd probably be good for keeping the platform simple and consistent. But, I think that doesn't actually address your need @hillbrad, right?

@hillbrad

This comment has been minimized.

Show comment
Hide comment
@hillbrad

hillbrad Nov 1, 2016

If you can track a user gesture in a parent frame leading to an postMessage
to the child frame and carry the user intent flags through, that should
work for my specific use cases. But it would definitely be nice to have
something deterministic to set so every postMessage API documentation
doesn't need an extra page of explanation about this behavior.

On Tue, Nov 1, 2016 at 11:33 AM ojan notifications@github.com wrote:

I think a way to delegate top navigation to subframes is reasonable. It
would probably build on top of feature policy:
https://wicg.github.io/feature-policy/. When we ship feature policy, I
don't see any downside to adding the ability to delegate down the ability
to do top-navigation without a gesture. But, I'm hesitant to block shipping
this until then due to:

  1. The large user benefit this has.
  2. (so far) no complaints of real-world web sites breaking.
  3. The restriction can be worked around via a postMessage to the parent.

I do think we might want to explore having a postMessage that happens
during a user-gesture grant the messaged-frame the ability to top-navigate
since we pass the user gesture bit with the postMessage already (e.g. the
inner frame's message handler can open popups, etc). That'd probably be
good for keeping the platform simple and consistent. But, I think that
doesn't actually address your need @hillbrad https://github.com/hillbrad,
right?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcA9bW9ghj0R0rZqmkdkr06UgsBH3ks5q54YRgaJpZM4IN2IH
.

hillbrad commented Nov 1, 2016

If you can track a user gesture in a parent frame leading to an postMessage
to the child frame and carry the user intent flags through, that should
work for my specific use cases. But it would definitely be nice to have
something deterministic to set so every postMessage API documentation
doesn't need an extra page of explanation about this behavior.

On Tue, Nov 1, 2016 at 11:33 AM ojan notifications@github.com wrote:

I think a way to delegate top navigation to subframes is reasonable. It
would probably build on top of feature policy:
https://wicg.github.io/feature-policy/. When we ship feature policy, I
don't see any downside to adding the ability to delegate down the ability
to do top-navigation without a gesture. But, I'm hesitant to block shipping
this until then due to:

  1. The large user benefit this has.
  2. (so far) no complaints of real-world web sites breaking.
  3. The restriction can be worked around via a postMessage to the parent.

I do think we might want to explore having a postMessage that happens
during a user-gesture grant the messaged-frame the ability to top-navigate
since we pass the user gesture bit with the postMessage already (e.g. the
inner frame's message handler can open popups, etc). That'd probably be
good for keeping the platform simple and consistent. But, I think that
doesn't actually address your need @hillbrad https://github.com/hillbrad,
right?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcA9bW9ghj0R0rZqmkdkr06UgsBH3ks5q54YRgaJpZM4IN2IH
.

@limpygnome

This comment has been minimized.

Show comment
Hide comment
@limpygnome

limpygnome Dec 1, 2016

I'm seeing this in Chrome 56 (dev release), but not for post message. Does anyone know if this will definitely ship on January 31st? I am not familiar with the Chromium release cycle, and whether dates are strictly followed.

limpygnome commented Dec 1, 2016

I'm seeing this in Chrome 56 (dev release), but not for post message. Does anyone know if this will definitely ship on January 31st? I am not familiar with the Chromium release cycle, and whether dates are strictly followed.

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Dec 10, 2016

Member

@limpygnome the dates aren't strictly followed, but it should ship on January 31st give or take a week. Is this breaking a page for you?

Member

ojanvafai commented Dec 10, 2016

@limpygnome the dates aren't strictly followed, but it should ship on January 31st give or take a week. Is this breaking a page for you?

@jitdasrjs

This comment has been minimized.

Show comment
Hide comment
@jitdasrjs

jitdasrjs Dec 13, 2016

In our facebook application we can not redirect pages using top.location.href any more in chrome v56 beta.
It worked fine in previous version.Now javascript error is coming-The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture.

In our facebook application we can not redirect pages using top.location.href any more in chrome v56 beta.
It worked fine in previous version.Now javascript error is coming-The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture.

@tonygaillard

This comment has been minimized.

Show comment
Hide comment

https://apps.facebook.com/candycrush is broken on first install
https://apps.facebook.com/candycrushsoda is broken on first install
https://apps.facebook.com/livepool/ is broken on first install

@uofifox

This comment has been minimized.

Show comment
Hide comment
@uofifox

uofifox Dec 13, 2016

I have several applications that I work with that will be broken with this new feature. We have requirements for us to send users out to external websites and redirections. Why would you block an internal application from making decisions about where it should go?

In software if you don't provide a way for either a sub-element to communicate with the parent to help make informed decisions, or allow the child element to make a decision, you're in essence making the child restricted to basically a small task. There are many situations where the child is better suited to make decisions related to the situation it is being used and is basic to decomposing systems. Almost like inheritance, and saying the inherited element is allowed to only do a couple of things, but you can't add functionality.

Also note that many systems have clearly been built using iframes as modular breakdowns. Hopefully this feature will be augmented or an api will be added allowing the child frame to communicate with the parent otherwise I forsee chrome being an issue for many users moving forward.

uofifox commented Dec 13, 2016

I have several applications that I work with that will be broken with this new feature. We have requirements for us to send users out to external websites and redirections. Why would you block an internal application from making decisions about where it should go?

In software if you don't provide a way for either a sub-element to communicate with the parent to help make informed decisions, or allow the child element to make a decision, you're in essence making the child restricted to basically a small task. There are many situations where the child is better suited to make decisions related to the situation it is being used and is basic to decomposing systems. Almost like inheritance, and saying the inherited element is allowed to only do a couple of things, but you can't add functionality.

Also note that many systems have clearly been built using iframes as modular breakdowns. Hopefully this feature will be augmented or an api will be added allowing the child frame to communicate with the parent otherwise I forsee chrome being an issue for many users moving forward.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 13, 2016

an api will be added allowing the child frame to communicate with the parent

This sounds like the already-existing postMessage API

domenic commented Dec 13, 2016

an api will be added allowing the child frame to communicate with the parent

This sounds like the already-existing postMessage API

@uofifox

This comment has been minimized.

Show comment
Hide comment
@uofifox

uofifox Dec 13, 2016

Valid point, looks like the postMesage API could be used to accomplish the issue. Of course means the parent frame would need to add a listener to the events. Thank you for the reference.

uofifox commented Dec 13, 2016

Valid point, looks like the postMesage API could be used to accomplish the issue. Of course means the parent frame would need to add a listener to the events. Thank you for the reference.

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Dec 14, 2016

Member

@tonygaillard this looks like a separate bug. Those apps are broken with this change disabled as well. Filed crbug.com/674229 to track that.

@uofifox sounds like your issue is resolved?

Member

ojanvafai commented Dec 14, 2016

@tonygaillard this looks like a separate bug. Those apps are broken with this change disabled as well. Filed crbug.com/674229 to track that.

@uofifox sounds like your issue is resolved?

@uofifox

This comment has been minimized.

Show comment
Hide comment
@uofifox

uofifox Dec 14, 2016

Well I would prefer the feature not get implemented as opposed to saying my issue is resolved. In my case it's great there is a workaround but as I don't have control over the main frame it means we have to ask for feature enhancements which take time to implement

uofifox commented Dec 14, 2016

Well I would prefer the feature not get implemented as opposed to saying my issue is resolved. In my case it's great there is a workaround but as I don't have control over the main frame it means we have to ask for feature enhancements which take time to implement

@joeedh

This comment has been minimized.

Show comment
Hide comment
@joeedh

joeedh Dec 15, 2016

What is a "user gesture"?

joeedh commented Dec 15, 2016

What is a "user gesture"?

@uofifox

This comment has been minimized.

Show comment
Hide comment
@uofifox

uofifox Dec 15, 2016

User initiated action

uofifox commented Dec 15, 2016

User initiated action

@tonygaillard

This comment has been minimized.

Show comment
Hide comment
@tonygaillard

tonygaillard Dec 15, 2016

@uofifox Nope, this is this bug/feature, because the redirection in JavaScript is not allowed. Go to either one of the application and open the developer console to notice the issue.

@uofifox Nope, this is this bug/feature, because the redirection in JavaScript is not allowed. Go to either one of the application and open the developer console to notice the issue.

@jerodvenemafm

This comment has been minimized.

Show comment
Hide comment
@jerodvenemafm

jerodvenemafm Dec 22, 2016

This is impacting a site of mine as well, which has an iframe-based login page. We do a login in the iframe via SAML (don't ask), and then on completion, a postMessage to signal the parent to navigate, which fails under the new rules. This is on the same root domain (different subdomains). I'd be OK with a frame-level setting to enable the behavior, or enabling via postMessage.

This is impacting a site of mine as well, which has an iframe-based login page. We do a login in the iframe via SAML (don't ask), and then on completion, a postMessage to signal the parent to navigate, which fails under the new rules. This is on the same root domain (different subdomains). I'd be OK with a frame-level setting to enable the behavior, or enabling via postMessage.

@elexisvenator

This comment has been minimized.

Show comment
Hide comment
@elexisvenator

elexisvenator Jan 2, 2017

This issue also impacts the use of the SecureFrame payment api from SecurePay. After payment is made, SecurePay is meant to redirect to a url on your site to notify your application of successful payment. This never happens and results in payments being made without the application knowing about it (reconciliation nightmare).

I have pointed this out to the SecurePay devs, who say they will monitor this feature.

SecurePay SecureFrame integration guide for reference: https://www.securepay.com.au/_uploads/files/SecureFrame_Integration_Guide.pdf

This issue also impacts the use of the SecureFrame payment api from SecurePay. After payment is made, SecurePay is meant to redirect to a url on your site to notify your application of successful payment. This never happens and results in payments being made without the application knowing about it (reconciliation nightmare).

I have pointed this out to the SecurePay devs, who say they will monitor this feature.

SecurePay SecureFrame integration guide for reference: https://www.securepay.com.au/_uploads/files/SecureFrame_Integration_Guide.pdf

@chrisbro-MSFT

This comment has been minimized.

Show comment
Hide comment
@chrisbro-MSFT

chrisbro-MSFT Jan 3, 2017

This also breaks login flows for Microsoft Office Online. Example flow:

  1. A Dropbox for Business user clicks on a .docx file in the Dropbox web UI.
  2. Dropbox iframes the Word Online app which runs on a different domain.
  3. Word Online checks for the user's login cookie and, not finding it, needs to redirect them to the Office 365 login page. Login pages can't be framed, of course, so it needs to navigate window.top to the login experience. This breaks in Chrome 56.

Here's some documentation on how that flow works: https://wopi.readthedocs.io/en/latest/scenarios/business.html#validating-edit-capabilities

We see two workarounds right now:

  1. We could deliver a little blob of HTML that says "hey buddy you need to log in, click here" and the user would click that to go to the page that asks them to log in. Degrades the user experience by forcing the user to click instead of redirecting them automatically so we'd only do this for Chrome users, but it would technically work and will be our plan if you don't provide another solution.
  2. If you implement a way for the host page to opt-in to this behavior, we could probably get all of our partners to implement the workaround by end of month. It only breaks their paying business users so they'll be motivated to work quickly...

If you'd like to discuss this in email, my email address is my username at microsoft.com.

This also breaks login flows for Microsoft Office Online. Example flow:

  1. A Dropbox for Business user clicks on a .docx file in the Dropbox web UI.
  2. Dropbox iframes the Word Online app which runs on a different domain.
  3. Word Online checks for the user's login cookie and, not finding it, needs to redirect them to the Office 365 login page. Login pages can't be framed, of course, so it needs to navigate window.top to the login experience. This breaks in Chrome 56.

Here's some documentation on how that flow works: https://wopi.readthedocs.io/en/latest/scenarios/business.html#validating-edit-capabilities

We see two workarounds right now:

  1. We could deliver a little blob of HTML that says "hey buddy you need to log in, click here" and the user would click that to go to the page that asks them to log in. Degrades the user experience by forcing the user to click instead of redirecting them automatically so we'd only do this for Chrome users, but it would technically work and will be our plan if you don't provide another solution.
  2. If you implement a way for the host page to opt-in to this behavior, we could probably get all of our partners to implement the workaround by end of month. It only breaks their paying business users so they'll be motivated to work quickly...

If you'd like to discuss this in email, my email address is my username at microsoft.com.

@lubin2010

This comment has been minimized.

Show comment
Hide comment
@lubin2010

lubin2010 Jan 3, 2017

Working on a related effort #42: "Require a user gesture for sandboxed iframe w/ 'allow-top-navigation' to navigate the top-level page" which has a similar purpose as this one but covers different use cases and might break less pages and thus less risky. Any concern about it?

lubin2010 commented Jan 3, 2017

Working on a related effort #42: "Require a user gesture for sandboxed iframe w/ 'allow-top-navigation' to navigate the top-level page" which has a similar purpose as this one but covers different use cases and might break less pages and thus less risky. Any concern about it?

@chrisbro-MSFT

This comment has been minimized.

Show comment
Hide comment
@chrisbro-MSFT

chrisbro-MSFT Jan 3, 2017

@lubin2010 - thanks, no immediate concerns as I don't think any hosts load our apps via sandboxed iframes, and if we do find issues the workaround is clear.

@lubin2010 - thanks, no immediate concerns as I don't think any hosts load our apps via sandboxed iframes, and if we do find issues the workaround is clear.

@limpygnome

This comment has been minimized.

Show comment
Hide comment
@limpygnome

limpygnome Jan 4, 2017

@ojanvafai yes, this breaks our payment pages for an iframe integration, whereby it needs to redirect the parent page. Our product processes a large volume of transactions for tier one/two merchants, so we're watching this closely and releasing a fix before the scheduled Chromium release date.

For now we've fixed it using post message, tested against Chrome 56 dev. This does not require any user interaction. Would this work-around be broken in the future?

@ojanvafai yes, this breaks our payment pages for an iframe integration, whereby it needs to redirect the parent page. Our product processes a large volume of transactions for tier one/two merchants, so we're watching this closely and releasing a fix before the scheduled Chromium release date.

For now we've fixed it using post message, tested against Chrome 56 dev. This does not require any user interaction. Would this work-around be broken in the future?

@Hammadk

This comment has been minimized.

Show comment
Hide comment
@Hammadk

Hammadk Jan 4, 2017

Shopify's embedded app SDK requires top level navigation with window.top.location.href during OAuth. This is similar to Facebook's SDK and many other platforms that assume this functionality -- this change will break logins on a lot of platforms.

This is a reasonable change (to prevent malicious ads) but it should be delayed and at least have a deprecation warning that Chrome developers (non-Canary) would see. That'll give developers more time to come up with other approaches.

Hammadk commented Jan 4, 2017

Shopify's embedded app SDK requires top level navigation with window.top.location.href during OAuth. This is similar to Facebook's SDK and many other platforms that assume this functionality -- this change will break logins on a lot of platforms.

This is a reasonable change (to prevent malicious ads) but it should be delayed and at least have a deprecation warning that Chrome developers (non-Canary) would see. That'll give developers more time to come up with other approaches.

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Jan 4, 2017

Member

@jerodvenemafm I don't quite understand your example. postMessage to the parent and then the parent navigating the top-level page should be unaffected by this change. Do you have a page you can point us to so we can understand what's going on?

@elexisvenator can you point to an example that breaks? Reading through the pdf it seems like the user would be require to interact with the frame?

@limpygnome using postMessage should be totally safe. The point of this change is to make it so that the top-level page is in control of navigations. If the top-level page does the navigation in response to a postMessage, then it's still in charge. :)

@Hammadk, do you have a page you could link us to that we can test?

For now, I think we'll probably change Chrome to show a console warning instead of blocking while we evaluate our options here. Thanks all for the feedback! In general, pointing us to actual sites that break is most helpful because then we can try our best to design solutions that don't break them whenever possible.

Member

ojanvafai commented Jan 4, 2017

@jerodvenemafm I don't quite understand your example. postMessage to the parent and then the parent navigating the top-level page should be unaffected by this change. Do you have a page you can point us to so we can understand what's going on?

@elexisvenator can you point to an example that breaks? Reading through the pdf it seems like the user would be require to interact with the frame?

@limpygnome using postMessage should be totally safe. The point of this change is to make it so that the top-level page is in control of navigations. If the top-level page does the navigation in response to a postMessage, then it's still in charge. :)

@Hammadk, do you have a page you could link us to that we can test?

For now, I think we'll probably change Chrome to show a console warning instead of blocking while we evaluate our options here. Thanks all for the feedback! In general, pointing us to actual sites that break is most helpful because then we can try our best to design solutions that don't break them whenever possible.

@jerodvenemafm

This comment has been minimized.

Show comment
Hide comment
@jerodvenemafm

jerodvenemafm Jan 4, 2017

URL is private. But it's part of the login process.

Iframe login->POST->successful login->postMessage to parent->parent redirects

The iframe resides on a different sub-domain than the main app.

URL is private. But it's part of the login process.

Iframe login->POST->successful login->postMessage to parent->parent redirects

The iframe resides on a different sub-domain than the main app.

@Hammadk

This comment has been minimized.

Show comment
Hide comment
@Hammadk

Hammadk Jan 4, 2017

Thanks Ojan. Shopify's apps are private and available to merchants with online stores. If you have trial store, you can install embedded apps to test this change:
https://YOUR-SHOP.myshopify.com/admin/apps/shopify-widgets

If you don't have a Shopify store, our setup is pretty similar to Facebook apps. You can test this change by installing a Facebook app:
https://apps.facebook.com/livepool/

Hammadk commented Jan 4, 2017

Thanks Ojan. Shopify's apps are private and available to merchants with online stores. If you have trial store, you can install embedded apps to test this change:
https://YOUR-SHOP.myshopify.com/admin/apps/shopify-widgets

If you don't have a Shopify store, our setup is pretty similar to Facebook apps. You can test this change by installing a Facebook app:
https://apps.facebook.com/livepool/

@elexisvenator

This comment has been minimized.

Show comment
Hide comment
@elexisvenator

elexisvenator Jan 4, 2017

Ojan,
The last step of the SecurePay payment process is to confirm payment via clicking a button. This redirects the iframe to a "payment is processing" page which after a while redirects the parent to the payment complete page. It is this last redirect that appears to fail.

As for examples, I am afraid our application doe not have any publicly accessible sites with the test payment interface configured. Securepay also does not appear to have a public demo. An example of an actual live site would be https://shopmate.auspost.com.au/ (auspost is their parent company).

elexisvenator commented Jan 4, 2017

Ojan,
The last step of the SecurePay payment process is to confirm payment via clicking a button. This redirects the iframe to a "payment is processing" page which after a while redirects the parent to the payment complete page. It is this last redirect that appears to fail.

As for examples, I am afraid our application doe not have any publicly accessible sites with the test payment interface configured. Securepay also does not appear to have a public demo. An example of an actual live site would be https://shopmate.auspost.com.au/ (auspost is their parent company).

@adob

This comment has been minimized.

Show comment
Hide comment
@adob

adob Jan 6, 2017

👎 👎 This change appears to be causing a lot of breakage in my end-to-end Selenium/WebDriver because a lot of the interaction is not treated as user-initiated.

adob commented Jan 6, 2017

👎 👎 This change appears to be causing a lot of breakage in my end-to-end Selenium/WebDriver because a lot of the interaction is not treated as user-initiated.

@limpygnome

This comment has been minimized.

Show comment
Hide comment
@limpygnome

limpygnome Jan 7, 2017

@ojanvafai unfortunately we've had a few issues with using an alternative in such a short time period.

Can you definitely confirm whether Chrome 56 will be changed to feature a console message instead? I think we're still seeing the blocked behaviour on dev.

@ojanvafai unfortunately we've had a few issues with using an alternative in such a short time period.

Can you definitely confirm whether Chrome 56 will be changed to feature a console message instead? I think we're still seeing the blocked behaviour on dev.

@lubin2010

This comment has been minimized.

Show comment
Hide comment
@lubin2010

lubin2010 Jan 8, 2017

@limpygnome AFAIK, yes. The code was submitted and will be merged in Chrome 56:
https://bugs.chromium.org/p/chromium/issues/detail?id=678328

@limpygnome AFAIK, yes. The code was submitted and will be merged in Chrome 56:
https://bugs.chromium.org/p/chromium/issues/detail?id=678328

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Jan 9, 2017

Member

Thanks for all the bug reports. We're working on reverting it in Chrome 56 and are working on a slightly more permissive solution for Chrime 57.

For those of you who have commented on breakage, since we can't test sites we don't have access to, it would be really helpful if you could tell us if proposed next attempt will still break your pages. Also, we should have it behind a flag in a week or two for you to test.

The Chrome 56 behavior requires the document to have ever had a user gesture. Which means that the bit is lost when the iframe is navigated. For Chrome 57, we're going to try the same thing, but will make it only require that that iframe had a user gesture ad some point. Namely, it will survive navigations in that iframe.

This will still break cases where an iframe is completely hidden from the user and the user never clicks or types in it.

Incidentally, I ran into https://news.ycombinator.com/item?id=13356074 today as an example of the sort of problem this change will mitigate.

Member

ojanvafai commented Jan 9, 2017

Thanks for all the bug reports. We're working on reverting it in Chrome 56 and are working on a slightly more permissive solution for Chrime 57.

For those of you who have commented on breakage, since we can't test sites we don't have access to, it would be really helpful if you could tell us if proposed next attempt will still break your pages. Also, we should have it behind a flag in a week or two for you to test.

The Chrome 56 behavior requires the document to have ever had a user gesture. Which means that the bit is lost when the iframe is navigated. For Chrome 57, we're going to try the same thing, but will make it only require that that iframe had a user gesture ad some point. Namely, it will survive navigations in that iframe.

This will still break cases where an iframe is completely hidden from the user and the user never clicks or types in it.

Incidentally, I ran into https://news.ycombinator.com/item?id=13356074 today as an example of the sort of problem this change will mitigate.

@riking

This comment has been minimized.

Show comment
Hide comment
@riking

riking Jan 11, 2017

since we can't test sites we don't have access to

Here's one that should be easy to test: https://www.twitch.tv/products/bits/B018WMZN5E

UI path to that URL:

  • Create an account on www.twitch.tv
  • Go to any partnered channel with Bits enabled
  • Attempt to buy $5.00 worth of Bits ($7.00 button)
  • Popup gets error

Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://www.twitch.tv/products/bits/B018YYYYYY?tv=eyJraWQiOiJjb20uYW1hem9uL…BlvswUhD7tKzLMVWz91pSgc_mvfn0id23MY2w' from frame with URL 'https://twitch.amazon.com/checkout/summary?embed=true&asin=B018YYYYYY&tuid=eyJraWQiOiJjb20uYW1hem9uL…BlvswUhD7tKzLMVWz91pSgc_mvfn0id23MY2w'.

riking commented Jan 11, 2017

since we can't test sites we don't have access to

Here's one that should be easy to test: https://www.twitch.tv/products/bits/B018WMZN5E

UI path to that URL:

  • Create an account on www.twitch.tv
  • Go to any partnered channel with Bits enabled
  • Attempt to buy $5.00 worth of Bits ($7.00 button)
  • Popup gets error

Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://www.twitch.tv/products/bits/B018YYYYYY?tv=eyJraWQiOiJjb20uYW1hem9uL…BlvswUhD7tKzLMVWz91pSgc_mvfn0id23MY2w' from frame with URL 'https://twitch.amazon.com/checkout/summary?embed=true&asin=B018YYYYYY&tuid=eyJraWQiOiJjb20uYW1hem9uL…BlvswUhD7tKzLMVWz91pSgc_mvfn0id23MY2w'.

@mikewoo200

This comment has been minimized.

Show comment
Hide comment
@mikewoo200

mikewoo200 Jan 12, 2017

Here is the eBay Checkout flow that was broken in Version 56.0.2924.51 beta (64-bit) - before this change was reverted recently.

  1. Go to ebay (www.ebay.com) and sign in
  2. Buy any item to get to checkout page. I used item id 121409414417

http://www.ebay.com/itm/eBay-Mobile-QA-10-0-Test-Item-12-/121409414417

  1. In Checkout page, click on PayPal or PayPal Credit to open the PayPal sign-in layer
  2. Without logging into PayPal, close the PayPal layer that came up
  3. The Unsafe JS error shows in console log. User is stuck with the page mask, unable to use the page
  4. User refreshes eBay checkout page but user is NOT signed into PayPal
  5. User who wants to pay with PayPal is now stuck in infinite loop

Thanks.

Here is the eBay Checkout flow that was broken in Version 56.0.2924.51 beta (64-bit) - before this change was reverted recently.

  1. Go to ebay (www.ebay.com) and sign in
  2. Buy any item to get to checkout page. I used item id 121409414417

http://www.ebay.com/itm/eBay-Mobile-QA-10-0-Test-Item-12-/121409414417

  1. In Checkout page, click on PayPal or PayPal Credit to open the PayPal sign-in layer
  2. Without logging into PayPal, close the PayPal layer that came up
  3. The Unsafe JS error shows in console log. User is stuck with the page mask, unable to use the page
  4. User refreshes eBay checkout page but user is NOT signed into PayPal
  5. User who wants to pay with PayPal is now stuck in infinite loop

Thanks.

@linkkingjay

This comment has been minimized.

Show comment
Hide comment
@linkkingjay

linkkingjay Jan 16, 2017

This also breaks WeChat OAuth login flows. Example flow:

  1. A web application use an iframe to insert a QR code in its login page.
  2. User use WeChat app in his/her phone to scan the QR code.
  3. After confirming login in WeChat app, the iframe will redirect the parent to home page.

https://www.weiyun.com/

POC:

success() {
  window.top.location = redirect_url
}

image

This also breaks WeChat OAuth login flows. Example flow:

  1. A web application use an iframe to insert a QR code in its login page.
  2. User use WeChat app in his/her phone to scan the QR code.
  3. After confirming login in WeChat app, the iframe will redirect the parent to home page.

https://www.weiyun.com/

POC:

success() {
  window.top.location = redirect_url
}

image

@limpygnome

This comment has been minimized.

Show comment
Hide comment
@limpygnome

limpygnome Jan 30, 2017

Do you have any detail around how this will be more "permissive" in Chrome 57?

Do you have any detail around how this will be more "permissive" in Chrome 57?

@mikewoo200

This comment has been minimized.

Show comment
Hide comment
@mikewoo200

mikewoo200 Jan 30, 2017

Will the "more permissive" version come in version 57 still? If so, when will we get a beta version to test?

Will the "more permissive" version come in version 57 still? If so, when will we get a beta version to test?

@natechapin

This comment has been minimized.

Show comment
Hide comment
@natechapin

natechapin Jan 30, 2017

@limpygnome In Chrome 57, if an iframe has ever received a user gesture, then the iframe can navigate top. The reverted experiment in Chrome 56 reset this state when the iframe navigated to a different document.

@mikewoo200 Yes, the more permissive version should be available in Chrome 57 builds (currently on canary and dev channels, not sure when the 57 beta will ship).

@limpygnome In Chrome 57, if an iframe has ever received a user gesture, then the iframe can navigate top. The reverted experiment in Chrome 56 reset this state when the iframe navigated to a different document.

@mikewoo200 Yes, the more permissive version should be available in Chrome 57 builds (currently on canary and dev channels, not sure when the 57 beta will ship).

@lubin2010

This comment has been minimized.

Show comment
Hide comment
@lubin2010

lubin2010 Feb 3, 2017

The Chrome 57 beta has been released to Desktop and Android (see the blog post), and it can be downloaded here. Please feel free to test it and report any issue you find. Thanks.

The Chrome 57 beta has been released to Desktop and Android (see the blog post), and it can be downloaded here. Please feel free to test it and report any issue you find. Thanks.

@mikewoo200

This comment has been minimized.

Show comment
Hide comment
@mikewoo200

mikewoo200 Feb 3, 2017

  1. What's the scheduled release date of Chrome 57 with this "more permissive" feature?
  2. Is this particular feature considered complete for Chrome 57?

One version of eBay checkout is still broken with this "more permissive" version (but broken differently from 56 Beta), with this error:

The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor has it received a user gesture. See https://www.chromestatus.com/features/5851021045661696.

We will work on a fix using this version of Chrome 57 Beta.

mikewoo200 commented Feb 3, 2017

  1. What's the scheduled release date of Chrome 57 with this "more permissive" feature?
  2. Is this particular feature considered complete for Chrome 57?

One version of eBay checkout is still broken with this "more permissive" version (but broken differently from 56 Beta), with this error:

The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor has it received a user gesture. See https://www.chromestatus.com/features/5851021045661696.

We will work on a fix using this version of Chrome 57 Beta.

@lubin2010

This comment has been minimized.

Show comment
Hide comment
@lubin2010

lubin2010 Feb 3, 2017

@mikewoo200 Could you share how to reproduce that broken checkout process on eBay? I couldn't reproduce it with the steps you mentioned above.

@mikewoo200 Could you share how to reproduce that broken checkout process on eBay? I couldn't reproduce it with the steps you mentioned above.

@mikewoo200

This comment has been minimized.

Show comment
Hide comment
@mikewoo200

mikewoo200 Feb 3, 2017

@lubin2010, Here are new steps for Chrome 57 Beta.

  1. Go to ebay (www.ebay.co.uk) and sign in. (Notice it's UK site)
  2. Buy any item to get to checkout page. I used item id 121409414417
    http://www.ebay.co.uk/itm/eBay-Mobile-QA-10-0-Test-Item-12-/121409414417
  3. Once the UK checkout page is loaded, click on PayPal or PayPal Credit to open the PayPal sign-in layer (pop up window)
  4. Without logging into PayPal, close the PayPal layer that came up
  5. The Unsafe JS error shows in console log. User is stuck with the page mask, unable to use the page
  6. User refreshes eBay checkout page but user is NOT signed into PayPal
  7. User who wants to pay with PayPal is now stuck in infinite loop

Thanks.

@lubin2010, Here are new steps for Chrome 57 Beta.

  1. Go to ebay (www.ebay.co.uk) and sign in. (Notice it's UK site)
  2. Buy any item to get to checkout page. I used item id 121409414417
    http://www.ebay.co.uk/itm/eBay-Mobile-QA-10-0-Test-Item-12-/121409414417
  3. Once the UK checkout page is loaded, click on PayPal or PayPal Credit to open the PayPal sign-in layer (pop up window)
  4. Without logging into PayPal, close the PayPal layer that came up
  5. The Unsafe JS error shows in console log. User is stuck with the page mask, unable to use the page
  6. User refreshes eBay checkout page but user is NOT signed into PayPal
  7. User who wants to pay with PayPal is now stuck in infinite loop

Thanks.

@MrStonedOne

This comment has been minimized.

Show comment
Hide comment
@MrStonedOne

MrStonedOne Feb 16, 2017

It seems like this should be opt in on the site, not opt out.

I'm failing to understand why breaking the flow of every oauth system out there (including mine) is necessary.

MrStonedOne commented Feb 16, 2017

It seems like this should be opt in on the site, not opt out.

I'm failing to understand why breaking the flow of every oauth system out there (including mine) is necessary.

@MrStonedOne

This comment has been minimized.

Show comment
Hide comment
@MrStonedOne

MrStonedOne Feb 16, 2017

Or actually, why are we not giving a topbar or a redirection blocked ui (like the popup blocked ui) to give the user the ability to say no, go ahead to that site.

Or actually, why are we not giving a topbar or a redirection blocked ui (like the popup blocked ui) to give the user the ability to say no, go ahead to that site.

@ziyunfei

This comment has been minimized.

Show comment
Hide comment
@ziyunfei

ziyunfei Feb 17, 2017

An opt-out should be provided, but personally, I don't want a popup blocking UI 😜.

An opt-out should be provided, but personally, I don't want a popup blocking UI 😜.

@MrStonedOne

This comment has been minimized.

Show comment
Hide comment
@MrStonedOne

MrStonedOne Feb 17, 2017

except heres the thing, I'm encountering this for my oauth workflow, only i don't have the ability to work around it. So allowing the user to approve the redirection is the only way my shit will work.

except heres the thing, I'm encountering this for my oauth workflow, only i don't have the ability to work around it. So allowing the user to approve the redirection is the only way my shit will work.

@chrcoluk

This comment has been minimized.

Show comment
Hide comment
@chrcoluk

chrcoluk Feb 27, 2017

found this page after seeing this flag was toggled to an enabled state in chrome://flags when I didnt make the change myself, is chrome now automatically enabling some experimental flags now?

found this page after seeing this flag was toggled to an enabled state in chrome://flags when I didnt make the change myself, is chrome now automatically enabling some experimental flags now?

@aels

This comment has been minimized.

Show comment
Hide comment
@aels

aels Feb 27, 2017

@chrcoluk, yes, all "Default" state flags can be toggled to "On" by chrome/google guys at any time.

aels commented Feb 27, 2017

@chrcoluk, yes, all "Default" state flags can be toggled to "On" by chrome/google guys at any time.

@mexhanic

This comment has been minimized.

Show comment
Hide comment
@mexhanic

mexhanic Mar 22, 2017

@ojanvafai
@lubin2010
You want to hit all rabbits with one bullet, but what about granular solution?
We have one thing, that brokes - oAuth, and one thing that must be stoped - ads framebusting.

So, lets assume we whitelist of (for example) "top Alexa 1k" domains, which allowed to bust-out their cross-domain top's. But let them still throw console warning from frame page, to notice developers.

If our frame is not in whitelist, let assume following algo when frame page try to bust-out (and cross-domain, and no gesture given):

  • issue a warning to console from frame page (no notice frame-page developers)
  • show access-request dialog on top page (like camera access request)
  • issue a warning to console from top page (with url of frame-initiator), to allow in-page reporters to log, that someone wants to redirect us.
  • if "granted", then pause redirection for 2 seconds and issue a warning from top page, to allow of logging this redirection. Then redirect.
  • if "declined", then throw error to frame page, and issue warning to top page, to allow top-page developers to log incident.

Mechanism of "warnings" is on your own. But I think it will be good to include not only frame url, but urls of all frames in chain, in case of nested frames.
That raises second problem - possible leakage of any secure tokens inside intermediate urls to the top-page. But that needs additional research.

@ojanvafai
@lubin2010
You want to hit all rabbits with one bullet, but what about granular solution?
We have one thing, that brokes - oAuth, and one thing that must be stoped - ads framebusting.

So, lets assume we whitelist of (for example) "top Alexa 1k" domains, which allowed to bust-out their cross-domain top's. But let them still throw console warning from frame page, to notice developers.

If our frame is not in whitelist, let assume following algo when frame page try to bust-out (and cross-domain, and no gesture given):

  • issue a warning to console from frame page (no notice frame-page developers)
  • show access-request dialog on top page (like camera access request)
  • issue a warning to console from top page (with url of frame-initiator), to allow in-page reporters to log, that someone wants to redirect us.
  • if "granted", then pause redirection for 2 seconds and issue a warning from top page, to allow of logging this redirection. Then redirect.
  • if "declined", then throw error to frame page, and issue warning to top page, to allow top-page developers to log incident.

Mechanism of "warnings" is on your own. But I think it will be good to include not only frame url, but urls of all frames in chain, in case of nested frames.
That raises second problem - possible leakage of any secure tokens inside intermediate urls to the top-page. But that needs additional research.

@mexhanic

This comment has been minimized.

Show comment
Hide comment
@mexhanic

mexhanic Mar 22, 2017

And second idea.
Mostly all of ad-frames have specific size (like 300x250), when oAuth-frames haven't.
So, if any of frames in chain from redirect-initiator to top page have ad-like size, then block.

And second idea.
Mostly all of ad-frames have specific size (like 300x250), when oAuth-frames haven't.
So, if any of frames in chain from redirect-initiator to top page have ad-like size, then block.

@lubin2010

This comment has been minimized.

Show comment
Hide comment
@lubin2010

lubin2010 Mar 23, 2017

We've reverted the change in Chrome 57, and are rethinking how to go forward with this, and will keep you updated once there is more to share. Thanks all for the feedback!

We've reverted the change in Chrome 57, and are rethinking how to go forward with this, and will keep you updated once there is more to share. Thanks all for the feedback!

@oniric85

This comment has been minimized.

Show comment
Hide comment
@oniric85

oniric85 Aug 7, 2017

Today I saw the warning the first time on my Chrome Console. We have a login system based on OAuth that automatically redirects to a success page by changing top navigation from inside the iframe. This breaks now that I activated the flag in Chrome flags as it does not require any user gesture on certain condition to increase responsiveness and performances.

Is this moving forward? Is there any way to whitelist the behavior from the top page?

oniric85 commented Aug 7, 2017

Today I saw the warning the first time on my Chrome Console. We have a login system based on OAuth that automatically redirects to a success page by changing top navigation from inside the iframe. This breaks now that I activated the flag in Chrome flags as it does not require any user gesture on certain condition to increase responsiveness and performances.

Is this moving forward? Is there any way to whitelist the behavior from the top page?

@lubin2010

This comment has been minimized.

Show comment
Hide comment
@lubin2010

lubin2010 Aug 7, 2017

Adding @ojanvafai to comment on the status of this.

lubin2010 commented Aug 7, 2017

Adding @ojanvafai to comment on the status of this.

@oniric85

This comment has been minimized.

Show comment
Hide comment
@oniric85

oniric85 Aug 14, 2017

Any news? We could really make use of some rough timings as to adapt to this change as we would need to plan work on several systems that currently rely on this feature, probably switching to postMessage.

Any news? We could really make use of some rough timings as to adapt to this change as we would need to plan work on several systems that currently rely on this feature, probably switching to postMessage.

@tomloake

This comment has been minimized.

Show comment
Hide comment
@tomloake

tomloake Oct 3, 2017

I noticed some of the work to unblock this has happened recently (main frame navigation consumes a user gesture) has started to move forwards - do we have any updates on this status of this bug now?

tomloake commented Oct 3, 2017

I noticed some of the work to unblock this has happened recently (main frame navigation consumes a user gesture) has started to move forwards - do we have any updates on this status of this bug now?

@MrStonedOne

This comment has been minimized.

Show comment
Hide comment
@MrStonedOne

MrStonedOne Oct 3, 2017

This issue is, (and will always be) detection.

A script (be it a good faith one like sso/oauth, or a bad faith one like ads) that fails to meet the criteria will have no way of knowing before hand, and will have its entire frame errored out, leaving no way to recover from the error or fallback to a gesture request.

This issue is, (and will always be) detection.

A script (be it a good faith one like sso/oauth, or a bad faith one like ads) that fails to meet the criteria will have no way of knowing before hand, and will have its entire frame errored out, leaving no way to recover from the error or fallback to a gesture request.

@lubin2010

This comment has been minimized.

Show comment
Hide comment
@lubin2010

lubin2010 Nov 14, 2017

It was announced that in Chrome 64 (To be the stable version in around late Jan, 2018), all redirects originating from third-party iframes will show an infobar instead of redirecting, unless the user had been interacting with that frame.

+@rschoen to answer questions if there are any.

It was announced that in Chrome 64 (To be the stable version in around late Jan, 2018), all redirects originating from third-party iframes will show an infobar instead of redirecting, unless the user had been interacting with that frame.

+@rschoen to answer questions if there are any.

@MrStonedOne

This comment has been minimized.

Show comment
Hide comment
@MrStonedOne

MrStonedOne Nov 14, 2017

Is there a way to determine, at the script level, if a topframe redirect would lead to an infobar.

Also how does the blocking chain on that work? would the location set block while the infobar is up, what happens if it is denied, does the frame error out (like it did before) or does the code continue on as normal?

I have to use this in an oauth flow that involves in game prompts because of the way the game engine presents these things to users and the fact the devs refuse to create a native oauth way to authenticate users. I can present them with a button, but the system works best if it can auth them in the background during the loading and redirect them once both complete.

Is there a way to determine, at the script level, if a topframe redirect would lead to an infobar.

Also how does the blocking chain on that work? would the location set block while the infobar is up, what happens if it is denied, does the frame error out (like it did before) or does the code continue on as normal?

I have to use this in an oauth flow that involves in game prompts because of the way the game engine presents these things to users and the fact the devs refuse to create a native oauth way to authenticate users. I can present them with a button, but the system works best if it can auth them in the background during the loading and redirect them once both complete.

@chrisbro-MSFT

This comment has been minimized.

Show comment
Hide comment
@chrisbro-MSFT

chrisbro-MSFT Jan 23, 2018

@lubin2010 @rschoen, the announcement does not describe how the allow-top-navigation and allow-top-navigation-by-user-activation flags are impacted with this current change, and the announcement does not explain how a site can opt-in to actionless navigation in a particular iframe. Could you please clarify?

@lubin2010 @rschoen, the announcement does not describe how the allow-top-navigation and allow-top-navigation-by-user-activation flags are impacted with this current change, and the announcement does not explain how a site can opt-in to actionless navigation in a particular iframe. Could you please clarify?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment