In https://bugs.webkit.org/show_bug.cgi?id=52877, dimich writes "When we transfer iframe, the main idea of the feature is that it continues all operations. If it is being loaded - it continues to load, if it has timers or XHRs in flight - they continue to work. Basically, since the iframe has its own origin, the security checks and permissions of various kind can continue to be checked against that origin. It would be unfortunate if the geolocation will stop working when iframe is transferred. It would be nice to figure out how to make it work, unless it contradicts the was Geolocation permissions are granted." In bug 52877, we stop the activities of the Geolocation when the iframe is transferred between pages because the old page client is becoming inaccessible, and we won't otherwise be able to stop activities when the old page client is destroyed. Also, it may be that the permission policy is different under the new client.
Some ideas, please comment: - in Frame::transferChildToNewDocument, in the body of the "if (didTransfer) {", extend the "if (oldPage != newPage)" body to include a call to a new method DOMWindow::geolocationPageChanged(oldPage) that will indirectly call a new method Geolocation::pageChanged(Page* oldPage). - Geolocation::pageChanged(oldPage) will: - If the Geolocation is updating, subscribe to the new page's GeolocationController, unsubscribe from the old page's GeolocationController - If the Geolocation is awaiting permission, cancel permission on the old page's GeolocationController and request permission from the new page's GeolocationController I think that there may be some subtleties involved with the above. We will want to avoid annoying the user with a permission request dialog disappearing and then reappearing.
Could you help me to fill some void in my understanding of how Geolocation should work? I probably miss some previous discussion on this. I initially wondered why do we even care about Page - it seems between Frame and its client (WebFrameClient in chromium) we should be able to pipe all the connections so that Frame would have its own GeolocationController. However, I see that we apparently grant geolocation permission for pairs <requesting_frame_url, embedder_page_url>, at least in Chromium implementation. Does it imply that reparenting into a different page should at least re-negotiate the permissions?
In Chromium, the URLs referred to above are a representation of security origins. It is my understanding that an iframe can only be reparented to another page of matching security origin. Is this correct? (In reply to comment #2) > Could you help me to fill some void in my understanding of how Geolocation should work? I probably miss some previous discussion on this. > > I initially wondered why do we even care about Page - it seems between Frame and its client (WebFrameClient in chromium) we should be able to pipe all the connections so that Frame would have its own GeolocationController. > > However, I see that we apparently grant geolocation permission for pairs <requesting_frame_url, embedder_page_url>, at least in Chromium implementation. Does it imply that reparenting into a different page should at least re-negotiate the permissions?
(In reply to comment #3) > In Chromium, the URLs referred to above are a representation of security origins. It is my understanding that an iframe can only be reparented to another page of matching security origin. Is this correct? I was not sure if those are full urls or stripped to origins. Yes, the script has to be able to access DOM of both pages to transfer iframe from one to another, so in most cases it's from the same origin. The iframe itself can be of a different origin. So your original plan sounds good. Moving permission request dialog from one window to another, following the transfer, might not be as bad. Most likely iframe transfer is used to implement some action requested by the user (by closing the window that contains it for example), so it wouldn't look like a random jump... My question was about why the GeolocationController is per Page rather then per Frame, and if we really asking users "Can foo.com hosted in bar.com use location information?" For example, if a GoogGuys.com page hosts iframe with advertisement from BadGuys.com, and that ad will ask for Geolocation, will user be presented with a dialog that has both GoodGuys.com and BadGuys.com origins?
(In reply to comment #4) > My question was about why the GeolocationController is per Page rather then per Frame, and if we really asking users "Can foo.com hosted in bar.com use location information?" For example, if a GoogGuys.com page hosts iframe with advertisement from BadGuys.com, and that ad will ask for Geolocation, will user be presented with a dialog that has both GoodGuys.com and BadGuys.com origins? What happens on Chromium is that the user is presented with an info bar that asks the user to authorise BadGuys.com for Geolocation. The info bar doesn't mention the outer site, but the decision of the user is recorded with respect to the outer site (so, in the preferences page you will see that BadGuys.com inside of GoodGuys.com has been allowed/refused permission).
Closing, the feature was removed.