summaryrefslogtreecommitdiff
path: root/embed
Commit message (Collapse)AuthorAgeFilesLines
* WIP: Copy Sonny's impl for manifest supportmwleeds/webapp-manifest-supportPhaedrus Leeds2022-03-303-0/+66
|
* file-helpers: Drop unused timestamp paramsAlexander Mikhaylenko2022-03-221-3/+3
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1096>
* download: Drop timestamp from do_download_action()Alexander Mikhaylenko2022-03-222-9/+6
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1096>
* download: Stop tracking download start timeAlexander Mikhaylenko2022-03-222-42/+1
| | | | | | This won't work in GTK4, so just always use GDK_CURRENT_TIME. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1096>
* Fix web app icon url vs path confusionPhaedrus Leeds2022-03-211-8/+8
| | | | | | | | | Confusingly, the icon_url member of EphyWebApplication is actually a path not a URL or URI. The only place where it gets set to a URI is in prefs-general-page.c when the user changes the icon, and there it is happening erroneously since all the other code that deals with it assumes it is a path. So, rename the struct member and ensure all the use of it treats it as a path.
* Make web app manager work under FlatpakPhaedrus Leeds2022-03-211-2/+14
| | | | | Make use of the GetIcon() portal method so the app manager can work under Flatpak.
* Get rid of web app install_date stringPhaedrus Leeds2022-03-211-1/+7
| | | | | Just create the string in the one place we need it rather than always storing it. This introduces no functional changes.
* Migrate web apps to portal locationsPhaedrus Leeds2022-03-211-9/+6
| | | | | | | | | | | This is yet another migration of web apps. This time we are changing the GApplication ID to make it simpler and more D-Bus friendly. We also have to ensure the GApp ID has the app ID as a prefix to be able to use the dynamic launcher portal (and in order to own the right bus name when the web app is run). We also migrate the web apps' desktop files and icons to the locations they'd be in if we had used the portal to create them, so that going forward they will all be in one place and things should be simpler.
* Add a WebAppProvider D-Bus interfacePhaedrus Leeds2022-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a D-Bus service that exposes the web apps managed by Epiphany so that a client can enumerate them, install a new one, or remove an installed one. The intended client is GNOME Software, since I am soon going to add back a webapp plugin to Software which will make use of this interface. This is part of a larger effort to improve the support for Progressive Web Apps in GNOME (though Epiphany's web apps do not support PWA manifest features). The great thing about having this be a service exposed by Epiphany, rather than having Software try to install Epiphany-compatible web apps on its own as it used to do, is that the implementation of how to create and manage the web apps can stay in Epiphany, and there can never be disagreement between Epiphany and Software about the proper on-disk format for them (e.g. the algorithm used for generating the app ID from the name). The goal for the PWA project is to support Flatpak'd Epiphany, whereas currently only non-Flatpak Epiphany can do web apps. This will be accomplished with new portals to allow installing and removing the .desktop launchers. The Flatpak support requirement is reflected in the design of the API here, specifically the install_token parameter for the Install() method. This token is to be acquired by the client of the D-Bus interface (Software) so that the installation can be achieved without any additional user interaction since the user would've already clicked "Install" in Software. Web app installation directly via Flatpak'd Epiphany's UI would involve a dialog created by the portal; this is because we don't want sandboxed applications in general to be able to create desktop launchers without user interaction. The Uninstall() method by contrast doesn't require such a token, because the portal can ensure that only apps created by an application are deleted by that application. The GetInstalledApps() method is implemented by looking at the profile directories of the apps, because we don't want to have to poke a sandbox hole to allow access to the actual desktop files.
* find-toolbar: Remove dead codeAlexander Mikhaylenko2022-03-012-36/+4
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1085>
* reader-handler: fix double free of errorMichael Catanzaro2022-03-011-1/+0
| | | | | | | | | | | When the reader mode JS fails, we accidentally free it manually, even though it's stored in an autoptr. Oops! Fixes #1698, sort of. This really only fixes the Epiphany side of things. I will report a separate WebKit bug to ensure the JS execution never fails. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1084>
* web-view: Remove ::search-key-pressAlexander Mikhaylenko2022-02-251-34/+0
| | | | | | It's unused and not portable to GTK4. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1081>
* Prefer GFile-based GtkFileChooser APIAlexander Mikhaylenko2022-02-181-5/+25
| | | | | | | | Everything else will go away in GTK4, and while some of the old functions got renamed, it's easier to just rename them later rather than move them from path/uri to GFiles. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1072>
* download: Stop using GtkFileChooserButtonAlexander Mikhaylenko2022-02-181-8/+81
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1072>
* search-engines: Port whole EphySearchEngineManager code to GListModelvanadiae2022-02-111-60/+28
| | | | | | | | | | | | | This commit ports EphySearchEngineManager to being a proper GListModel, with a separate EphySearchEngine object for each search engines. That makes the code overall way cleaner and easier to work with, as there's no need to keep track of the old_name and saved_name or whatever horrible thing that I needed to do, since now we just need to keep around the EphySearchEngine object we're displaying in this preferences row, and do changes on it directly. That did require quite a few changes all around the code base to adapt to all API changes, but it is definitely worth it. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1055>
* embed: Properly allow translation of concatenated ", "%s"" in mailto: handlingvanadiae2022-01-291-1/+9
| | | | | | | | This part wasn't allowed as a translatable string, so in french for example we'd have a mismatch of quotes type since the first email address would have «» as quotes but the next addresses have "" instead. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1065>
* embed: Split mailto: URIs' addresses using the correct comma separatorvanadiae2022-01-291-1/+3
| | | | | | According to the RFC, it's not a semi-colon but a comma instead. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1065>
* about-handler: don't encode app ID (or install date)Michael Catanzaro2021-12-201-12/+11
| | | | | | | | | | | | | | We are overencoding here. Epiphany is not prepared to handle the encoded app ID, and it is not necessary to encode in the first place because the app ID is trusted to be a valid GApplication ID, which cannot contain nasty characters. However, encoding the URLs here really is necessary, because they really could contain nasty content. Fixes #1665 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1050>
* Fix reload buttons on error pagesMichael Catanzaro2021-12-202-59/+114
| | | | | | | | | | | The encoded URL here does not work. And we cannot reload via the web process, because the window.location is about:blank for alternate HTML, so we'll have to send a message to the UI process to have it do so instead. Fixes #1663 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1050>
* reader-handler: unbreak reader mode and add CSPMichael Catanzaro2021-12-161-4/+17
| | | | | | | | | | | | | | | | | | | | | HTML-encoding the content passed to reader mode does not work because it contains HTML markup generated by Readability.js. Oops. I must have seriously screwed up when testing this yesterday, because there is no way this could ever have worked. Upstream recommends use of a DOM purifier, but in theory, if we completely block *all* script execution, we can avoid the need for that. So add a CSP recommended by Patrick. We'll sneak in a couple bonus fixes: use ' rather than " to improve readability, and close the </body> tag that we opened rather than abuse the permissiveness of the parser. Fixes: #1612 See also: #1661 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1047>
* Style web app delete button like destructive-classPhaedrus Leeds2021-12-161-1/+2
| | | | | | | | | | This changes the style of the "Delete" button on the "about:applications" page so that it looks like it has the "destructive-class" applied, which makes it more consistent with destructive buttons across the rest of GNOME. The CSS is copied from error.css. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1040>
* about-handler: don't attribute-encode title entityMichael Catanzaro2021-12-151-4/+7
| | | | Let's use only the required encoding here, and not more.
* web-view: encode data in error pagesMichael Catanzaro2021-12-151-11/+30
| | | | | | | Page titles and URLs are untrusted and could be nasty, so we need to encode them appropriately when injecting them into HTML. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* web-view: convert error pages to use autofree/autoptrMichael Catanzaro2021-12-151-53/+24
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* reader-handler: encode data when constructing reader mode contentMichael Catanzaro2021-12-151-6/+15
| | | | | | | This is necessary to prevent web content from escaping its intended context. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* reader-handler: fix style errorMichael Catanzaro2021-12-151-2/+1
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* view-source-handler: encode data passed to highlight.jsMichael Catanzaro2021-12-151-5/+13
| | | | | | | | | | | | The actual data here should be good already because it gets escaped by GLib, but this function is really designed for use in XML, so let's switch to the simpler Epiphany function designed for anti-XSS to make it more clear what's going on here. The URL is probably vulnerable, though, since a malicious URL could conceivably try to escape the HTML entity context. Encode that. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* pdf-handler: properly encode filename before inserting to HTMLMichael Catanzaro2021-12-151-6/+8
| | | | | | | | | | | The file's name is suggested by the server, and could be malicious. We don't want it to be able to escape the HTML attribute context. The file data should already be safe because it is base-64 encoded. Here I'm just adjusting the code style to match what I've done for the filename. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* pdf-handler: fix a leakMichael Catanzaro2021-12-151-1/+1
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* about-handler: properly encode web app info in about:applicationsMichael Catanzaro2021-12-151-2/+20
| | | | | | | | The web app has some partial control over its title, and full control over its URL. Let's be careful here to ensure the web app info cannot be used to execute code. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* about-handler: properly encode page title/URL in about:overviewMichael Catanzaro2021-12-151-4/+8
| | | | | | | | | | Otherwise, web pages can execute code in about:overview via a malicious page title. It might be possible to do the same via the URL, so better encode that too. Fixes #1612 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* Detect Snap sandbox in addition to FlatpakPhaedrus Leeds2021-12-092-3/+3
| | | | | | | | | | | | Snaps use the same portals as Flatpak, so we should detect whether we're running as a Snap when deciding whether to use portals or disable features that are impossible in these different but similar sandboxing technologies. This is mostly academic because the Snap of Epiphany appears to be outdated, but it is more correct so let's do it. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1041>
* web-view: Fix a leak in open_response_cb()Alexander Mikhaylenko2021-12-021-1/+1
| | | | | | | webkit_file_chooser_request_select_files() is transfer none, we still need to free the array. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1038>
* nautilus-floating-bar: Trim downAlexander Mikhaylenko2021-12-021-1/+1
| | | | | | | | It can do things such as show a spinner, a secondary label or actions. Remove all of that, only leave what we actually use. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1038>
* Unify gtk_box_pack_*() argumentsAlexander Mikhaylenko2021-12-022-10/+11
| | | | | | | | | | | | | | | In GTK4 gtk_box_pack_start() is gone, replaced with gtk_box_append(). More importantly, child properties are gone and pack_start() allows to set them. With this in mind, stop using anything other than their default values: FALSE, TRUE, 0. Everything else can be done with halign, valign, hexpand, vexpand and margins. gtk_box_pack_end() is gone as well. Replace with pack_start() where possible (which involves rearranging the order in which widgets are added), and the remaining uses at this point can be replaced with gtk_box_prepend(). Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1038>
* download: Stop using gtk_dialog_run()Alexander Mikhaylenko2021-12-011-17/+44
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1035>
* Stop referencing style class constantsAlexander Mikhaylenko2021-12-013-5/+3
| | | | | | They are gone in GTK4. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1035>
* find-toolbar: Don't set raised style classAlexander Mikhaylenko2021-12-011-2/+0
| | | | | | This looks like legacy, not sure what it was even used for. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1035>
* find-toolbar: Remove a redundant show_all() callAlexander Mikhaylenko2021-11-291-1/+0
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1034>
* find-toolbar: Stop setting max-size on the entryAlexander Mikhaylenko2021-11-291-1/+0
| | | | | | It's already in a clamp. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1034>
* find-toolbar: Remove a useless size groupAlexander Mikhaylenko2021-11-291-8/+0
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1034>
* find-toolbar: Don't subclass HdySearchBarAlexander Mikhaylenko2021-11-294-12/+17
| | | | | | GtkSearchBar won't be derivable in GTK4. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1034>
* embed: Inline EphyEmbedEventAlexander Mikhaylenko2021-11-293-220/+0
| | | | | | | | | | | It was probably more useful when it was written, but by now it's a thin wrapper around WebKitHitTestResult that proxies everything to it and doesn't do much else. Also contains a GdkEvent and proxies its fields but it's unused. So just inline it instead. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1034>
* embed: Use New Tab title for overview as wellAlexander Mikhaylenko2021-11-244-10/+6
| | | | This indicates that it's a new tab better than Most Visited.
* Stop using about:blank for new tabsAlexander Mikhaylenko2021-11-246-1/+40
| | | | | | | | | | about:blank is still white even when the app is using dark style. Go with the same approach as Safari and introduce a new page for new tab instead: about:newtab. As a bonus, we can give it a proper title instead of "blank page". Fixes https://gitlab.gnome.org/GNOME/epiphany/-/issues/1555
* Follow the system dark preference for reader modeAlexander Mikhaylenko2021-11-212-12/+34
| | | | | | | | | | | When it's available, hide the reader color scheme preference and follow the system. Change the setting description to reflect this. Fixes https://gitlab.gnome.org/GNOME/epiphany/-/issues/1546 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1029>
* Display PDFs from non-HTTP/HTTPS protocolsMichael Catanzaro2021-10-241-1/+1
| | | | | | | | | | | We forced PDFs loaded via POST requests to become downloads to solve issue #1505, but forgot that PDFs can also be opened via other URI schemes. We shouldn't crash in this case. These can safely be loaded via PDF.js. Fixes #1611 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1023>
* Fix some user content and user scripts leaksMichael Catanzaro2021-10-151-3/+3
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1020>
* error: Make error pages work in darkAlexander Mikhaylenko2021-10-061-1/+1
| | | | | | | | | | | | | | Same as the last commit, and a few more adjustments. Recoloring icons is easy when they are monochrome. Unfortunately, here we have red icons. So here we have to use complex and fragile filters, assume the source icon is #cc0000 and carefully manipulate it to get the precise color we want. We also have to move the style class for it to work. While it could be both on the icon and the title, it's easier to add it to the parent instead. Fix the details expander.
* Use username when retrieving passwords from password managerMichael Catanzaro2021-09-211-0/+2
| | | | | | | | | | | | Looking up passwords is a two-step process: * Look up available usernames for the domain * Look up passwords for the username (for the domain) Currently if there is exactly one available username, we throw it away rather than passing it along. Oops! Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1014>
View Lorry Controller Status