| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Minimal solution, add fixed AdGuard youtube blocker.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1534
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1000>
|
|
|
|
|
|
|
| |
Use internal pdf viewer only for GET. In case it is a POST request download it.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1505
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1001>
|
|
|
|
|
|
|
|
| |
Apparently this code is a workaround for
https://bugs.webkit.org/show_bug.cgi?id=221771, which has been fixed, so
we should no longer need it anymore.
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/973>
|
|
|
|
|
|
|
|
|
|
|
| |
The new version of PDF.js is having trouble loading our icons via
ephy-resource:// URIs. We're going to need to disable CORS to solve
this. We can replace it with some custom security checks to restrict
resource access as far as practical based on the URI scheme of the main
resource. Error page assets will have to be left open, though. It's
pretty hard to see how that could be abused, so I think it's OK.
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/975>
|
|
|
|
|
|
|
|
| |
Try to handle misconfigured servers and check the file content locally based on content.
If it is not valid, remove stray file.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1543
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/998>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WebKit determines that the web process is hung when it has been more
than three seconds since it has responded to a ping from the UI process.
Turns out, this timeout is too low in practice because websites
routinely run JavaScript for longer than this. So let's wait 10 seconds
after the process is determined to be unresponsive, for 13 seconds
total, before we kill anything. My hope is that this makes the
unresponsive process killer less painful in practice.
We might still want to ask users before killing anything, #1561, but
this might suffice for now. Maybe.
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/994>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if doing a search using a bang (e.g. "!ddg GNOME") the whole search
is lowercased. This is unexpected as one might want to include the correct
caps so that it lands on the right page straight away, without needing to
go through the search results page. This is the case for example if searching
"!wt Katze" (with the wiktionary), where it'll land on a page saying that
the "katze" page doesn't exist but instead there is the Katze page (in german
caps at the beginning of words is important for nouns), even though "Katze" was
already what was searched in Epiphany's search bar.
So this was a bug where it wanted to lowercase only the hostname part (like
GOOgle.com => google.com) but did it before it checked and processed the bang
search, which isn't a proper URI so it assumes the hostname is the whole string
and lowercases it.
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/988>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WebKitGTK 2.33.1 allows us to detect and kill runaway web processes.
Let's take advantage of that.
The process is not detected as unresponsive for quite a while -- 10
seconds -- so there's no need for any secondary timeout at the Epiphany
level. Let's kill it immediately when WebKit says the web process has
been lost. If the WebKit timeout were shorter, then prompting the user
to decide whether to kill the page would make more sense, but 10 seconds
is long enough that any web content that hasn't returned to the main
loop deserves to be immediately killed. There's no excuse for that.
|
|
|
|
|
|
| |
It's freed twice in a row in this function, oops.
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/962>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/958>
|
|
|
|
|
|
| |
This is a one-time leak, but still a leak. Found by valgrind.
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/958>
|
|
|
|
|
|
|
| |
CONSOLE LOG Deprecated as of 10.6.0. initHighlightingOnLoad() is deprecated. Use highlightAll() instead.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1501
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/959>
|
| |
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/950>
|
|
|
|
| |
See #1435 for discussion of why we can't do this with older WebKit.
|
|
|
|
|
|
|
|
| |
I incorrectly assumed that a GTask becomes completed once
g_task_return() is called. In fact, it becomes completed once its
callback is invoked, which may occur later.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1942814
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit b37ef802ce0eaf556916ae292bd76afa0b1fc73e.
Looks like we were too aggressive here. WebKit's default behavior may
not actually be suitable for browsers. It broke the VMWare vSphere web
console.
Fixes #1467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If any web process is unresponsive when the window is closed using the
close button in the header bar -- not Ctrl+Q -- then the entire session
state is lost. Disaster! This happens to me three or four times per
year, and it is sad because it inevitably results in me forgetting
important things I had to do.
Anyway, the problem is our code to handle an unresponsive web process.
We'd like to cancel the JavaScript execution using
g_cancellable_cancel(), but it doesn't work because the underlying
WebKit operation is not actually cancellable, so instead we use a big
hammer and gtk_widget_destroy() the EphyWebView. Then when we wind up
closing the session later, there are no tabs open and nothing to save.
It was tricky to figure out how to fix this, because the only way to
truly cancel the operation is to destroy the web view, and if we do that
then we have to close the session first to avoid losing tabs, but the
user could legitimately choose to reject a modified forms close
confirmation warning, in which case they would wind up using Epiphany
after the session is closed, meaning all subsequent changes to open tabs
would be lost since they won't be saved after the session is closed.
Eventually I realized that we can just move the timeout from EphyWindow
-- where it's handled in two separate places, once for closing a single
tab, and once for closing an entire window -- down into EphyWebView
itself. This solves all our problems because now EphyWindow can assume
the JS execution always completes in a reasonable time.
I tested this by changing the call to
webkit_web_view_run_javascript_in_world() in
ephy_web_view_has_modified_forms() to execute a while(true) loop.
Without the other changes, the session state is lost if closing the
window using the close button in the header bar. With this patch, the
session state is no longer lost.
Fixes #1445
|
|
|
|
|
| |
ephy-pdf: is an internal URI scheme and it shouldn't be showing up in
the address bar dropdown or the history dialog.
|
|
|
|
|
|
|
|
|
| |
When the floating bar covers a link at the bottom of the page, I should
be able to click the floating bar to click the link. This broke in !850.
There is some visual glitchiness where the bar briefly appears on the
left before being moved out of the way to the right, but I'm not sure
how to fix that
|
| |
|
|
|
|
| |
Fixes #1443
|
|
|
|
| |
Replace the aging GtkNotebook-based tabs with a new implementation.
|
|
|
|
| |
dispose works fine.
|
|
|
| |
This reverts commit 7d73117519c792cccceb757c50bc7a8dd98f0ac9
|
|
|
|
| |
Make it clear that this is an own epiphany internal uri scheme.
|
|
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1435
|
|
|
|
|
|
| |
In case the pointer hovers the floating bar move it to the other direction.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1368
|
| |
|
| |
|
|
|
|
|
| |
This was rejected from WebKit in
https://bugs.webkit.org/show_bug.cgi?id=220512.
|
|
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/802
|
| |
|
|
|
|
| |
set_default_application_title will fallback to a better formatted hostname
|
|
|
|
|
|
|
|
|
|
|
| |
With commit 809d76e6cfc7 (Pre-fill search field with current selected
text) focused text from the website will be pre-filled into the search
entry. This is great, but even though the entry is focused, one cannot
simply start typing to update the search text.
Improve this user interaction by selecting the pre-filled text.
Related: #809
|
| |
|
|
|
|
|
|
|
| |
Addresses with a space shouldn't be treated as a valid host with port. Just
exit early.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1418
|
|
|
|
| |
We don't want type coercions anywhere in our comparisons.
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the icon is handled in a weird way involving manually managing
a cairo surface instead of just using GIcon. Getting scale factor from the
window doesn't work when the widget isn't realized yet and doesn't have a
window to begin with, which gtk_widget_get_scale_factor() does handle.
Additionally, the icon isn't reloaded on scale factor changes.
Fixes https://gitlab.gnome.org/GNOME/epiphany/-/issues/1298
|
|
|
|
|
| |
This API is deprecated in 2.32, and it hasn't been needed since
2.6.something since FAIL is now default, so we can drop it.
|
|
|
|
| |
Fixes #1358
|
|
|
|
|
|
| |
We need to own the WebKitPolicyDecision.
Probably fixes #1357
|
|
|
|
|
|
| |
Move gsb_api_key to meson_options.txt so we can provide the necessary support within flatpak, but can disable it for the rest.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/682
|
|
|
|
|
|
|
| |
Store user reader mode toggle request as EphyWebView property. Based on this information
load the existing source data or trigger a new load.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1339
|
| |
|
|
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1326
|
|
|
|
|
| |
They cannot be deleted as we don't control their desktop file. Don't show
them at all.
|
|
|
|
|
|
|
| |
This old, manual, and very non-comprehensive method of tracking
prevention doesn't make much sense to do now that we have far more
sophisticated anti-tracking measures in WebKit and enabled by default
that don't require listing ad-hoc query parameters to remove from URLs.
|
|
|
|
| |
Looks like it's a leftover from inspector from very long ago.
|