Moves the 5.8 check to `_WebEngineScripts.init()`.
Changes `_inject_userscripts` to allow for the two code paths. With
5.7.1 we need to specify the injection point and not clear all scripts
for each call, since we have to call it three times.
Change the 5.8+ hook to call a new method which passes all the scripts
into `_inject_userscripts` so that doesn't have to have a fallback
conditional inside it because thats an inversion of responsibility!
Pulling the remove scripts part into a seperate function and making it
the callers responsibilty to call that first would tidy it up a little
more but meh.
I was worried about just doing `_widget.page().urlChanged.connect()`
once at tab init, where before it was connected at page init, because I
was under the impression that the child page can be replaced at any
time, eg when navigating to a new origin. But under manual testing I
didn't see that at all. Maybe I was mistaken or maybe that only started
in a later Qt version.
Replace characters that Windows doesn't like from generated and
suggested filenames for downloads. Does not apply to filenames that a
user inters via the downloads location prompt.
Fixes#3922
QtWebEngine (via chromium) has the ability to run injected scripts in
isolated "worlds". What is isolated is just the javascript environment,
so variables and functions defined by the page and the script won't
clobber each other, or be able to interact (including variables saved to
the global `window` object). The DOM is still accessible from "isolated"
scripts.
This is NOT a security measure. You cannot put untrusted scripts in one
of these isolated worlds and expect it to not be able to do whatever
page js can do, it is just for namespacing convenience. See
https://stackoverflow.com/questions/9515704/insert-code-into-the-page-context-using-a-content-script
for some examples of how to inject scripts into the page scope using DOM
elements.
Now you can specify the world ID in a `@qute-js-world` directive like:
```
// ==UserScript==
// @name Do thing
// @match *://some.site/*
// @qute-js-world 1234
// ==/UserScript==
document.body.innerHTML = "<strong>overwritten</strong>"
```
The QtWebEngine docs say worldid is a `quint32` so you can put whatever
number (positive, whole, real) you want there. I have chosen to allow
the `qutebrowser.utils.usertypes` enum as aliases for IDs that are
predefined in
`qutebrowser.browser.webengine.webenginetab._JS_WORLD_MAP`. So you can
pass `main`, `application`, `user` or `jseval` in there too. `main` (0)
is the default one and is the only one in which JS disabled when
`content.javascript.enabled` is set to `false`. All others are still
enabled.
I'm not sure whether using any of those already-named worlds makes
sense, apart from `main`. We could stop people from using them I
suppose. Another option is to allow people to pass in `*` as a value to
have scripts put into their own little worlds, probably backed by a
counter in the GreaseMonkeyManager class.
Chrome docs: https://developer.chrome.com/extensions/content_scripts#execution-environment
Webengine docs: https://doc.qt.io/qt-5/qwebenginescript.html#details
When we click a QTBUG link (to open in a new tab) from Qt's codereview, we get
two RWHV objects which both are visible.
Experimenting with .setEnabled(False) it looks like it's (hopefully always...)
the last one which is the one to use.
Apparently the signal attributes already exist with PyQt 5.10 (*sigh*) but PyQt
doesn't know what to do with the arguments, causing this to happen:
TypeError: unable to convert a C++ 'QWebEngineRegisterProtocolHandlerRequest'
instance to a Python object
Doing so causes QtWebEngine to load its own view-source: page even if we supply
custom data.
Instead we pass the original page's URL (to not regress #2948).
This partially reverts #3521 and reintroduces TabData.viewing_source.
However, on QtWebEngine we can still ":view-source --pygments" and then
":view-source" (with or without "--pygments") again, because the bit gets
cleaned in _on_load_started.
See #3654.
Sometimes I want to see all the logs _except_ for the sql stuff and
"marked cookies as dirty". with this you should be able to pass
`--logfilter \!sql,save`.
This codepath may trigger a crash which was fixed by
0e75f3272d.
However, this commit does not make it more likely to happen, and this
patch was backported into arch (at least).
In the future, we may be able to use <enter> on qtwebkit with js,
without triggering this crash
It looks like chrome-error://chromewebdata/ triggers another invalid scheme
load which is why the endless loop happens. When we install a custom scheme
handler for chrome-error:// we can at least show an error page.
This issue was probably introduced in 545539f28d
- with JavaScript, we can't "click" on an external link.
There might be a better solution using
QWebEngineSettings::setUnknownUrlSchemePolicy(QWebEngineSettings::AllowAllUnknownUrlSchemes)
temporarily when using hints with PyQt 5.11.
Fixes#2833
This reverts commit 1956590df84a72c7f9a516e805d01529291fccf8.
Turns out the actual issue wasn't due to *invalid* links - it's with links
which have an unknown scheme.
There's still a change in behavior between Qt 5.10 and 5.11 though: Invalid
links are apparently not passed to acceptNavigationRequest (sometimes?) so we
don't show an error message. Instead, we just load about:blank. However,
Chromium does that too and we can't handle a real click easily, so let's just
ignore that one.
See #3661
This reverts commit 6cc920472ee4170b257a0b588687b175162e83df.
Since self._widget can go stale in the layout, we need to somehow solve this differently...
It reads nicer, and this is also speculative fix for #3896 as PyQt5 is
hopefully better at disconnecting partial-objects from dead objects than it is
with lambdas.
Turns out str.isdigit() also handles ² as a digit, but int('²') causes a
ValueError.
Here we use `string.digits` instead, which is '0123456789'.
Fixes#3743
Please let this be the last attempt... :D
Fixes#3939
Supersedes #3921
Reverts ae295a7f65
See #3661
This should not regress #3872. Might affect #3834 in some way.
Also change the block scoped `window` declaration to be const because it
seemed like a good idea. The real window seems to just silently ignore
attempts to overwrite it.
Since the JSCore used by WebKit 602.1 doesn't fully support Proxy and I
can't think of a way to provide isolation otherwise just revert to the
old behaviour in that case. I am checking for the specific WebKit
version because I'm pretty sure that version just happened to be
released when Proxy support was only partially done, any later release
will presumably have a newer JSCore where it works.
There I changed the indentation of a block in the jinja template which
will have inflated the diff.
I added mocking of `objects.backend` to the `webview` and
`webenginewebview` fixtures, I am pretty sure they are mutually
exclusive so don't expect any issues from that.
Because of the feature detection being at template compile time I had to
tweak the test setup to be done via a fixture instead of the setupClass
functionality that I was using before.
The implementation of Proxy in JSCore used by current QtWebkit (webkit
602.1) doesn't support the `set()` handler for whatever reason. So
instead of testing for a specific behaviour that we can't ensure on that
version let's just skip the tests and handle user complaints with
sympathy.
Apparently making a function like `function foo() {};` in block scope is
illegal. It should be named via assignment.
Switched to an IIFE anyway because it doesn't need a name.
Previously scripts were failing to find attributes that they assigned to
window and then tried to use from the global scope. Eg
window.newthing = function() {...};
newthing(...); // newthing is not defined error
This wasn't the case for things that already existed in the global scope
and were just being overwritten.
This change just overrides the `Proxy.has()` function which seems to fix
it. Probably the `while` implementation was failing to pick up new
attributes because of the lack.
I also tweaked some comments and variable names and const-ness to be a
little more production ready.
Since the global namespace of javascript in the browser is accessible
there where issues with scripts clobbering things that the page expected
to be attributes of window pages clobbering things that userscripts
saved to `window`. The latter was occuring with OneeChan. OneeChan was
setting `window.$` to a function that took a css selector and the 4chan
catalog script was setting `window.$` to some object. Since OneeChan was
set to run at document-start this broke OneeChan, switching it to
document-end broke scripts on 4chan.
I used OneeChan and 4chan-X on 4chan as the test case for this and
TamperMonkey as a guide for what is the correct way to handle scoping. I
didn't manage to pick apart just how TamperMonkey does what it does (I
think it might just be the environment that Chrome provides extensions
actually) but I got close to the same behaviour.
TamperMonkey provides a `window` object that appears to be what the
global window looked like before the webpage modified it. The global
scope though does have the pages modifications accessible. If the script
assigns something to an attribute `window` it can see that attribute in
the global scope. This implementation differs from that one in that, to
the scipt, `window` and the global scope always look the same, and that
is the same as the global scope looks in the environment provided by
TamperMonkey.
I am using the ES6 `Proxy` feature to allow the `window` object to look
like the actual (unsafe) one while allowing writing to it that doesn't
clobber the unsafe one. I am then using the ES4 `with` function to make
attributes of that window (proxy) object visible in the scope chain.
There may be other ways to do this without using `with` by using nested
functions and setting `this` creatively. There are notes around
alleging `with` to be various states of uncool[1].
I also ran into an issue where a userscript calling
`window.addEventListener(...)` would fail with `TypeError: Illegal
Execution` which is apparently due to `this` not being set correctly. I
looked at the functions which threw that error and those that didn't and
am using whether they have a `prototype` attribute or not to tell
whether I need to bind them with `window` as `this`. I am not sure how
correct that is but it worked for all the cases I ran into.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with
Previously, we would focus webviews even if they were in the
background to work around https://bugreports.qt.io/browse/QTBUG-68076.
This adjusts that to only occur when needed.
Closes#3875
The autoupdator, which uses `qutebrowser.misc.httpclient` has been failing recently because the URL that it hits to check version information is now serving a 301 moved permanently. By default QNetworkRequest doesn't follow redirects so it was getting back a (non-json, despite the request) body pointing to the new location, instead or version information. This changes fixes that by changing HTTPClient to use a QNetworkRequest subclass which follows redirects by default.
It lookes like HTTPClient is currently only used in autoupdate.py, version.py, and crashdialog.py so I don't expect any breakage.
5.6-5.8 Only had a boolean setting available which allows redirects, but not from the https scheme to http, 5.9 introduces a more nuanced setting. I have tested locally on 5.7.1 and 5.10.
The greasemonkey `@match` directive is used to match urls against
chromium url patterns (as opposed to `@include` which treats its
argument as a glob expression). I was using fnmatch for both here
because I am lazy and knew someone else was going to implement chromium
url patterns for me eventually. Now it is done and I should switch to
using them instead. The most common failing case that this will fix is
something matching on `*://*.domain.com/*` because it wouldn't match
the url with no subdomain.
This codepath is only used on webengine 5.7.1 and webkit backends.
Greasemonkey scripts are supposed to default to running on all pages.
@jgkamat and @nemanjan00 repurted some script not running on all pages
unless they either removed (or broke) the metadata block or added an
include directive. Indeed I had a logic error when it only defaulted to
being included on all pages when no metadata block at all was included.
Whoops.
nemanjan00 reported this script not having any effect da850e49cc/duckduckgo-deepdark.user.js
It turns out that the previous implementation of GM_addStyle was relying
on `document.onreadystatechange` when the script ran early enough that
there was no `head` element. That event wasn't getting fired for the
main frame of duckduckgo.com for whatever reason. Maybe using
`DOMContentLoaded` or something would have worked but I just copied the
fallback in the above linked script which seems to work just fine.
Allow completion functions to react dynamically to args as the user
inputs them. This allows config-cycle to filter out values that were
already provided.
Args provided after the maxsplit do not cause the completion to regen.
For example, successive words typed after `:open` just set the filter
pattern and do not spuriously regenerate the completion model.
When a command has positional varargs, keep offering the configured
completion for each successive argument.
Right now this only influences `config-cycle`.
Previously, `config-cycle <option> ` would offer a value completion for
only the first argument after the option. Now it will keep offering
value completion for each successive argument.
This will be useful for passing multiple tags to the new bookmark
commands that will be added for #882.
`prefix` is a string and `seq` is a key sequence, so removing `len(prefix)`
items from `seq` will remove too many if `prefix` contains a special character
(ex "<Ctrl+x>"). Remove the number of characters from `str(seq)` instead.
- Initialize JavaScript in webenginesettings.py instead of webenginetab.py
- Move JavaScript snippet into a .js file
- Make sure scripts can be re-run and do nothing if already run.
- Run scripts on DocumentCreation *and* DocumentReady. Closes#3717.
- Give each script an unique name for debugging.
- Also make custom stylesheets work on chrome:// pages
When we reload because of a config change in _on_load_finished, we can't use
self.reload() as no URL is set yet. Instead, we call self.openurl with the
current URL.
However, we need to make sure we don't emit predicted_navigation again at that
point.
This should (finally) fix#3718
When we reload a page because of a config change, we won't get another
titleChanged signal (at least sometimes).
Also, the predicted_navigation signal is worthless when reloading anyways, as
we're going to load the same URL and not something different.
Fixes#3718
In #3521, the injection point was changed to DocumentReady as a fix for
https://bugreports.qt.io/browse/QTBUG-66011 / #3490.
However, that prevents e.g. using hints before a page is fully loaded, which can
be annoying on a mobile connection.
Instead, just run the scripts twice, which won't hurt and makes sure they're
available.
- add INPUT_MODES & PROMPT_MODES constants in modeman
- use those in tabbedbrowser and modeman
- fix debug logs format to be more human readable
- fix associated tests for new debug logs
- Use qutebrowser-editor-backup as the backup file prefix
- Consistently use message.error instead of cmdexc
- Improve test coverage for the backup function
- Fix lint errors in the unit test code
Currently the editor deletes its temp file whenever editing is finished.
With this patch, the file will not be deleted if the editor callback
encounters an exception.
One example is if the tab containing the edited element is closed. The
editor errors with "Edited element vanished", but with this patch it
will also print "Backup at ..." so the user does not lose their work.
Resolves#1596.
Supersedes #3641, using the cleaner approach started in #1677.
1899e313fd as a fix for #3631 broke :unbind, as
the config system treats None and '' equally.
Instead, allow None/'' again, but just handle it as "no binding".
This mostly reverts 4ef5db1bc4 for #1966, but
fixes#3684 by allowing numbers to be bound again. If the user wants to bind
numbers instead of using them for a count, why not let them.
With QtWebKit it's probably okay to still use it (*cough* Hyperbola
GNU/Linux-libre^tm *cough*), and only blacklisting it with QtWebEngine would be
quite some effort.
Fixes#3608
This handles Qt.KeypadModifier (Num+...) correctly, adds tests for converting
modifiers to strings, and strips Qt.GroupSwitchModifier as QKeySequence doesn't
know about it.
Fixes#3675
When pressing a key which doesn't exist as Qt.Key, we don't get Qt.Key_unknown
like we'd expect, but we get 0x0 instead...
Let's add that as a new "nil" key (to not conflict with None/unknown/zero/...)
and handle it appropriately.
This can be reproduced by doing:
setxkbmap -layout us,gr -option grp:alt_shift_toggle
and pressing Alt-Shift/Shift-Alt.
Turns out when we press yY, we get three events:
Qt.Key_Y, Qt.NoModifier
Qt.Key_Shift, Qt.ShiftModifier
Qt.Key_Y, Qt.ShiftModifier
If we don't ignore the second one, our keychain will be interrupted by the Shift
keypress.
Now that we don't rely on str(KeyInfo) being empty anywhere, there's no reason
to return an empty string for only-modifier keypresses anymore.
While those keys can't be bound (QKeySequence('Shift') == Qt.Key_unknown)
there's also no reason to explicitly ignore them.
Hopefully closes#3627
This feels like fixing the symptom instead of the problem but I am not
sure how such a situation would arise. Never the less, the crash logs
clearly show that `_inject_userjs()` is being called with a deleted
frame sometimes. It is being called from a closure that gets triggered
on frame.loadFinished so I am not sure how frame could be deleted at
that time unless:
* the error message is misleading and it is actually some reference to
the object that is no longer valid
* the frame gets deleted from some other handler of loadFinished.
Previously to add a greasemonkey script you had to write it to the
greasemonkey data directory and call load_scripts(). Now you can just
make a new GreasemonkeyScript and pass it to add_script(), yay.
There are no users of the method yet although I could have used it while
writing the tests.
When `@require`ing local files (with the `file://` scheme) the
greasemonkey manager was not catching the DownloadItem.finished signal
because it was being emitted before it had managed to connect.
I didn't see this happening while testing with files that should have
been in cache but I wouldn't be surprised.
I had to change the download mock to be able to give it the appearance
of asynchronicity. Now when using it one must set download.successful
appropriately before firing download.finished. I also added a list of
downloads to the stub so a test could enumerate them in case the
unit-under-test didn't have a reference to them.
This is for the case where a script uses `@require` to pull down another
greasemonkey script. Since QWebEngineScript doesn't support `@require`
we pass scripts to it with any required ones pre-pended. To avoid
QWebEngineScript parsing the first metadata block, the one from the
required script, we indent the whole lot. Because the greasemonkey spec
says that the //==UserScript== text must start in the first column.
Apparently the currently available QtWebkit's javascript engine doesn't
support Object.entries[1]. It was only using that because I had copied
it from the official gm4 polyfill (maybe I should open an issue there?).
Tested with libqt5webkit5 version 5.212.0~alpha2-5 (debian) and I was
getting the same type of failures as Travis so it looks like this is the
case in arch too.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/entries
This is to support the non-interactive use case of setting a
`FileDownloadTarget` and passing auto_remove and not caring if the target
file exists or not.
An alternative to adding the attribute to `FileDownloadTarget` and
having set_target pull it out would be to add a new param to `fetch()`
and `set_target()`. But it would only be used for one target type
anyway.
Based on the gm4-polyfill.js script from the greasemonkey devs. But not
the same because that script doesn't work for us for a couple of
reasons:
* It assumes all GM_* functions are attributes of `this` which in
this case is the global window object. Which breaks it out of our iife.
It is possible to change what `this` is within the iife but then we
would have to do something weird to ensure the functions were available
with the leading `this.`. And I don't think user javascripts tend to
call GM functions like that anyway, that polyfill script is just making
weird assumptions and then claiming it'll work for "any user script
engine".
* It tries to provide implementations of GM_registerMenuCommand and
GM_getResource text which do unexpected thins or implement a circular
dependency on the new version, respectively.
The greasemonkey spec states that user scripts should be able to put the URL
of a javascript source as the value of an `@require` key and expect to have
that script available in its scope. This commit supports deferring a user
script from being available until it's required scripts are downloaded,
downloading the scripts and prepending them onto the userscripts code before
placing it all in an iffe.
TODO:
* should I be saving the scripts somewhere else? Maybe the cache dir?
The are just going to data/greasemonkey/requires/ atm.
When min_chars is nonzero, if the first command that opens the
completion has < min_chars on the word under the cursor, it triggers a
check for a condition where last_cursor_pos is None.
By setting last_cursor_pos=-1 we ensure that the completer always
updates the first time it is opened, and that there is never a check
against None.
This adds a test for the min_chars feature.
Resolves#3635.
The --pygment argument allows to use the pygment version of view-source
over the qtwebengine internal one.
This version is slightly different in what's processed before the site
is generated, so some javascript created texts can be available.
