| Age | Commit message (Collapse) | Author |
|---|
|
Why? See #13. This commit closes #13.
|
|
|
|
The WebKit1 version of lariza simply ignored certificate errors. I could
have turned off validation in WebKit2 as well, but I wanted to try to do
it right. :-)
Closes #12.
|
|
Addressing the issues mentioned in the README:
- I'm using it every day and I haven't found any more bugs (in lariza).
- "View source" mode is still not implemented. However, I don't see any
other way than re-downloading the current weg page and showing the
results in some to-be-written widget that displays text (+ HTML syntax
highlighting + maybe other stuff). That's quite a lot of overhead for
a rarely used feature, so I decided to drop it.
- That "annoying border around the WebView widget" is related to my gtk
theme (upstream "Raleigh"). Adwaita, the current GTK+ 3 default theme,
does not have that border.
tl;dr: The WebKit2 port is as ready as it can get and it's "more bug
free" than the WebKit1 version.
|
|
|
|
This is kind of a quickfix as well (related to #10). I'll have to use
this for a while to see if I'm happy with it.
|
|
Every new window added download_handle_start() as a signal handler to
the global WebKitWebContext. This is wrong anway, because the signal
handler sets the destination path; this should not be done multiple
times.
The actual crash happened when a window was closed and *then* a download
started. The window's signal handler still existed with a pointer to the
window's "struct Client". This struct, however, is now free'd and
invalid. Hence the crash.
To get rid of the crashes, only add the signal handler once. Sad thing
is, this makes the "status" level bar useless: It would only work for
the very first window ever created -- if it still existed. If that
window has been closed as well, we would still crash. Thus, remove
"status" completely.
We'll have to find a new way to announce the start of a download.
Closes #10.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... because it's WebKit2's default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
With WebKit2, adblock is no longer a trivial task. It must be realized
as a "web extension" in WebKit2. See, for example:
http://blogs.igalia.com/carlosgc/2013/09/10/webkit2gtk-web-process-extensions/
We need to connect to the "send-request" signal and stop the request
from being sent in the first place.
|
|
|
|
|
|
|
|
As suggested by #8.
|
|
Plus, my "80 characters" only work with 4-spaced-tabs anyway. I might
rethink that.
|
|
MB is good enough, I don't care about byte, kilobyte, megabyte,
gigabyte, ...
Yes, SI units.
|
|
I checked WebKit's source code: webkit_download_get_destination_uri()
never returns NULL in lariza. It's because we set the destination URI in
the signal handler for the download request.
If g_filename_from_uri() really returned NULL for some reason, then it'd
be just plain wrong to announce the "suggested file name", because we
might be saving the download ... somewhere else. I doubt this function
ever returns NULL in lariza, though, but you never know.
So, now, the download manager will correctly show the URI if the
destination URI is "unknown".
|
|
CC #6.
|
|
Ugly hackaround. Closes #6, though.
|
|
CC #5.
|
|
Closes #5.
|
|
As suggested by @okraits in #2.
|
|
While Mod1 + q is consistent with the main window, it also poses the
risk of accidentally closing the main window. With Mod1 + d it's more
like a "toggle the download manager".
|
|
|
|
|
|
Let's stick to WebKit's and GNOME's terminology.
|
|
|
|
|
|
|
|
Disconnect the handler for "notify::progress" because that signal might
get fired after "c" has been free'd which resulted in a reproducible
crash.
|
|
|
|
|
|
GLib catched these errors but it's wrong nevertheless.
|
|
|
|
|
