search

madebymany / sir-trevor-js

Rich content editing entirely re-imagined for the web
http://madebymany.github.io/sir-trevor-js/
MIT License
4.51k stars 399 forks source link

Chromium 95 - Windows issues #589

Closed shaunbellis closed 3 years ago

shaunbellis commented 3 years ago

Since Chromium 95 update we haven't been able to use Sir Trevor on any Windows based machines. It locks the browser window entirely when interacting with the block add button. Anyone else having this issue?

raffij commented 3 years ago

@shaunbellis which version of sirtrevor are you using?

shaunbellis commented 3 years ago

@shaunbellis which version of sirtrevor are you using?

@raffij We were running 0.6 when we noticed it but upgraded to 0.8.2, both lock up chrome on windows and Mac.

We've tried it on 0.9-7b too; it's the same.

shaunbellis commented 3 years ago

Is it something you can help with @raffij ?

shaunbellis commented 3 years ago

It happens on the example too if that helps @raffij https://madebymany.github.io/sir-trevor-js/example.html

NickGowdy commented 3 years ago

@raffij We're also using sir-trevor and have noticed this defect very recently. On Chromium 95 when clicking on the textarea, it freezes up and I have to reload the page.

raffij commented 3 years ago

Yeah there's no console errors, some sort of loop.

Possibly it's the scribe library we use. Something which isn't maintained anymore.

I might have time this evening to take a look.

raffij commented 3 years ago

I've got a pr for the issue in the underlying library that is used.

It's a hack, but should allow usage again.

olvado commented 3 years ago

Thanks @raffij - I've merged the scribe PR and will look at putting together the relevant package releases tomorrow

bigclumsyoaf commented 3 years ago

Hi @raffij

I've tried manually updating our version with this change. It's better, but I still see the problem occasionally. Can you give it another check? Using arrow keys to move around between lines, and then it just hangs.

raffij commented 3 years ago

I agree it's still an issue after further testing. It's also broken the way that we detect empty cells in some instances.

This appears to be a change in the way that contenteditable works in Chrome, I should test in a canary 96. As you'll have seen we use https://github.com/guardian/scribe to work with the editor, so we'll need to investigate further, but it's also difficult to debug. Which will take time.

raffij commented 3 years ago

Taken a look at future releases and from what I can tell 97 fixes the bug that is causing the issues.

Can someone else try Chrome Canary to see if it still has issues the the existing master?

olvado commented 3 years ago

I’ve downloaded the latest Chrome Canary (Version 97.0.4690.0 (Official Build) canary (x86_64)) and indeed the cpu issues do not appear to manifest!

bigclumsyoaf commented 3 years ago

Canary and Dev channels seem ok after quick tests. Beta still a problem.

How long do fixes normally take to filter to stable?

raffij commented 3 years ago

They are saying Jan 4th. So need an interim solution probably.

shaunbellis commented 3 years ago

Thanks @raffij it would be awesome if you could.

raffij commented 3 years ago

@shaunbellis i don't have a solution available at the moment.

The hack I was able to deploy for the add button doesn't really work for cursor controls as you end up getting non functioning text inputs in places you don't expect.

It really feels like contenteditable has been broken for the way we use it until Chrome 97.

shaunbellis commented 3 years ago

@shaunbellis i don't have a solution available at the moment.

The hack I was able to deploy for the add button doesn't really work for cursor controls as you end up getting non functioning text inputs in places you don't expect.

It really feels like contenteditable has been broken for the way we use it until Chrome 97.

Thank you for having a look. I'll close this issue with that. We will have to swap out the editior for another at least until #97.