+++ This bug was initially created as a clone of Bug #636905 +++ Foreign-/cross-origin iFrames (et al.) should not be able to nag me unless I have interacted with them (i.e. click anywhere inside them). Specifically, they should not be able to trigger any dialogs, e.g. alert() et al., HTTP Auth. Doing this for same-origin iFrames will likely break a lot™.

This is not a Firefox front-end bug, so not eligible for being in our backlog.

(In reply to Florian Bender from comment #0) > +++ This bug was initially created as a clone of Bug #636905 +++ > > Foreign-/cross-origin iFrames (et al.) should not be able to nag me unless I > have interacted with them (i.e. click anywhere inside them). Specifically, > they should not be able to trigger any dialogs, e.g. alert() et al., HTTP > Auth. This would always block all toplevel HTTP auth dialogs, so that's kind of a non-starter...

(In reply to :Gijs Kruitbosch from comment #2) > (In reply to Florian Bender from comment #0) > > +++ This bug was initially created as a clone of Bug #636905 +++ > > > > Foreign-/cross-origin iFrames (et al.) should not be able to nag me unless I > > have interacted with them (i.e. click anywhere inside them). Specifically, > > they should not be able to trigger any dialogs, e.g. alert() et al., HTTP > > Auth. > > This would always block all toplevel HTTP auth dialogs, so that's kind of a > non-starter... s/toplevel//

We're talking about foreign, cross-origin iframes here. Why is that a non-starter?

How would this interact with <iframe sandbox="allow-popups">

(In reply to Jesse Ruderman from comment #4) > We're talking about foreign, cross-origin iframes here. Why is that a > non-starter? Why is having a cross-origin http auth'd page in an iframe "bad" in the sense that we should block the http auth dialog? If a site is intending to use the http auth dialog in a dos-style attack, they will just use same-origin iframes - much easier.

If a third-party iFrame popped up an HTTP Auth window I would suspect most of my users would assume its from my site and enter their login information in the popup not realizing its going to submit to a third-party. I would hope because of at least that (not counting the annoying bit) HTTP Auth windows are included in this.

(In reply to James Hartig from comment #7) > If a third-party iFrame popped up an HTTP Auth window I would suspect most > of my users would assume its from my site and enter their login information > in the popup not realizing its going to submit to a third-party. I would > hope because of at least that (not counting the annoying bit) HTTP Auth > windows are included in this. This is a spoofing worry, whereas the original issue here was DoS. In particular, the assertion was that you can't trust a page to do X, Y or Z if you've not interacted with it. The fundamental issue with this in the case of HTTP auth is that you'll *never* have interacted with it (as it'll come up before you even can). It seems like if there are other concerns with doing http auth from iframes inasmuch as that's currently allowed, they should probably be a separate bug.

Btw, there are other bugs about blocking HTTP auth dialogs from frames: bug 647010 and bug 978471

(In reply to Jesse Ruderman from comment #9) > Btw, there are other bugs about blocking HTTP auth dialogs from frames: bug > 647010 and bug 978471 Ah - I thought there would be, but then bugzilla search failed to find them for me... Thanks!

Once bug 636905 is fixed, we track interaction state (ie "has the user interacted with this document") on a document. That should make it possible for the prompt service to implement the behaviour suggested here.

We now have a flag for user interaction, so this should be possible. This prevents third parties from popping up annoying dialogs that interrupt a users experience. The specific HTTP Auth issue is separate and being discussed in bug 647010 or related bugs (tl;dr; we tried blocking http auth on subresources, it broke too much so we had to revert the page; perhaps we need to narrow it down to specific subresource content types). (In reply to Florian Bender from comment #0) > +++ This bug was initially created as a clone of Bug #636905 +++ > > Foreign-/cross-origin iFrames (et al.) should not be able to nag me unless I > have interacted with them (i.e. click anywhere inside them). Specifically, > they should not be able to trigger any dialogs, e.g. alert() et al., HTTP > Auth. > > Doing this for same-origin iFrames will likely break a lot™.