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

Feature request: prevent open-in-new-window #544

Closed
ghost opened this issue Mar 11, 2019 · 8 comments
Closed

Feature request: prevent open-in-new-window #544

ghost opened this issue Mar 11, 2019 · 8 comments
Assignees

Comments

@ghost
Copy link

ghost commented Mar 11, 2019

(sorry; pressed <Enter> in the title -- in vimb -- and it submitted the ticket prematurely)

I'd like an option that could be enabled to force links to open in the same window. On Mozilla, this is the "expert" option browser.link.open_newwindow.restriction. This option would force links (including those triggered by Javascript) to be opened in the same window, rather than opening a new one. Some sites are really bad about opening every link in a new tab (Qwant is one, and a lot of Google areas like account administration overuse this too), and it'd be helpful to be able to disable it. Also, for those of us who are running in privacy mode, where every window is fresh, it'd prevent us from having to log in for every new window that's popped up when we're browsing around in-account.

I don't know if Webkit supports this, but if it does, it'd be great if it could be exposed through the vimb configuration options.

@iamleot
Copy link
Contributor

iamleot commented Mar 11, 2019 via email

@fanglingsu
Copy link
Owner

Hi @iamleot as I understand @serussell want to prevent vimb brom opening a new related instance in case a link is clicked which contains something that enforces to open a new window/tab (window.open or target="_blank"). If the user explicitely requests a new window (by ;t hinting, middle mouse click) we should follow this decission and open the target into new window.

I thought that this would be easy, but as I can see we do not have the information about a possible new window request in on_webview_decide_policy. The on_webview_create which is only called in case a new instance is requested is to late, because we have to return a new webview. And I have not found some related webkit setting to toggle this behaviour.
@serussell I like you idea of having such an option but I don't know how to achieve this.

@athrungithub
Copy link

athrungithub commented Mar 12, 2019

surf browser manage ok mouse click in webview_decide_policy, never open new window/tab

@fanglingsu
Copy link
Owner

@athrungithub Links with target="_blank" are also opened into new window with surf.
@serussell Have you any suggestion how to name the new option?

@ghost
Copy link
Author

ghost commented Mar 18, 2019

@fanglingsu, following the Firefox setting (if we're making up names, having them be similar to other popular implementations seems logical) how about open-newwindow-restrictions? I don't think it's particularly intuitive; prevent-newwindow might be better. But if people are searching how to enable this, they'll probably come across the Firefox method and check if that setting exists in vimb.

I don't know how hard it would be to still allow user initiated new windows to pass through; it'd be great if ;t still opened a new window even if this setting were enabled. I only want the decision to open a new window to be my decision, not the web site designer's.

Thanks for looking into this.

fanglingsu added a commit that referenced this issue Mar 23, 2019
Added setting 'prevent-newwindow' to enforce opening links into same
window even if they are crafted by `target="_blank"` or using
`window.open()`.
This option does not change the behaviour for links fired by hinting.
@fanglingsu
Copy link
Owner

@serussell The prevent-newwindow is now available and seem to work for the case i saw.

@ghost
Copy link
Author

ghost commented Mar 25, 2019

@fanglingsu Get out! Really? Holy crap, that's amazing! I'll give it a shot tomorrow.

Thanks!

@ghost
Copy link
Author

ghost commented Apr 28, 2019

Sorry for the delay, but confirmed working as expected. Awesome work; thanks!

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

3 participants