The recent pytest 7.2 upgrade leads pylint to complain:
************* Module unit.browser.test_qutescheme
tests/unit/browser/test_qutescheme.py:26:0: I0021: Useless suppression of 'no-name-in-module' (useless-suppression)
tests/unit/browser/test_qutescheme.py:226:0: I0021: Useless suppression of 'no-member' (useless-suppression)
************* Module helpers.fixtures
tests/helpers/fixtures.py:39:0: I0021: Useless suppression of 'no-name-in-module' (useless-suppression)
tests/helpers/fixtures.py:639:0: I0021: Useless suppression of 'no-member' (useless-suppression)
possibly due to it not being able to infer 'py' anymore with the weird
shenanigans pytest does now?
Also, what weird glitch in the matrix is it that those just happen to be
on lines [2]26 and [6]39 for *both* files? 🤯
There is now some code in statusbar relying on the enabled attribute
stopping events from being processed (or at least stopping them from
showing the widget again). So add tests to make sure that behaviour
keeps working.
Also split the big test in test_backforward into a couple of smaller
ones and pull some common lines out to a (still clunky) fixture.
Not sure why we didn't do this initially, maybe it wasn't possible: https://webpy.org/cookbook/ssl
This means we don't need to (ab)use the Flask development server anymore.
We used to dodge these by listening on 0.0.0.0. Now they are on to us
and always show the warnings. Running flask in development mode here is
intended, so lets not have the warnings fail the tests.
Ref: https://github.com/pallets/werkzeug/issues/2480
Those commands use the config interface expecting Python objects (via
update_mutables), but we always used the raw user-supplied string as
input.
Thus far, it was very hard to trigger this bug: It would only
trigger with a List or Dict config option, with a value type which does
*not* accept a string type in to_py(). That means:
- List / FlagList / ConfirmQuit / ShellCommand
- Bool / BoolAsk
- Int
- Float
- Dict / Padding
(Notably, Perc, PercOrInt and Regex all *do* accept a string.)
That leaves only a couple of candidates:
- hints.selectors, but that's "no_autoconfig: true"
- bindings.default, ditto
- bindings.commands, but no reason to use :config-dict-* on it,
especially with fixed keys
Therefore, this got only uncovered now, after adding
content.javascript.log_message.levels, which is a Dict with FlagList
values.
Note that we still don't have any config definition with an affected
List type, thus currently making it impossible to test the changes for
:config-list-{add,remove}.
Also note the adjusted test_{dict,list}_add_invalid_value tests - they
were just plain wrong. The command functions are never going to be
called by a Python object from the user (only with a str).
Finally, test_list_remove_no_value also needed an adjustment because
the value validation now happens *before* the other validation done
by the command.
If we only clear existing mutables *after* applying, we get into an
inconsistent state if there was an error in one of the config values:
The improper value lingers around in self._mutables, and then gets
returned when get_mutable_obj() (or update_mutables()) gets called the
next time.
Reproducer:
qutebrowser --debug --temp-basedir \
':config-dict-add content.javascript.log_message.levels example.org bla' \
':later 1000 config-dict-add content.javascript.log_message.levels example.org bla'
Results in:
ERROR: Invalid value 'bla' - expected a value of type list but got str.
ERROR: example.org already exists in content.javascript.log_message - use --replace to overwrite!
Fixes the second part of #7343.
nb: As before, the mutable updating actually gets interrupted by a
failing update, instead of it e.g. collecting all errors but carrying
on. With this change, the remaining updates will thus also be discarded,
but that does not seem to be a problem with how mutables are currently
used. Ideally, we should get rid of the mutable handling entirely
anyways, at least for qutebrowser internal code - see #4344.
Those are handled separately from the other settings, but were never initialized
properly in init_settings().
For content.javascript.clipboard, this is a recent regression introduced in
4a6df3a8e8. For content.default_encoding, this has
been around since 2018: 3956f81e73.
Fixes#7281
Florian Bruhin
Kian-Meng Ang
toofar
kt programs