Paperpile loses connection to google document

Support
#1

I’m having difficulty with the sidebar. I like using it much, much more than I like using the control-alt-p option to enter citations. The only problem, which I have mentioned before to support, is that the sidebar frequently reports that it has lost its connection to the document I am editing, which creates an obnoxious red pop-up that is very distracting. I recognize that I am in the minority and that this is an issue few others have reported. All I want is a way to stop getting the pop-ups in the bottom right. Maybe make it silently retry to connect after five seconds before producing the pop-ups for disconnect and reconnect. Maybe I can just turn off the pop-ups entirely and take my chances. Whatever the solution is, it is essential that I have some way of removing the pop-ups.

It is no longer possible for me to leave the sidebar closed and use the control-alt-p Chrome extension to add references, because i have discovered that this causes significant lag when footnoting large documents.

I have tried:

Powerwashing the chromebook.
Uninstalling and reinstalling all extensions.
Double-checking my internet connection. This problem appears at regular intervals on all connections I have tried, even perfectly stable university wifi.
Using adblock to filter the div for popups (doesn’t work because of the nested iFrame)
my current solution is a sticky note in the bottom right-hand corner of my page, which is for obvious reasons not a good long-term fix.

EDIT: Incidentally, I only just now saw the replies to my previous topic. The issue appears on every document I edit.

#2

I’m aware that this is still an issue for some users, unfortunately we only see it happen in the logs from time to time but don’t get any feedback about it at all. So I’m happy about your post because it gives us something to work with. I’ll have another look at your account to see if I can find out more. I’ve added more logs after your first report.

But to make it clear: the popup cannot simple be removed. We already try 4 times to reconnect as you suggested and if we can’t connect to the document the add-on simply cannot function. Unfortunately, Google only gives us this strange way to poll where the cursor is by calling their servers and that fails shockingly often.

What happens if you click the popup away with “Retry” will it re-appear again soon?

I’m still optimistic that we can improve that. What I’m more concerned of is the lag you describe with the extension. Can you send us more details via the in app messenger? We have not heard about that and people have created documents with hundreds of citations. I can’t think of a reason why it should be different for footnotes but that’s something I’d like to find out.

#3

I’ll take a look at the footnotes thing again tomorrow. It’s been an issue for a while now but I only noticed it recently when a heavily-footnoted file became unusable. Disabling the chrome extension in google docs solved the problem immediately.

When I click “retry,” it functions normally (reconnects successfully) and I get anywhere from thirty seconds to five minutes before another popup occurs. Please note that if I don’t hit retry, it also functions normally, reconnecting at the end of the minute, and I don’t have any problems.

#4

Thanks. One more thing. You mentioned a sticky note, you mean you used a physical sticky note to hide the popup?

Does the add-on do anything useful when the popup is showing? It can’t know where the cursor is so won’t get feedback for example when you move the cursor over an existing citation. Does this still work?

It might be that there is a bug in our error handling but I’ve double checked already after your first report.

#5

It lets me cite things. But you’re right, it doesn’t let me edit previous citations while like that.

#6

I’ve checked the logs and unfortunately I can’t find anything unusual. The root cause is that Google responds to our request to check the cursor position with:

We’re sorry, a server error occurred. Please wait a bit and try again

That’s what we do and we retry 4 times immediately and if it still fails we show the popup which retries in a minute or so.

It could be that it’s not a intermittent outage of the Google server as their error message suggests. We’ve had a situation a few months ago where a Google Docs update caused the same error in our script. It turned out it was a bug in Google Docs introduced by an update related to page numbers in the headers.

So it could be that your cursor is in a specific position of your document which causes problems for the system to detect the position. Could you try the following:

  • Whenever you see the popup remember exactly the position of the cursor
  • Move the cursor elsewhere and click “retry” (don’t change anything in the document), wait if the popup goes away or not
  • Move the cursor back to the previous position and wait if you get the popup again.

In other words, if it’s not just a random server outage it should be possible to reproduce the behaviour.

#7

I think I have this about 80% figured out. Will update momentarily with my data.

#8

I attempted to reproduce in the manner you described; it did not work. So I created a new document, opened the paperpile sidebar, and banged on keys. I had errors occur at a fairly consistent rate – much more consistent than in ordinary writing, so I began to suspect, based on what you told me about the cause of the error, that the cause was rapidly-increasing character count.

In rapid typing, the error occurred approximately every 470 characters, standard deviation 113 (sample size 7; I got bored). The range was 315 to 659. In very slow typing, I got to 1321 characters before I got bored and stopped – no errors. I then moved my cursor to the middle of the (by this point fairly long) document, at least 1000 characters from the end, and typed very rapidly. I got to 1700 characters before I experienced an error. I repeated the test, moving my cursor almost 2000 characters from the end, and typed very rapidly. I reached 2000 characters, then moved my cursor to the end of the document and resumed typing. I got 177 characters, a full standard deviation below the lowest normal result. Finally, I moved my cursor to roughly the beginning of the document and began typing. I reached 3000 characters before the amount of data being entered posed actual problems for the google document, which temporarily restricted my edit access. This coincided exactly with another Paperpile error; I am not sure if they were linked.

Theory: Google Docs is bad at reporting the cursor position when that position is ahead of the last recorded document size, and is slow to update document size.

Interim solution: add ~1500 buffer characters to end of file before beginning work.

#9

Thanks so much. I can reproduce the problem now and experience exactly the same behaviour as you describe.

I will look into it in more detail. The popup indicates 4 consecutive failures. If I directly measure the first failure I probably can reproduce the error more directly. I hope that will (i) allow me to report a bug to the Google AppScript team and (ii) probably think of a workaround.

Thanks, again. Please look in your inbox, I’ve sent you a coupon for 1 year free Paperpile.

1 Like
#10

Follow up: I could create a minimal test case and filed a bug with Google. It’s actually very easy to reproduce the problem. I’m a bit out of ideas how to address this issue though as we can’t expect Google to fix it any time soon.

The problem is the bug brings down the complete script and does not give me a chance to catch the error. Also I can’t test if the cursor is at the end of the document which triggers this problem.

However, if we assume this bug is responsible for the majority of these “Server errors” we probably can be more conservative about showing the popup.

https://code.google.com/p/google-apps-script-issues/issues/detail?id=5567

#11

Strictly speaking, the bug doesn’t only occur when the cursor is at the end; it just seems to occur more frequently because there’s less of a buffer there. One thought – the unformatted citations are treated as links when you click on them and the paperpile add-in doesn’t handle the click. Is it possible to have the add-in handle the link as well as just moving the cursor to the citation? That would provide a way to allow people to edit citations even when the add-in can’t verify cursor position. Or, for that matter, is it possible to only check the cursor position when the cursor is deliberately moved? Because no matter how much you type, your cursor will never wind up in the middle of an existing citation without deliberately moving it. Just a couple thoughts; I don’t really have the first clue what the possibilities are.

What I’ve started doing is going ahead and inserting the bibliography at the end as soon as I start citing things, which gives me enough of a buffer that I don’t see the error much. Incidentally, I don’t believe I ever got that coupon in my inbox – am I checking in the wrong place?

Also, thanks so much for being so transparent about all of this. When you told me the basic cause of the error, it made it possible for me to revise my workflow to mostly avoid the problem, which I really appreciate.

#12

Another thought, since apparently getCursor works but getSurroundingText doesn’t, is using getElement (if you can make a Paperpile citation as an element). Or, for that matter, creating bookmarks for each citation, storing a list of bookmark positions, and then checking the cursor position against the list of bookmark positions you already have.

#13

First, I accidentally sent your coupon as in-app message. If you open Paperpile you should see my face in the bottom right …

I can reliably reproduce when the cursor is at the end. I failed to see the error in any other situation. So I focused my bug report on this observation. It’s optimistic anyway to assume they will do anything about it anytime soon.

As the bug does not really cause any harm other than showing an annoying popup, I decided to address it by changing the schedule for retries. I now don’t retry immediately after an error but wait 6 seconds and show the popup only after 5 failures. The idea is that if someone was writing a sentence before this could take 5 seconds and that’s enough for 4 failures showing the popup. It’s very unlikely that someone writes 30 seconds straight without a short break. Such a break is enough to get a correct cursor position which resets the error counter.

The changes are not live yet but will be with the next update.

#14

The same problem is happening with my document. Regardless of whether or not I’m typing, I can open Paperpile in any way.

#15

Please have a look here:

http://forum.paperpile.com/t/recent-bugs-in-google-docs-read-this-if-paperpile-crashes/1606/2

That Google Docs bug prevents Paperpile (and any other add-on) to process some documents.

#16