[XFA] Send URLs as strings, rather than objects (issue 1773) #13417
Conversation
Snuffleupagus
force-pushed
the
xfa-URL-clone
branch
from
0e1b329 to
76784fd
Compare
Note that `URL`s aren't supported by the structured clone algorithm, see https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm, and any attempt to send a `URL` using `postMessage` is rejected by the browser. Hence, for consistency when workers are disabled, the `LoopbackPort` should obviously also reject any `URL`s.
Snuffleupagus
force-pushed
the
xfa-URL-clone
branch
from
76784fd to
81ce28b
Compare
|
/botio unittest |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/d9a5b96498960ac/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://3.101.106.178:8877/0658c37ac2de79b/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/d9a5b96498960ac/output.txt Total script time: 3.76 mins
|
From: Bot.io (Windows)SuccessFull output at http://3.101.106.178:8877/0658c37ac2de79b/output.txt Total script time: 5.19 mins
|
Given that `URL`s aren't supported by the structured clone algorithm, see https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm, the document in issue 1773 will cause the browser to throw `DataCloneError: The object could not be cloned.`-errors and nothing will render. To fix this, we'll instead simply send the stringified version of the `URL` to prevent these errors from occuring.
Snuffleupagus
force-pushed
the
xfa-URL-clone
branch
from
81ce28b to
ba13bd8
Compare
| @@ -2257,7 +2257,7 @@ class Image extends StringObject { | |||
| }; | |||
|
|
|||
| if (this.href) { | |||
| html.attributes.src = new URL(this.href); | |||
| html.attributes.src = new URL(this.href).href; | |||
There was a problem hiding this comment.
I think that for now we shouldn't create an image in case of this.href !== null:
- the ref can be a path (a name) to an internal picture which is not in the xml stream and we'll handle this case
- it can be a real
http://link or whatever. In this case, what's the policy ? especially if the url has the file protocol. - it can be garbage as you saw it in the mentioned pdf.
And I've the same question foratag inxhtml.js.
There was a problem hiding this comment.
The main objective of the PR was simply to avoid this line completely breaking everything, because of structured cloning errors (since a URL can't be cloned), and further improvements can probably happen elsewhere?
- it can be a real
http://link or whatever. In this case, what's the policy ? especially if the url has the file protocol.
I'm not sure that we should even attempt to support that case at all, given the possibly security implications of loading arbitrary content; this feels a bit similar to e.g. #13266 (comment).
Given that
URLs aren't supported by the structured clone algorithm, see https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm, the document in issue #1773 will cause the browser to throwDataCloneError: The object could not be cloned.-errors and nothing will render.To fix this, we'll instead simply send the stringified version of the
URLto prevent these errors from occuring.