summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Prepare 3.28.63.28.6gnome-3-28Michael Catanzaro2019-09-072-1/+18
|
* web-view: don't connect to embed-shell in page-created cbMichael Catanzaro2019-09-051-18/+22
| | | | | This isn't the right place. It could lead to these signals being connected multiple times due to PSON.
* Do not trust URI during WEBKIT_LOAD_STARTEDMichael Catanzaro2019-09-051-21/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since WebKit r243434 [1][2], the web view's URI property might not be updated during WEBKIT_LOAD_STARTED. For example, when on the about:overview page, if we click on any overview thumbnail, the URI is still ephy-about:overview at this point. WebKit internally knows the URI is different, but it is hiding the change from us until WEBKIT_LOAD_COMMITTED because it doesn't know if web content is maliciously attempting to spoof the URI. The URI is now only expected to be accurate if the load was initiated by API request, e.g. webkit_web_view_load_uri(), and our code here doesn't know anything about how the load was initiated, so we'd better not check the URI here at all. There were several regressions that I never noticed until today: (1) We freeze the history here improperly, since we incorrectly think that we are loading about:overview. Then the page we load doesn't make it into history. (2) For the same reason, we don't save a new snapshot of the page for the overview, resulting in stale snapshots persisting the next time the overview is opened. (3) We set the loading message in the floating statusbar to indicate that we are loading the currently-viewed page, rather than the page that is actually being loaded. To fix this, we can just set the label to "Loading...", without displaying any URL at all, until WEBKIT_LOAD_COMMITTED is reached. These bugs only occur when the load is initiated by web content, or by user interaction with web content. Loads triggered by API request should be fine. [1] https://trac.webkit.org/changeset/243434 [2] https://bugs.webkit.org/show_bug.cgi?id=194208
* web-view: remove the previous extension weak pointer before setting a new oneCarlos Garcia Campos2019-09-031-0/+3
| | | | | | | | | Now that WebKit has PSON enabled, it's possible to have different web processes for the same web view ID. When the view swaps processes, the page created signal is emitted in the new process, and a new web extension proxy is set. This might fix https://gitlab.gnome.org/GNOME/epiphany/issues/871
* download: prepare for WebKitDownload to outlive the EphyDownloadMichael Catanzaro2019-05-271-15/+15
| | | | | | | I'm seeing occasional criticals when a WebKitDownload outlives the EphyDownload, so better protect here. (cherry picked from commit f793d533d4d9dc6eda6c5d20648721cd61859523)
* history-manager: avoid critical when deleting URLs not tracked by syncMichael Catanzaro2019-05-151-0/+6
| | | | | | | | | | Fixes #691 (cherry picked from commit 7e7aa0fbd26147bb2b0aadd1e67fb3f65d9937e6) (cherry picked from commit 7be86b8b66afa396f6c0a94ee9dd75f16f924acb) (cherry picked from commit 4ded92136d69ae119077166776b0b92770e73ddf)
* gsb-service: ref self for lifetime of update threadMichael Catanzaro2019-05-151-1/+3
| | | | | | | | | | Fixes #736 (cherry picked from commit cefc3e33cca914cdc3130e589bc855491baaf004) (cherry picked from commit 28eee99ade1cfb4fa84b50f844e0bfac3c2a4b21) (cherry picked from commit 97bc80c65f4e13be1be1446668636f0f31cbc513)
* bookmark: ensure tags sequence is always createdMichael Catanzaro2019-02-201-4/+6
| | | | | | | | | | | | | | Somehow we are getting EphyBookmarks objects deserialized without initializing the tags property. I'm not sure how this happens. It even happens for JSON corresponding to bookmarks that definitely have tags set. Anyway, ephy_bookmark_get_tags() is used as if the result is not nullable, so let's guarantee this and return an empty list instead in this case. This is a speculative fix for #612. It should fix the reported crash, but it's possible it will only uncover a subsequent crash. (cherry picked from commit 672cffa5ec652a5d5f7d98d0e0664408d58dcf8c)
* Tags with empty labels are no longer allowed in bookmarksAral Balkan2019-02-201-1/+1
|
* web-view: Handle NULL URIs in ephy_web_view_set_address()Michael Catanzaro2019-02-201-1/+1
| | | | | | This is possible if the web view has not loaded anything yet. Fixes #590
* Fix Google Search in Russian localisationAlexandr Sidorenko2019-02-201-1/+1
| | | (cherry picked from commit db1b1c60d3167064c547ba9416a821ba4be641ee)
* Create sync web context using Epiphany website data managerMichael Catanzaro2019-02-201-1/+3
| | | | | | | I was confused why ~/.local/share/webkitgtk was being created in Ephy Tech Preview, until I realized the only storage was being used for accounts.firefox.com. Let's save this data under Epiphany's proper cache and data directories.
* web-apps: fix deleting of web app desktop file symlinkCarlos Garcia Campos2018-11-271-1/+1
| | | | | We were checking that the file is a directory instead of that is a symlink.
* Prepare 3.28.53.28.5Michael Catanzaro2018-09-212-1/+12
|
* Try enabling MSEMichael Catanzaro2018-09-201-0/+1
| | | | | | This is broken and not ready to be enabled, but we think YouTube has begun to require MSE to access WebM videos. So we're left with no real choice here.
* Prepare 3.28.43.28.4Michael Catanzaro2018-09-022-1/+10
|
* embed-shell: Use more g_signal_connect_object()Michael Catanzaro2018-09-021-43/+43
| | | | | | I just hit a crash where a history service callback executes improperly after the EphyEmbedShell has been destroyed. Certainly not supposed to happen. Make sure this never happens.
* Fix a -Wmaybe-uninitialized warningMichael Catanzaro2018-09-021-1/+1
|
* Fix crash on homedepot.comMichael Catanzaro2018-09-021-1/+2
| | | | | Tracking query removal fails to consider that the URI might not have a hostname.
* Ensure the correct address is displayed in security popover during loadsMichael Catanzaro2018-08-223-7/+14
| | | | | | | | | Between LOAD_STARTED and LOAD_COMMITTED, we show the security level of the previously-loaded page, but the address of the page that is being loaded. They need to match. Track the last committed load and display its address instead. Fixes #503
* embed-shell: Don't forget to unregister all message handlersMichael Catanzaro2018-08-221-0/+2
|
* Update Catalan translationJordi Mas2018-08-031-10/+10
|
* Update Afrikaans translationPieter Schalk Schoeman2018-07-061-32/+45
|
* Fix const qualifiers warningMichael Catanzaro2018-07-011-1/+1
| | | | | | | I introduced this warning recently when fixing the memory leak that was here. (cherry picked from commit 2d166afcfc083ce650192155e6925ed4f6d79bca)
* Update Afrikaans translationPieter Schalk Schoeman2018-06-291-90/+106
|
* Fix leak in ephy_uri_to_security_originMichael Catanzaro2018-06-271-1/+2
|
* Fix leak in adblock_filter_retrieve_data_newMichael Catanzaro2018-06-241-2/+2
|
* Fix multiple leaks in ephy_uri_decodeMichael Catanzaro2018-06-241-0/+3
|
* Fix leak in ephy_user_agent_get_internalMichael Catanzaro2018-06-241-2/+5
| | | | If it returns a nonnull, zero-length string, then we leak it.
* Revert "gsb-storage: Don't hardcode Linux threat lists"Gabriel Ivașcu2018-06-133-124/+51
| | | | | | This reverts commit 3c8cd6387f85106051c9e674ee8b1e59fb40858c. Also, increment SCHEMA_VERSION in ephy-gsb-storage.c.
* uri-tester: Fix cache lookups when URI is not matchedMichael Catanzaro2018-06-131-3/+4
| | | | | | | | | | | | | This regressed in e17dc3627218aed60e2fa61486757b55dc804b6e. g_hash_table_lookup() cannot distinguish between a missing value and a NULL value. We are storing a NULL pointer (GINT_TO_POINTER (FALSE)) to indicate that the URL is not a match, so the end result is that instead of a cache hit indicating we should return FALSE, we instead get a cache miss and then have to manually determine that we need to return FALSE. This should be a performance fix only, it should not affect correctness. Fixes #37
* uri-tester: Fix urlcache memory leakMichael Catanzaro2018-06-131-1/+1
| | | | | | | | | | | | | | Something went wrong with the git history related to e17dc362, and we wound up allocating a string here that will never be freed. Whoops. Then we pass it through GPOINTER_TO_INT() even though it is really a random pointer and not going to be a meaningful integer value, and return it as a gboolean. So we have a gboolean that is neither TRUE nor FALSE, which is bad. But fortunately, it looks like it's never explicitly compared to TRUE, so there should have been no behavioral issue besides the leak. This is related to #37.
* Prepare 3.28.3.13.28.3.1Michael Catanzaro2018-06-082-1/+6
|
* Silence deprecation warnings on 3.28 branchMichael Catanzaro2018-06-085-0/+25
| | | | | I can't see serious problems due to all the warning spam. All deprecations are addressed in master already and are unfixable here.
* Fix missing symbol in 3.28.3Michael Catanzaro2018-06-081-34/+3
| | | | | | I have no idea how I managed to mess this up so badly. Fixes #33
* Prepare 3.28.33.28.3Michael Catanzaro2018-06-072-1/+9
|
* Fix password manager crash on chase.comMichael Catanzaro2018-06-033-93/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to be way more careful when converting URIs to security origins. This can fail. In this case, Chase used a valid URI javascript:void(0); for its form action, which of course does not have any hostname and therefore cannot be converted to a security origin. This is a legitimate technique in order to prevent the web browser from actually submitting the form. That doesn't even matter, because this is untrusted HTML and the website can put whatever bogus data it wants there, so we'd better be prepared to handle it. The solution is to always use the page's origin for the target origin if the form action cannot be converted to an origin. This is correct because the target origin is just used as a heuristic when detecting and filling the forms. The same problem could, in theory, exist with the actual origin of the page containing a form. It's not guaranteed that every page will have a sane URI, e.g. when pages are opened by JavaScript. So, although I don't have a test case to trigger this, we ought to be careful about this, too. In this case, there's nothing really we can do, so we should fail to create the EphyEmbedFormAuth and abort whatever we were trying to do with it. Finally, move computation of the origin and target_origin into ephy_embed_form_auth_new() in order to simplify the implementation of these EphyWebExtension functions and reduce the chances of future errors. Fixes #11 on the gnome-3-28 branch. The code is completely different in master and will need to be fixed separately there.
* Revert "Again disallow new tab action in app mode"Michael Catanzaro2018-06-012-6/+2
| | | | | | | | This reverts commit c56294dd46db69c94f8238dd47f568ca57bc51c0. Seems this has had unintended consequences. https://bugzilla.gnome.org/show_bug.cgi?id=796204
* Update Afrikaans translationPieter Schalk Schoeman2018-05-291-101/+62
|
* Add Afrikaans translationPieter Schalk Schoeman2018-05-272-0/+3421
|
* Don't offer to remember passwords when setting is disabledMichael Catanzaro2018-05-251-0/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796219
* session: Fix crash when JS opens an invalid URIMichael Catanzaro2018-05-221-1/+8
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=795740
* Prepare 3.28.2.13.28.2.1Michael Catanzaro2018-05-222-1/+6
|
* Disable safe browsing testMichael Catanzaro2018-05-221-8/+9
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796324
* Prepare 3.28.23.28.2Michael Catanzaro2018-05-212-1/+8
|
* Add migrator to remove annoyance filtersMichael Catanzaro2018-05-212-2/+26
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796245
* Revert "Add social media and annoyance blocking by default"Michael Catanzaro2018-05-213-11/+4
| | | | | | | | This reverts commit 8edafec78cbb99eef99fe7fc7b1dfdf021bbfe23. It's breaking a bunch of websites. This fixes a lot of bugs. https://bugzilla.gnome.org/show_bug.cgi?id=796245
* sync-service: Fix crash when signing out before the initial sync startsGabriel Ivascu2018-05-151-3/+4
|
* sync-service: Fix crash when signing out while syncingGabriel Ivascu2018-05-151-4/+29
| | | | | | | | When the user signs out, all sync secrets including the crypto-keys are deleted. If the sign out happens while syncing, i.e. while retrieving the sync records from the server, and the server request callback is called after the sign out, the sync service will try to access the crypto-keys that no longer exist.
* Again disallow new tab action in app modeMichael Catanzaro2018-04-262-2/+6
| | | | | | Tabs still work, but only when opening a link https://bugzilla.gnome.org/show_bug.cgi?id=795007
View Lorry Controller Status