freeze-dry icon indicating copy to clipboard operation
freeze-dry copied to clipboard

Allow passing custom grabber for frame contents

Open Treora opened this issue 6 years ago • 1 comments

As explained in src/Readme:

Although we try to clone each Document living inside a frame (recursively), it may be impossible to access these inner documents because of the browser's single origin policy. If the document inside a frame cannot be accessed, its current state cannot be captured. ... When freeze-dry is run from a more privileged environment, such as a browser extension, it could work around the single origin policy. A future improvement would be to allow providing a custom function getDocInFrame(element) to enable such workarounds.

Treora avatar Jul 23 '18 11:07 Treora

Some notes to self (or others who wish to implement this):

The current source code suggests that the grabber function would, given an (i)frame element, give back a DOM; the default is to try read frameElement.contentDocument (lines). I assumed a grabber function would call some privileged code (a content script inside the frame) to access the iframe's DOM and return that, possibly after having serialised&messaged&parsed it again.

However, the serialising&messaging&parsing would break the living parts, preventing us from then accessing any frames within the frame, as well as canvas data (#18) and form state (#19).

Some possible solutions:

  • keep the grabber signature as is; instead of serialising&parsing, the custom grabber should return a Proxy that does RPCs to access the iframe content (comlink could be adapted for webextensions).
  • change the grabber signature to return the resource object. It should then run captureDom to recurse into its own frames, grab canvas data, etc. Downside is that a resource object contains getters like .blob and .string, which we could not pass in a message.
  • perhaps our recursive part should return the essential data to create the resource tree afterwards.

Treora avatar Aug 02 '18 16:08 Treora