Hi, sometimes when I’m clipping a webpage, clicking the DT clipper just redirects the page to about:blank#blocked. I know there is existing posts about this, like this one, but it seems that the issue happens somewhat randomly. For example, when I try to clip this innocuous wikipedia article 孙中山, it’s redirected to about:blank#blocked, while another one 国民政府 works smoothly.
I’m left no clue what’s the possible cause of it. I’ve tried uninstall then re-install the web clipper extension with no avail. How to fix it, or at least how to debug the cause of the problem?
Which format do you use for clipping, is the clutter-free option en- or disabled?
I didn’t got chance to choose, just on tapping the extension icon, it was redirected. I made a gif to show it.
Do you use any Chrome extensions, did you deny any prompts in the past to open x-devonthink://...URLs? Does it work using another browser?
I’ve tried to disable all but DT clipper extension, with no avail.
No, I didn’t. Actually, I have a very rough guess that it happens only after I checked “Always allow …” on this popup. But can’t be sure about it.
FWIW, other wikipedia pages still pops up this “Open DEVONthink 3”, and they can be clipped.
It works in Safari, but not in Chrome or Brave. Actually, I just downloaded a Chrome to test it (I normally use Brave instead of Chrome), with only DT clipper extension installed, no success.
Does the Clip to DEVONthink bookmarklet (see DEVONtechnologies | Handbooks and Extras) work in Chrome?
Nope, same about:blank#blocked
Does this happen on a second & clean user account (see System Preferences > Users & Groups) too?
Yep. Just managed to setup a new user and all that. Same about:blank#blocked. Also tried bookmark, no success.
Which version of macOS do you use?
Hi, I’ve made some progress, for your reference.
The Clip to DEVONthink bookmark, which is essentially a window.location redirection of
window.location='x-devonthink://clip?title='+encodeURIComponent(document.title)+'&location='+encodeURIComponent(window.location)+'&referrer='+encodeURIComponent(document.referrer)+'&width='+window.innerWidth+'&source='+encodeURIComponent(document.documentElement.outerHTML)+'&text='+encodeURIComponent(getSelection())
Executing this line of javascript in console results in the same about:blank#blocked. BUT, if I log the url in console,
console.log('x-devonthink://clip?title='+encodeURIComponent(document.title)+'&location='+encodeURIComponent(window.location)+'&referrer='+encodeURIComponent(document.referrer)+'&width='+window.innerWidth+'&source='+encodeURIComponent(document.documentElement.outerHTML)+'&text='+encodeURIComponent(getSelection()));
then manually copy and paste the x-devonthink:// in address bar, it would work as expected.
But I’m by no means front-end expert, knowing nothing about the working of chrome. So probably can not dig any deeper.
One workaround might be to specify a hotkey in Preferences > Sorter for Clip to DEVONthink, does this at least work as expected?
Great, the hotkey works as expected. I’ll resort to this workaround for now. But still, hope we can finally resolve it someday.
Hi again, I believe I have finally figure it out. The root cause is the value of source url paramter might be too too long. Its value encodeURIComponent(document.documentElement.outerHTML) appends the entire html of the current webpage to x-devonthink:// url. Now the problem is, Chrome has a global url length limit at 2MB, quoting:
In general, the web platform does not have limits on the length of URLs (although 2^31 is a common limit). Chrome limits URLs to a maximum length of 2MB for practical reasons and to avoid causing denial-of-service problems in inter-process communication.
When clipping huge page, the size of entire html could easily exceed this 2MB limit, as my example wikipedia page 孙中山 has demonstrated.
I believe both the DT clipper and the bookmarklet are plagued with this problem.
To make sure the issue is indeed caused by 2MB limit, I’ve made the following tests:
// Chrome url limit
var urlLimit = 2 * 1024**2;
// Get url length without html of page
var lengthWithoutSource = (
'x-devonthink://clip?title='
+encodeURIComponent(document.title)
+'&location='+encodeURIComponent(window.location)
+'&referrer='+encodeURIComponent(document.referrer)
+'&width='+window.innerWidth
+'&source=' // without source value
+'&text='+encodeURIComponent(getSelection())
).length;
// Test 1: Invoke clipper url command, truncate source exactly to 2MB -> Success!
window.location='x-devonthink://clip?title='
+encodeURIComponent(document.title)
+'&location='+encodeURIComponent(window.location)
+'&referrer='+encodeURIComponent(document.referrer)
+'&width='+window.innerWidth
+'&source='+encodeURIComponent(document.documentElement.outerHTML).substring(0, urlLimit - lengthWithoutSource)
+'&text='+encodeURIComponent(getSelection());
// Test 2: Invoke clipper url command, truncate source to 2MB + 1byte -> Failed!
window.location='x-devonthink://clip?title='
+encodeURIComponent(document.title)
+'&location='+encodeURIComponent(window.location)
+'&referrer='+encodeURIComponent(document.referrer)
+'&width='+window.innerWidth
+'&source='+encodeURIComponent(document.documentElement.outerHTML).substring(0, urlLimit - lengthWithoutSource + 1)
+'&text='+encodeURIComponent(getSelection());
Test 1 generated a url with 2MB length, and it clipped problematic page successfully. Test 2 generated a url with 2MB + 1 length, and it failed to clip the same page and redirected to about:blank#blocked, as expected.
My suggested solution would be simply removing the source parameter. I’m not sure why it’s necessary. Setting its value to an empty string doesn’t seem to affect clipping result in any way, no matter which format is chosen (webarchive, formatted note or html).
1 Like
The source is used to ensure that the clipped page will look like the current web page if possible (especially useful in case of pages requiring logins or dynamic pages). Instead of using the extension or bookmarklet the hotkey should work. Or just activating the Sorter and choosing Chrome in the Clip to DEVONthink tab.
The latest release of the Chrome extension fixes this.
