This reverts commit 4e11613d2df064b138532c18f88bbf278c64f347.
We can actually make this synchronous just fine by collecting that
information when searching for the elements...
Otherwise they're invalid but still in the HintContext, so calling
.hide() on it later (e.g. because the user pressed another key) would
give us a RuntimeError from PyQt.
Previously, the drawn hint labels were affected by the zoom, i.e., they
were stretched out by QtWebKit and actually had to be drawn at the
unzoomed position.
The Python/C++ API gives us coordinated adjusted for zoom, so
we always *negatively* adjusted them to get the unzoomed coordinates.
JS gave us the original coordinates, so we stretched them out according
to the zoom if adjust_zoom was given (which means only when clicking a
link).
Now we always operate in term of display coordinates: The point where we
draw the hint label is equal to the point we're clicking.
Thus, the zoom level for javascript is always adjusted, and the Python
zoom level is never (negatively) adjusted.
The following methods were only used for hint labels and thus removed
now:
- document_element
- create_inside
- find_first
- set_inner_xml
- remove_from_document
- set_style_property
If the clipboard contains "-a" then "open {clipboard}" will fail because
-a gets parsed as an option. "open -- {clipboard}" doesn't do that. See
some comments in #1791.
Fixes#1060.
In the process of adding this, I also decided to rewrite
mainwindow.get_window() for clarity (and also because flake8 was warning
about complexity).
Also adds some tests to the new-instance-target mechanism, in particular
a specific test for the issue in question.
Implement `completion-item-focus next-category` and
`completion-item-focus prev-category` to jump through completions by
category rather than by item.
Resolves#1567.
This moves creating the HintManager to AbstractTab, and lets
TabData (which is now a QObject) handle the start_hinting/end_hinting
signal.
For the mouse_event signal of HintManager, we now have a slot in
AbstractTab too, though that might actually be moved to
WebKitTab/WebEngineTab later when needed.
This moves various stuff around and out of QtWebKit code:
- open_target and hint_target are now in TabData, not on the WebPage
- As much as possible got extracted from WebPage.acceptNavigationRequest
to AbstractTab._on_link_clicked, with a new link_clicked signal added
to WebPage. However, we need to decide whether to handle the request
in this tab or not inside acceptNavigationRequest, so we have some
code duplicated there and in WebEnginePage.acceptNavigationRequest.
- _mousepress_opentarget (i.e., setting the open_target) is now handled
in MouseEventFilter, not in WebView.
It seems with document.documentElement.client{Height,Width} we
sometimes (e.g. without <!DOCTYPE html)...) get the full element height
instead of the viewport height.
Fixes#1821.
For some reason, when e.g. visiting duckduckgo and then heise.de,
QtWebEngine suddenly gets a new QOpenGLWidget as focusProxy.
We install an extra eventFilter observing the ChildAdded event and
re-adding the MouseEventFilter when that happens.
I usually use my browser with a one-window-per-workspace flow. If I
click on a URL anywhere, I personally would prefer it to go to the
browser instance that's on the same workspace.
To this end, the easiest way to accomplish this is to simply track when
windows are made visible and register them as the last visible object.
(To get finer control for when you have multiple windows on the same
workspace, focus changes also update the last visible object - the
implication being here that focusing something also means you're looking
at it)
Not all users may like this behavior, so I consider it strictly optional.
Command completions for `:bind` and `:` will now show bindings for
aliases. The binding is only included if it is bound to that alias, not
if it is bound to the command the alias points to.
Returning a defaultdict made the caller's code look confusing, as it
wasn't clear why there wouldn't be a Keyerror in some cases. Instead,
let the caller explicitly use `get`.
Consolidate the logic used to generate the command completion category
into one place. This is shared by CommandCompletionModel,
HelpCompletionModel, and BindCompletionModel.
Hidden commands are not shown in command completion as they typically
would not be run directly. However, a user might still might like to see
help for them if, for example, they are writing a script or creating a
binding.
Addresses #1707.
Various code (like src2asciidoc.py) relies on all @cmdutils.register
decorators being called when qutebrowser.app is imported.
Moving the keyconf import to _init_key_config broke that assumption, as
keyconf isn't imported anywhere anymore - which caused :bind and :unbind
to vanish from the generated documentation.
In the long run we should perhaps use venusian:
http://docs.pylonsproject.org/projects/venusian/
But for now, this is the easiest solution.
Wire up the config change event to update command completion on
changing aliases, so the new aliases will be included.
Fixes#1814.
Currently we do not have tests at a high enough level to test whether
signals are wired up correctly to update completions.
This adds the ability to open new tabs in the last-focused window
instead, which fixes#1801.
Right now the only other option is probably not that useful for human
users but it's required to make tests behave deterministically and
consistently. (But with #881 on the roadmap, I would implement this as
another choice)
To this end, also make the test framework set this option to preserve
the invariant against which existing tests are written: that spawning a
new window would effectively also focus it.
This was currently almost completely broken, yet nobody complained. The
new behavior (in the previous commit) makes this always hide the mouse
cursor, even when an input field has focus.
Since the only two easy options to implement are "never hide" and
"always hide", combined with the fact that both are sort of useless to
an end-user, just remove the option until somebody wants it back.
Right now, get('last-focused-main-window') essentially returns the same
as qApp.activeWindow(), since it's None when no window is focused. This
seems somewhat contrary to its original intent, so I've changed it to
only ever update the object.
This actually fixes another bug as well: on_focus_changed's new is not
always a MainWindow - in fact it's a WebView on my end. To fix this,
directly use the QApplication.activeWindow() to find the current focus.
That second bit in particular actually some related bugs that probably
nobody ever noticed or bothered reporting:
* _maybe_hide_mouse_cursor currently pretty much never gets called
* :adblock-update doesn't actually show any downloads
* ... probably more
This allows a specific keybinding, for whatever reason, to override the
default mode. Examples of when this could be useful:
* :hint --rapid --mode=word (to type them more rapidly)
* :hint --mode=letter input (if the default mode is number)
Also reword the description of 'group' to make the distinction between
'group' and 'mode' clearer.
Since we now use QWebEngineScript, we can't easily know when the script
finished running and we can access window._qutebrowser.scroll.
We instead assume the initial position (if we don't get a
scrollPositionChanged) will always be (0, 0), and explicitly set it
to (None, None) (displaying ???) if we can't connect that signal.
We now load the JS code as a QWebEngineScript, which sets up
window._qutebrowser with various "modules". That means we don't have to
pass the whole module every time we want to execute something.
