| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
A couple of TODO features have been left guarded by #if 0 blocks.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=693832
|
|
|
|
| |
GCC, you need to warn me about these.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Firefox has led the way implementing this behaviour to improve the experience
of restoring a session with lots of tabs. By delaying the loading of pages to
when the user shows interest in them, the time it takes for the browser to
become usable is diminished, and less pages are loaded in parallel, which
improves load time for the first pages the user sees.
It also has the advante of displaying less HTTP Basic Auth dialogs, when the
user has many tabs pointed to the same server.
https://bugzilla.gnome.org/show_bug.cgi?id=675302
|
|
|
|
|
|
|
| |
ephy_web_view_get_security_level
Remove the unused description parameter an return the TLS certificte and
errors instead.
|
| |
|
| |
|
|
|
|
| |
Do not make it public.
|
|
|
|
|
|
| |
Nowhere in epiphany were we using the "get the non-toplevel location"
feature (which was broken anyway), so I think we should be able to
just use get_address everywhere.
|
|
|
|
|
| |
In both ephy_web_view_set_link_message() and
ephy_embed_utils_link_message_parse().
|
|
|
|
| |
To check whether the load operation in the web view failed.
|
|
|
|
| |
It builds and basic functionality works.
|
|
|
|
|
|
| |
We add it to EphyWebViewChrome and track it there.
https://bugzilla.gnome.org/show_bug.cgi?id=671195
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=676904
|
| |
|
|
|
|
| |
We do not support this anymore in our UI.
|
|
|
|
| |
It's only used by the class itself now.
|
| |
|
| |
|
| |
|
|
|
|
| |
And add a getter for the information.
|
|
|
|
|
|
|
|
|
| |
WebKitWebView has a ::close-web-view signal for the same thing.
The only user of this was ephy-window, for exactly the same thing that
we are already doing in ephy-web-view, when handling ::close-web-view.
https://bugzilla.gnome.org/show_bug.cgi?id=669737
|
|
|
|
|
| |
It's already accessible from the Print dialog itself, so there's
really no need to duplicate it.
|
| |
|
|
|
|
|
|
|
|
| |
Hardcode it to be "about:blank". The final step could be completely
remove the rest of the code, but it might be useful for the future
Overview page (if we consider it the new "homepage").
https://bugzilla.gnome.org/show_bug.cgi?id=665469
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Allow to save any page as a "Web Application". A new .desktop file
will be created, and added to the Shell as a new application. It will
launch epiphany in application mode, with its own private profile
(inheriting some data from the main profile, like the relevant domain
cookies) and in a new process.
|
|
|
|
|
| |
It's where it belongs, and it will make things easier for the
following patches in this area.
|
|
|
|
|
|
| |
Show nice error pages instead of WebKitGTK+'s defaults.
Bug #592667
|
|
|
|
|
|
| |
Non prefixed names trigger lots of warnings, avoid them.
Bug #636790
|
|
|
|
| |
They are not even emitted anymore, and are unused.
|
|
|
|
|
| |
Would duplicate the functionality of the WebKit DOM signals, if it
worked at all...
|
|
|
|
|
| |
Define them in the EphyWebView header, since we'll need to create the
context ids from multiple files.
|
|
|
|
|
|
|
|
|
|
| |
Get rid of our statusbar for good and switch to something like what
Chromium uses, since it takes less vertical space.
The only regression is that we lose the resize grip, but that should
be re-added to GtkWindow soon.
Bug #609713
|
| |
|
|
|
|
|
|
| |
Create a method to make the EphyWebView load the homepage set by the
user. This is in preparation for creating a signal for this action,
which other code in Epiphany will need.
|
|
|
|
|
|
|
|
| |
This patch uses the ephy-embed.c callback code and refactors it in
just one method in the ephy-web-view that handles all the status
changes for this object.
Bug #593743
|
|
|
|
|
|
|
| |
We can use the webkit load status (WebKitLoadStatus) and avoid
defining our own enum to check the net states.
Bug #593743
|
|
|
|
|
|
|
|
|
|
| |
Added new function in EphyWebView to clear the history from
WebKitWebView, and connect to the 'cleared' signal in EphyEmbed to call
to such a function when needed.
Bug #539716
Signed-off-by: Xan Lopez <xan@gnome.org>
|
|
|
|
|
|
|
|
|
| |
Use the already existing functions we have for print preview also for
printing; fixes a bunch of usability issues.
Bug #609756
Signed-off-by: Xan Lopez <xan@gnome.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Created function ephy_web_view_show_print_preview, which replaces the
old implementation of print preview, which was not working now.
Preview is displayed in an external viewer, so print preview mode does
no longer exist.
All functions of the old implementation of print preview have been
removed, PPViewToolbar was removed also. Also, as EphyWebView has no
more a print preview mode, all functions which checked if a view was
in print preview mode were modified.
Bug #609021
|
| |
|
|
|
|
| |
Also redundant since we have the same thing in WebKitWebView now.
|
| |
|
|
|
|
| |
We already have WebKitWebView::icon-loaded, so it's redundant now.
|
|
|
|
| |
Bug #503852
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a few items (like email link) and actions (like bookmark link)
missing or not working because of missing information in the
WebKitHitTestResult object, but most of the stuff is working.
For some reason the g-ir-scanner is not picking up the correct type
name for WebKitHitTestResult (it uses WebKitHitTestResult instead of
WebKit.HitTestResult), so the introspection support is broken unless
that error is fixed manually. Looking into that ...
Bug #562617
|
|
|
|
| |
Bug #562611
|
|
|
|
|
|
| |
The whole thing just had one functionality at this point as far as I
can see: prevent the typed address from being wiped out when a page
is loading. Simplify the code to do just that.
|
|
|
|
|
| |
Much more clear, and avoids confusions with the WebKitWebView function
with similar name.
|
| |
|
|
|
|
|
|
|
|
|
| |
We now use WebKitWebView's 'progress' property directly.
The "opening about:blank blinks the entry" bug is back because for
some reason a) webkit reports a 10% progress for that URL b) get_uri
reports NULL until 100% is loaded for only that page, so blacklisting
by URI is not possible either.
|
|
|
|
| |
Holds the code that used to be in WebKitEmbed, which is now dead.
|
|
|
|
|
|
|
| |
EphyWebView.
Those two embed classes are pretty much dummy leftovers, so it should be
easier to remove them now.
|
| |
|
|
|
|
| |
Just part of the gradual progress to get rid of the Embed interface.
|
|
|
|
|
|
| |
As the first API adition to out WebKitWebView subclass, we allow
Epiphany code to use a WebKitNetworkRequest to load pages. This way we
can use the full request information, not just the URI.
|
|
This is an object inheriting from WebKitWebView, and will be used to
house most of the functionality we move from EphyEmbed.
|