In a48ea597d0 we fixed settings in private
QtWebEngine windows.
However, this means we also enable local storage for private windows, which was
disabled in QtWebEngine by default:
4ef5831a39 (diff-44ac7d27348388501944f6a8e2e67d8dR207)
It should be safe to enable it, as we get the same behavior as in Chromium, i.e.
a working local storage which entirely lives in RAM.
This also makes those tests work on QtWebKit-NG, presumably because private
browsing for cookies is implemented there.
It also adds a test to at least check whether local storage is isolated from
non-private tabs. I tried writing a test which ensures nothing lands on the hard
disk, but due to QTBUG-52121 this might not happen at all:
https://bugreports.qt.io/browse/QTBUG-52121
Turns out QWebEngineSettings.globalSettings() only sets things on the default
profile. We now get everything from the default profile settings, but set it on
both the default and the private profile.
Fixes#2638
(cherry picked from commit b11a4388cd10b6ff2fd917fca689ebdc50d581ae)
If we don't wait here, we might end up running the subsequent commands (like
:command-history-prev) on the old window while it's still closing, causing an
exception at least on AppVeyor:
Traceback (most recent call last):
File "C:\projects\qutebrowser\qutebrowser\app.py", line 110, in <lambda>
target_arg=target_arg))
File "C:\projects\qutebrowser\qutebrowser\app.py", line 265, in process_pos_args
win_id = mainwindow.get_window(via_ipc, force_tab=True)
File "C:\projects\qutebrowser\qutebrowser\mainwindow\mainwindow.py", line 89, in get_window
window.setWindowState(window.windowState() & ~Qt.WindowMinimized)
RuntimeError: wrapped C/C++ object of type MainWindow has been deleted
There's actually no good reason to filter javascript links as we might want to
click them (or copy their URL) just like any other link - this fixes#2404.
With that being gone, we don't need FILTERS at all anymore, as we can check for
existence of the href attribute in the CSS selector instead.
Looks like we get this sometimes:
----> Waiting for 'Clicked non-editable element!' in the log
14:02:14.976 DEBUG webview webkittab:find_at_pos:618 Hit test result element is null!
14:02:14.976 DEBUG mouse mouse:_mousepress_insertmode_cb:149 Got None element, scheduling check on mouse release
14:02:14.977 DEBUG mouse webview:mousePressEvent:299 Normal click, setting normal target
14:02:14.978 DEBUG mouse mouse:mouserelease_insertmode_cb:173 Element vanished!
This could happen for any of the attributes, but for tagName this actually
happens in the wild... Since elem.tagName is equal to elem.nodeName we just try
to use this.
Fixes#2569
