CommandRunner.parse had some logic for handling commands of form
:<count>:cmd. However, this complicated the parsing logic for something
that appears to only be used in tests. One could use it in a
userscript, but this is unlikely as it is undocumented. Removing
support for this simplifies the logic of parse.
The commnd `run-with-count` is added to provide this functionality.
It works like `repeat` but passes the count along to the command
instead of running the command multiple times.
This resolves#1997: Qutebrowser crashes when pasting commands.
This bug was caused by excess stripping of ':' from the command string
by _parse_count.
There is no reason I guess to do this with an environment variable. On
top of that, introducing a settings also documents the netrc feature
itself (Closes #1975?).
I got this during shutdown once:
Traceback (most recent call last):
File ".../qutebrowser/mainwindow/mainwindow.py", line 552, in closeEvent
File ".../qutebrowser/mainwindow/mainwindow.py", line 538, in _do_close
File ".../qutebrowser/mainwindow/tabbedbrowser.py", line 218, in shutdown
self._remove_tab(tab)
File ".../qutebrowser/mainwindow/tabbedbrowser.py", line 280, in _remove_tab
tab.shutdown()
File ".../qutebrowser/browser/webengine/webenginetab.py", line 536, in shutdown
log.stub()
File ".../qutebrowser/utils/log.py", line 151, in stub
function = inspect.stack()[1][3]
File "/usr/lib64/python3.5/inspect.py", line 1464, in stack
return getouterframes(sys._getframe(1), context)
File "/usr/lib64/python3.5/inspect.py", line 1441, in getouterframes
frameinfo = (frame,) + getframeinfo(frame, context)
File "/usr/lib64/python3.5/inspect.py", line 1414, in getframeinfo
lines, lnum = findsource(frame)
File "/usr/lib64/python3.5/inspect.py", line 804, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range
They renamed PDFView to PDFViewerApplication, which we need to account
for in our pdfjs scripts.
Also, it seems like the actual viewer is now only created when the DOM
has been loaded. This means that at the time when our script is
executed, the viewer does not yet exist. Thus we need to delay the open
request too by registering a DOMContentLoaded handler.
On some pages with particular zoom levels, elem.offsetHeight is exactly
one pixel more than elem.scrollHeight when fully scrolled down.
This is probably due to rounding/floats/off-by-one errors somewhere
inside Chromium?
We now instead always clip the displayed percentage at 100% (so we don't
display 101%), and consider the page fully scrolled even if we're
scrolled more than the page.
This reverts commit 0c5d95c943.
Using those values is probably okay as long as we adjust for the
off-by-one errors which will follow in the next commit.
scroll measures failed a travis test where document.documentElement.offsetHeight and document.documentElement.scrollHeight diffed by one pixel when the browser zoomed. --> Removed offsetHeight.
