summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* output-encoding: fix build with older GLibgnome-3-38Michael Catanzaro2022-02-081-0/+43
|
* output-encoding: remove JS encoding functionMichael Catanzaro2021-12-202-17/+7
| | | | | | This is no longer required after #1665. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1050>
* 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-46/+100
| | | | | | | | | | | 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
* Revert "Disable reader mode"Michael Catanzaro2021-12-161-4/+0
| | | | This reverts commit ee245c436bb640d1c2547c57d57ace1bdac98a81.
* Revert "Disable reader mode URI scheme"Michael Catanzaro2021-12-161-2/+0
| | | | This reverts commit 29843cdbe406ead409caa6c03ab625ca983facf1.
* Disable reader mode URI schemeMichael Catanzaro2021-12-161-0/+2
| | | | It is unsafe and not going to be fixed for GNOME 3.38
* Disable reader modeMichael Catanzaro2021-12-161-0/+4
| | | | It is unsafe, and too hard to fix to backport to older branches
* web-view: encode data in error pagesMichael Catanzaro2021-12-161-10/+27
| | | | | | | 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-161-53/+24
| | | | Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* reader-handler: encode data when constructing reader mode contentMichael Catanzaro2021-12-161-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>
* view-source-handler: encode data passed to highlight.jsMichael Catanzaro2021-12-161-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-161-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>
* about-handler: properly encode web app info in about:applicationsMichael Catanzaro2021-12-161-3/+21
| | | | | | | | 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-161-4/+11
| | | | | | | | | | 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>
* Add secure output encoding functionsMichael Catanzaro2021-12-163-0/+113
| | | | | | | | | | If we fail to use these when required, malicious web content could XSS Epiphany's internal pages. (As you might guess, the fact that these functions don't exist already indicates that is currently possible in various places.) Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1045>
* Update Hungarian translationBalazs Ur2021-09-161-1188/+561
|
* passwords-view: fix the Clear All actionMichael Catanzaro2021-08-311-3/+7
| | | | | | | | | | | | | Apparently people don't try to delete all their passwords very often, because this has been broken for the past year and nobody noticed until now. Whatever. The dialog is no longer a GtkWindow so we just have to find the parent window instead. Fixes #1570 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/993> (cherry picked from commit c084516e271387e03033db32bbb14b647c2747fc)
* Prepare 3.38.63.38.6Michael Catanzaro2021-08-123-1/+7
|
* Only update adaptive mode state on changeJan-Michael Brummer2021-07-111-0/+7
| | | | | | | | | | Currently we update the adaptive mode state from top to bottom for every state change even when there hasn't been a change. Change it and only do it once. Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1560 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/985> (cherry picked from commit 70730e4dd17081b7b02c8a1c447d2bd935d48ca1)
* Update Portuguese translationJuliano de Souza Camargo2021-06-121-66/+71
|
* Prepare 3.38.53.38.5Michael Catanzaro2021-06-043-1/+9
|
* Disable -Werror for 3.38Michael Catanzaro2021-05-071-2/+2
|
* history-dialog: fix memory corruptionMichael Catanzaro2021-05-071-1/+1
| | | | | | | | | Since converting the history dialog from the hosts table to the URLs table, we have been using the wrong free function here. :/ Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/960> (cherry picked from commit 3ce5510238f25c8a0de2428b7b24693f78bac296)
* web-view: fix double free in has_modified_forms_cbMichael Catanzaro2021-05-071-1/+0
| | | | | | | | It's freed twice in a row in this function, oops. Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/962> (cherry picked from commit 45d2a79c91a938295145d43d8195e245a4a5f1fc)
* Updated Spanish translationDaniel Mustieles2021-05-051-6714/+6719
|
* Update Serbian translationМирослав Николић2021-05-011-176/+180
|
* Fix crash when importing bookmarks from FirefoxMichael Catanzaro2021-04-291-4/+6
| | | | | | | | | | | | The problem is the strings returned by get_firefox_profiles() are freed with g_free(), which is correct, but we are actually returning pointers into the middle of the allocated region, rather than pointers to the start of the string. Truncating a string using pointer arithmetic is a nice trick for unowned strings, but for owned strings it doesn't work. https://bugzilla.redhat.com/show_bug.cgi?id=1946648 (cherry picked from commit 7e31b93d937625602e910d7397d00cc6082a37be)
* Prepare 3.38.43.38.4Michael Catanzaro2021-04-293-1/+9
|
* window: launch URLs whenever triggered by user gestureMichael Catanzaro2021-04-281-18/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Currently we check the default app for the URI scheme and call gtk_show_uri_on_window() only if the default app is not NULL and is not Epiphany. This fails under flatpak because there we cannot check the user's default apps. It is always NULL, so we bail out and refuse to launch any app for the URL. Oops. This code was originally added to prevent us from launching Epiphany in a recursive loop if it somehow gets registered as the default handler for a scheme that it doesn't actually support, as in #1053. In this case, we should only relaunch ourselves once because the second launch will be triggered by API request, when the new instance calls webkit_web_view_load_uri(). That's not a user gesture and will avoid the recursion. This change also prevents websites from opening URLs without user intervention. Thanks to Adrian Perez for proposing this solution! Fixes #1385 Part-of: <https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/951>
* Bring back the custom CI containerMichael Catanzaro2021-04-284-8/+63
| | | | | This is based on Jan-Michael's previous work, modified to use our custom container image with scan-build as well, and to retain the eslint check.
* Run uncrustify check in parallel with other checksMichael Catanzaro2021-04-291-1/+0
| | | | | | This will speed up our CI by 1-2 minutes or thereabouts (cherry picked from commit a46d2cf28296812aa5741517629736f32c92020c)
* Add missing test dependencies to fix CIMichael Catanzaro2021-04-293-10/+12
| | | | | | See gnome-build-meta#372 (cherry picked from commit c40a2be787df03dca706b2d70450795791b556ea)
* Update Portuguese translationHugo Carvalho2021-03-301-26/+26
|
* Update Portuguese translationHugo Carvalho2021-03-291-51/+50
|
* Update French translationCharles Monzat2021-03-281-116/+121
|
* Update German translationChristian Kirbach2021-03-281-127/+132
|
* Update Italian translationGianvito Cavasoli2021-03-281-187/+130
|
* web-view: remove bad assertMichael Catanzaro2021-03-251-1/+0
| | | | | | | | | | 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 (cherry picked from commit adeb59da5ae7d177a3bb7016bc27990e851b82ee)
* Updated Czech translationMarek Černocký2021-03-231-242/+134
|
* Update Slovenian translationMatej Urbančič2021-03-221-127/+133
|
* Update Romanian translationDaniel Șerbănescu2021-03-221-170/+176
|
* Updated Lithuanian translationAurimas Černius2021-03-211-124/+129
|
* Update Turkish translationEmin Tufan Çetin2021-03-211-123/+128
|
* Update Hungarian translationBalázs Úr2021-03-201-429/+174
|
* Update Polish translationPiotr Drąg2021-03-201-127/+129
|
* Update Indonesian translationKukuh Syafaat2021-03-201-123/+128
|
* Update Brazilian Portuguese translationEnrico Nicoletto2021-03-191-179/+134
|
* Update Swedish translationAnders Jonsson2021-03-191-124/+130
|
View Lorry Controller Status