I found the reason for WebExecutor’s misbehavior - it happens when the web app/website revokes the URI right after a [simulated] click on it. This technique is used in three apps we saw - Firefox Send, Privacy Badger and Tresorit, all of which are security-related apps. As a result, by the time the URI gets into WebExecutor it becomes _recently revoked_. It seems to me like it still might be possible to get the data somehow, and I tried a few approaches none of which worked. Continuing my search for solution.
Bug 1432949 Comment 26 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I found the reason for WebExecutor’s misbehavior - it happens when the web app/website revokes the URI right after a [simulated] click on it. This technique is used in three apps we saw - Firefox Send, Privacy Badger and Tresorit, all of which are security-related apps. I was able to reproduce this in a unit test, which fails in exactly same way as reference browser. As a result, by the time the URI gets into WebExecutor it becomes _recently revoked_. It seems to me like it still might be possible to get the data somehow, and I tried a few approaches none of which worked. Continuing my search for solution.
I found the reason for WebExecutor’s misbehavior - it happens when the web app/website revokes the URI right after a [simulated] click on it. This technique is used in three apps we saw - Firefox Send, Privacy Badger and Tresorit (this is one is not open source, but I strongly suspect has the same issue), all of which are security-related apps. I was able to reproduce this in a unit test, which fails in exactly same way as reference browser. As a result, by the time the URI gets into WebExecutor it becomes _recently revoked_. It seems to me like it still might be possible to get the data somehow, and I tried a few approaches none of which worked. Continuing my search for solution.