More Gracefully Handle `chrome://` Tabs
Closed this issue · 2 comments
Right now, if you try to "panel" a system tab (such as chrome://whatever) and it will instantly bork and foobar the entire browser and shuts it down, anything you are doing or had open is GONE.
Sometimes, session restore manages to bring them back but a lot of time, nope. This is not hanging or crashing slowly, this is a FULL ON, HARD KILL, of the browser like it was done by a TaskManager.
- Why doesn't it handle internal pages (aka chrome://)
- If it can't do it, then it should catch and prevent it more gracefully, killing the whole browser is way too ridiculous.
- You stated in the roadmap that you are replacing panels with 2.0 alternative, but the installer as of today still requires you to set the panel flag, so what exactly is being alternated? This is not mimicking panels, it IS panels, can you clarify?
I was hopeful to use this today but given that the primary reason I needed it for is resulting in the browser being killed and losing everything, not keeping this until someone explains to me why its behaving so badly.
Hey, sorry for the delay, I’ve been incredibly busy lately. Bad news but I hope you understand: due to the recent changes in Chrome I’ve decided to stop maintaining Panel Tabs. I’ve written a more thorough blog post with details, please check it out here. Thanks for the support along the way!
Ok, thanks.