Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

option to clone tab on network errors #1308

Closed
vbr opened this issue Mar 12, 2017 · 4 comments
Closed

option to clone tab on network errors #1308

vbr opened this issue Mar 12, 2017 · 4 comments

Comments

@vbr
Copy link

vbr commented Mar 12, 2017

Hi,
I'd like to ask about a possible option to automatically clone tabs, where a network error was triggered
It seems to be a consequence of QNetworkAccessManager problems mentioned in an earlier issue:
#1054
I experience such problems (Network error 99) rather frequently, mostly for login-accessed pages, webmail etc., after recovering the computer from hibernation or after a new start of Otter (with previously opened pages). (Using otter win64 weekly166 on win7)
In such cases, reloading the page doesn't work, but cloning the tab does, in most cases it even keeps the credentials, tab history etc.
Would it be possible (probably as an option), to try to clone such tabs automatically and close the invalid ones? Are there any drawbacks of such approach? I belive this might solve the most frequent problems "on the surface", until QNetworkAccessManager can be fixed. Of course, a possibility of "real" network errors should be handled, if such automatic cloning doesn't solve the problem in a few trials.
Alternativelly, if there were problems with automatic cloning, could the newly designed error pages be enhanced to contain designated links/buttons for cloning the tab (and preferably replace the current one)?
Thanks for considering this option,
regards,
vbr

@Emdek
Copy link
Member

Emdek commented Apr 17, 2017

@vbr, are you using WiFi or some other sort of unstable connection?
AFAIK such conditions are required to trigger such error.
I could experiment with simply always recreating QNetworkAccessManager instance when we hit this error and then reload, but that might cause other issues (like loop caused by multiple reloads, each ending with error 99 again).
Perhaps there is some other way to workaround that, it will need some debugging.
I can prepare test build if you could join us on IRC for short debugging session.

@vbr
Copy link
Author

vbr commented Apr 18, 2017

Thanks for investigating this; yes, the mentioned problems only appear with notebooks on wifi network (most regularlry after waking-up from the suspended mode, but also in other circumstances). On a computer using wired network connection I don't experience such problems.
I'll set up a connectionat freenode IRC as soon as I have access to the hardware in question. Is the web-based connection via irc.lc as linked from the Otter homepage appropriate?
Thanks,
vbr

@Emdek
Copy link
Member

Emdek commented Apr 19, 2017

@vbr, yeah, it's otter-browser channel on Freenode network.
Just ping me, usually I'm available from 6:00 to 20:00 UTC.

@Emdek
Copy link
Member

Emdek commented Jan 19, 2018

@vbr, it seems that it got finally fixed upstream, now we need to wait for a release containing this fix (according to wiki it should be sometime this month, maybe in February):
https://codereview.qt-project.org/#/c/212187/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants