Serious performance degradation in Google Docs when disabled

[nkgm]

To reproduce, try opening a decent sized google doc with a few pictures in it and press the down arrow key. Now try with the extension globally disabled. As long as the extension is enabled, google docs will be sluggish, and adding an exception rule (disabling vimium) for the page doesn't make any difference.

[smblott-github]

Have you got an example document, @nkgm?

[nkgm]

Try this google doc for example. On my MBP with all extensions disabled it's not entirely smooth, but still usable. With vimium extension enabled (but still disabled for the page) it lags so bad it's unusable for me.

Update:
Added editing permissions

[smblott-github]

Thanks, @nkgm. I don't see any sluggishness. What's "not smooth" for you?

[nkgm]

To reproduce, try opening a decent sized google doc with a few pictures in it and press the down arrow key.

I should have said headings instead of images, as it appears the slowdown occurs when the caret hits lines with headings, or anything that causes the url fragment identifier to change.

So basically disable all extensions but vimium (even add a vimium exception for docs.google.com/* so it's active but disabled for the page), place the caret at the start of the document and keep the down arrow key pressed (40ms repeat rate here) and observe the sluggishness. Now try the same with the extension disabled in the chrome extensions page. Can do screencast if needed.

[smblott-github]

Thanks, @nkgm. I can reproduce that now. It's not immediately obvious what's going on. Even disabling (that is, not installing) Vimium's main event handlers doesn't make the effect go away.

Note, however, the Google Docs scrolling operation does seem to be pretty processor intensive. On my laptop, the fan spins up after just a few seconds. So, any extra work Vimium's doing would be disruptive.

[nkgm]

Thanks for investigating @smblott-github. Indeed the scrolling operation is very intensive and I'm not suggesting Vimium should do something that's clearly not possible. I was only hoping there was a way to cleanly override the extension in this case.

Could it just be the overhead of reinitializing the extension every time the url fragment changes? Is it possible to profile something like this?

[gdh1995]

I also reproduced the problem.

If I use Developer Tools to show the fps number:

• Normally, the page has a frame rate of 18 fps, which means only the cursor is blinking.
• If I've turned off Vimium, and begin to scroll up from the bottom, the frame rate will be between 20 ~ 45 fps (desktop computer, Intel i5-4590).
• When Vimium is enabled without any exclusion rule, the frame rate is about 10 fps firstly, and reduces rapidly to 0.9fps ~ 3fps.
• After disabling VImium on chrome://extensions (not refreshing the doc page), its frame rate is 3040 fps, and reduces to about 2530 fps.

It seems that hash change events will cause too many messages, which can not be handled in time, and many things including redrawing are delayed heavily.

Add

Now the process for one hash change event is:

• the backend receives a message "onReferenceFragmentUpdated" from Chrome,
• it sends messages via chrome.tabs.sendMessage, which opens new ports to all frames
• all frames (in the docs.google page, it's 5) get messages "checkEnabledAfterURLChange"
• the one focused currrently begins to check if enabled
• the frame posts "isEnabledForUrl" via Frame.port to the backend
• the backend calcs enabledState via Exclusions.isEnabledForUrl request.url
• chrome.browserAction.setIcon is called since frameIsFocused is true,
  • which means the imageData, two big binary object images, is sent to Chrome
• the backend returns enabledState, and the top frame receives it
• normalMode.setPassKeys is called
• bgLog sends a message "Clearing key state" via a new port to a backend page

How ugly it is!

• In fact, onURLChange has known the new url and the frameId (if Chrome.version >= 41).
• I think it's a bug to call KeyHandlerMode::setPassKeys to reset @keyState on hash changed.
• setPassKeys is also called on window focused, and send the same log message, which is a little annoying.

[gdh1995]

Maybe we can close this issue? bgLog has been reworked months ago.