New update breaks interface on Roundcube mail

[mnowotnik]

No description provided.

[smblott-github]

In what way is the interface broken, @Mike-now?

[mnowotnik]

I attach screenshots with and without vimium enabled.

[smblott-github]

In the top screenshot, is the blurred-out Vimium icon blue?

You're saying Vimium being enabled or not causes the shape and position of that box to change, yes?

And when Vimium is disabled, the box in the wrong place, yes?

[mnowotnik]

I shouldn't have blurred it , tho. It's a language immersion plugin the same as in the lower screenshot. The vimium icon is not present in the upper screenshot. I purposefully disabled vimium in the lower screenshot (hence gray) , but it didn't have any effect.

Yes, the text area is missplaced whem vimium is enabled as a chrome extension. It doesn't matter if it is internally "disabled" (grey icon) for this site. I could try to debug it with breakpoints if you have any tips. I couldn't catch anything obvious.

[joshuamhanley]

The new update (1.50) has also broken the loading of a multiline rich text field in ScienceLogic's EM7 ticketing/monitoring system that I use at work. Clicking New Note in a ticket doesn't seem to fully load the multiline text field--it can't be typed into--so I can't update my tickets. Adding the site as an exception in Vimium settings doesn't solve the issue. I can only update my tickets with Vimium completely disabled.

With Vimium enabled:

With Vimium disabled:

Please fix, Vimium saves me so much RSI pain! If this should be in a new issue or you want more details, please let just me know and I'll provide whatever I can. I'm no developer and the javascript is beyond my understanding, but I can probably provide page sources for the pictured windows if that would help. I know loading the Note field is done with AJAX, though.

In the meantime I'll have to figure out how to build and install Vimium v1.49.

Edit: Nevermind on the page sources, they are the same with or without Vimium enabled except for a random key. So I guess View Page Source in Chrome doesn't show any js added by extensions.

[smblott-github]

Thanks, @joshuamhanley.

Your problem is not that Vimium's not working right, or that Vimium's interfering with your workflow, right? You problem is that it's preventing (somehow) the page/widget/input from loading properly.

Is that it? Are there any interesting-looking messages on the console?

What would be most helpful (but might not be possible) would be a link to a public site where we can see the problem for ourselves.

(I'm trying to sign up for a ScienceLogic demo account.)

[joshuamhanley]

Yes, exactly. Well, it does kind of break my workflow in that I have to either disable Vimium (which I love and use a lot) to add notes to a ticket...or open the ticketing portal in IE. Something added to Vimium in 1.50 prevents the control/text box/whatever it's called from loading completely. Unfortunately, I don't know of a public site, as this is my employer's private ticketing system. Also, my understanding is that we are not on the very latest EM7 version, although that may not matter, given how old the code behind the text editor already is (see below).

There is an error in the javascript console:

Uncaught SecurityError: Blocked a frame with origin "::our EM7 portal's URL (redacted)::" from accessing a frame with origin "chrome-extension://dbepggeogbaibhgnhhndojpepiihcmeb". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "chrome-extension". Protocols must match.

The error refers to line 36 of fckeditorcode_gecko.js.

Fckeditor appears to be an old (circa 2008) open source js text editor that has since (2009?) become ckeditor.

Does that help?

I know very little about js, but it seems from the error text like that error would have been triggered before, but I never had a problem until the Vimium v1.5 update.

[smblott-github]

Yes. That helps a lot.

@Mike-now... Are you seeing the same message in the console?

[smblott-github]

@joshuamhanley ... If you send me your email address (smblott@gmail.com) I'll set you up with a working version until we get this fixed.

[mrmr1993]

Both of these issues look like they're to do with Vomnibar in iframe, and — if I'm right — were probably fixed by recent changes in master.

@smblott-github is the working version you're sending master, or something more complicated?

[smblott-github]

@joshuamhanley... Would you be able to try out a couple of versions? I think we pretty much know the source of the problem (thanks to your earlier report), but need some help figuring out how best to fix it? I can also provide you with a 1.49 version to tide you over, thereafter.

@mrmr1993... Do you know how to rattle up a page with the tightest possible (or tightest reasonable) CSP which we could use as a test bed?

[mrmr1993]

Do you know how to rattle up a page with the tightest possible (or tightest reasonable) CSP which we could use as a test bed?

No, unfortunately not. Should be plausible to arbitrarily apply a harsh CSP to pages via chrome.webRequest, though, if you're willing to test with a modified Vimium version.

[joshuamhanley]

Sure, I'd love to help. Just tell me what you need me to do.

[smblott-github]

@joshuamhanley Send me an email ... smblott@gmail.com

[joshuamhanley]

@smblott-github Emailed you.

[mnowotnik]

@smblott-github Yep, exactly the same.

[smblott-github]

Thanks, @Mike-now.

Weird, @joshuamhanley. I didn't get your email. Please send again... smblott@gmail.com
Or post a link to somewhere where I can find your email address.

[smblott-github]

Update: @joshuamhanley tried a snapshot from master, and gets the same CSP error. I haven't been able to create a server/web page configuration to reproduce this, but it's apparently a Content Security Policy issue related to the Vomnibar being in an iframe.

I'll open a separate issue to discuss the various ways in which we can fix this.

[joshuamhanley]

With Collusion for Chrome extension disabled, 1.49 works most of the time, and the April-30 version you sent works some of the time, although less often on the first try (or so it appeared--I didn't test 1.49 nearly as extensively as the April-30, so I may not have gotten a big enough sample to really say anything substantive about success rates). With both versions, if they don't work initially, I can reload the page once or twice and give it a couple seconds to completely load, and then clicking the New Note button will (usually) load a usable, typable multiline text field. Waiting a few seconds after the page is fully loaded to hit New Note button seems to improve the success rate on both versions, although it doesn't improve it to 100%.

When they don't work (and by don't work I mean they show the exact issue I described), they show the same error:

fckeditorcode_gecko.js:36 Uncaught SecurityError: Blocked a frame with origin "::redacted URL::" from accessing a frame with origin "chrome-extension://noojglkidnpfjbincgijbaiedldjfbhh". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "chrome-extension". Protocols must match.

(As you'd expect, the extension ID is different between the different versions, but otherwise this error is identical.

When they do work, they show this error in the console:

fckeditorcode_gecko.js:67 Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.

As you would expect, I can hit F12 and look at the console to see which error shows without actually clicking the New Note button and thus know whether clicking it will work; the two errors are perfectly correlated with the issue. I can't determine what seems to cause it to glitch or not, as it seems to be random, other than to say it seems to happen less often if I wait a few seconds, even after the page is completely loaded, to check the console or click the New Note button.

[joshuamhanley]

I did a little more testing, and waiting for the page to fully load doesn't seem to impact the success rate, but whether it is the first time the ticket's page has opened (as opposed to having opened it to no success but then reloaded it) does impact the success rate. The initial page load seems to work much less often than subsequent reloads of the same page in both 1.49 and the April-30 version @smblott-github emailed me.

[joshuamhanley]

The vimium-without-omnibar.crx version @smblott-github sent worked much more consistently, although not perfectly. 10-20% of the time it still fails, at least on the initial ticket page load, with the same error:

fckeditorcode_gecko.js:36 Uncaught SecurityError: Blocked a frame with origin "::redacted URL::" from accessing a frame with origin "chrome-extension://noojglkidnpfjbincgijbaiedldjfbhh". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "chrome-extension". Protocols must match.

But it does work most of the time on the initial page load (and if it doesn't a single reload of the page gets it working again)--and does so much more often than any of the other versions I've tried--albeit with the same error as before when it works:
fckeditorcode_gecko.js:67 Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.

I'm trying to remember, but I can't recall if I an earlier version never caused issues. I've only been at this job for about 5 months now, with Vimium installed the whole time, and although I do remember it glitching like this occasionally, I can't recall if there was a time when it never did. It's possible that I've always had the error occasionally, and I just assumed it was an issue inherent to our ticketing system.

[smblott-github]

Do you use this too? https://chrome.google.com/webstore/detail/buffer/noojglkidnpfjbincgijbaiedldjfbhh?hl=en

[joshuamhanley]

Yes, I just realized that might not have been the right extension when I tried disabling/removing all Vimium versions, still had the issue, and realized that Buffer was the extension named in the error. I've disabled it--let me try the testing again...

[joshuamhanley]

Ok, I created a new user without any extensions (which I apparently should have done from the start--sorry for all the confusion!) and tested each version ten times with the following results:

no extensions: works consistently, still gives the "fckeditorcode_gecko.js:67 Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user" error in the console, so that must be inherent to EM7 and not related to any extensions. Therefore, though it appears consistently with every success, I won't mention it again.

Vimium current release version 1.50: consistently broken, with the error "fckeditorcode_gecko.js:36 Uncaught SecurityError: Blocked a frame with origin "::redacted URL::" from accessing a frame with origin "chrome-extension://dbepggeogbaibhgnhhndojpepiihcmeb". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "chrome-extension". Protocols must match."

vimium-2015-04-30.crx: Worked consistently.

vimium-1.49.crx: Worked consistently.

vimium-without-vomnibar.crx: Worked consistently.

[smblott-github]

Excellent!
Thanks for your patient efforts, @joshuamhanley.

@mrmr1993... That suggests master is good, and #1614 knocked this issue on the head.