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

Handling of window.open/target=_blank with tabs.background = False #3231

Open
The-Compiler opened this issue Nov 1, 2017 · 2 comments
Open
Labels
component: QtWebEngine Issues related to the QtWebEngine backend, based on Chromium. priority: 1 - middle Issues which should be done at some point, but aren't that important.

Comments

@The-Compiler
Copy link
Member

Right now we open window.open links in a background tab when tabs.background is set to False, so that Ctrl-Shift-Click on an element does the right thing.

We should probably have a setting (maybe even true by default) which breaks ctrl-shift-click instead, but does the right thing with window.open.'

@The-Compiler The-Compiler added the priority: 1 - middle Issues which should be done at some point, but aren't that important. label Nov 1, 2017
@The-Compiler The-Compiler changed the title Handling of window.open with tabs.background = False Handling of window.open/target=_blank with tabs.background = False Nov 22, 2017
@The-Compiler The-Compiler added the component: QtWebEngine Issues related to the QtWebEngine backend, based on Chromium. label Nov 22, 2017
@jgkamat jgkamat assigned jgkamat and unassigned jgkamat Aug 25, 2018
@jgkamat
Copy link
Member

jgkamat commented Aug 25, 2018

A quick half-baked discussion about this:

<jgkamat> The-Compiler:
    https://github.com/qutebrowser/qutebrowser/issues/3231 is really
    bugging me, would you prefer a new setting (something like
    tabs.background.force) or new values in the existing setting
    {default, invert, force-on, force-off} 
<The-Compiler> jgkamat: can't have tabs.background.force shadowing
    tabs.background though :)
<jgkamat> er, yah :P
<jgkamat> tabs.background_force or something
* jgkamat is horrible at naming things in general
<The-Compiler> wonder if we should just change it without a setting
    and see if anyone complains
<jgkamat> I would be fine with it, personally force-on/force-off make
    the most sense to me, the default browser behavior just confuses
    me xD
<jgkamat> but I could imagine some people want exactly what
    firefox/chrome does (which correlates to tabs.background true)
<The-Compiler> but firefox/chrome probably also handle window.open the
    same as ctrl-clicking links, no?
<jgkamat> The-Compiler: firefox at least opens ctrl-click in the
    background and window.open (I think) in the foreground
<The-Compiler> hm, true
<The-Compiler> same in Chromium too
<jgkamat> oh you know what, we can't actually change this because
    https://github.com/qutebrowser/qutebrowser/blob/master/qutebrowser/browser/webelem.py#L347-L350
<jgkamat> we would break tab_bg when force_on is true...
<The-Compiler> I think tab_bg would work (because all tabs open in the
    background then), but opening it as a foreground tab won't
<jgkamat> yah, it wouldn't work (tab_bg or tab_fg) for both "force"
    settings, either on/off
<jgkamat> I'll think about this tomorrow after I sleep :/
<The-Compiler> I'll think about this after my exams are done :P
<jgkamat> I suspect this could break rapid mode as well aah. I'm just
    going to set hints.background=true and change all my bindings to
    tab_fg -_-

@The-Compiler
Copy link
Member Author

Note this also affects "Open in new tab" in the context menu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: QtWebEngine Issues related to the QtWebEngine backend, based on Chromium. priority: 1 - middle Issues which should be done at some point, but aren't that important.
Projects
None yet
Development

No branches or pull requests

2 participants