summaryrefslogtreecommitdiff
path: root/embed
Commit message (Collapse)AuthorAgeFilesLines
* ephy-embed-shell: make history read-only in incognito modeClaudio Saavedra2014-10-171-1/+2
| | | | | Whatever is searched in a incognito session shouldn't go to the history, not even if this will be deleted afterwards.
* ephy-web-view: Fix potential crashersBastien Nocera2014-09-111-10/+6
| | | | | | | | | | | | | | | | | | | | | | The "form-auth-data-save-requested" signal was not properly disconnected as the g_signal_handlers_disconnect_by_func() was using the wrong object. The "allow-tls-certificate" signal was not disconnected at all. The "notify::favicon" was needlessly disconnected (it will be disconnected when the web view disappears). And the "cleared" signal for the history service was never disconnected. g_signal_connect_object() should ensure that all the signals we connect to that have the web view as data are disconnected when the web view is destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=735706 Conflicts: embed/ephy-web-view.c
* Don't accidentally delete adblock filtersMichael Catanzaro2014-09-071-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The uri-tester is created from the web extension. When created, it opens ~/.config/epiphany/adblock/filters.list for reading in uri_tester_load_filters(), then calls uri_tester_set_filters() with the read filters. uri_tester_set_filters() unconditionally calls uri_tester_save_filters(), so we immediately write back what we read to filters.list. But this is racy: if you are starting multiple web processes at the same time, such as when opening epiphany with multiple saved tabs, then one process may open the file for reading after another has opened it for writing (which clears the file) but before the filters have been written back to the file, so now one UriTester instance has an empty list of filters, and it will immediately write back that empty list. The original list is completely doomed because the only time we ever write to filters.list is immediately after the filters are read, since we do not support modifying filters. That's right, these writes are NEVER necessary, so let's just remove them completely so we can be completely sure the problem is gone. Now we have an ununsued uri_tester_save_filters() function, but I don't want to get rid of it quite yet as I do want to support at least a couple different types of filters in the future (for tracking protection). Also, there are already other unused functions here as well, so one more is no difference for now, but refactor is imminent. https://bugzilla.gnome.org/show_bug.cgi?id=697329
* Revert "Fix a couple more uses of HTTP DuckDuckGo"Michael Catanzaro2014-08-231-1/+1
| | | | | | This reverts commit a47608b090e5cd7700820dc9be0674df3c1e8644. String freeze...
* Fix a couple more uses of HTTP DuckDuckGoMichael Catanzaro2014-08-221-1/+1
|
* Add sanity check warning for finding extensionsGustavo Noronha Silva2014-07-101-0/+3
| | | | | | That will help debugging future issues with extensions not being found. https://bugzilla.gnome.org/show_bug.cgi?id=727139
* Wait for name acquisition before we register and emit notificationsGustavo Noronha Silva2014-07-101-5/+6
| | | | | | | | The UI side relies on having the name of the owner to find the extension on its linked list. If we start emiting signals before that has been acquired, we will miss page created signals. https://bugzilla.gnome.org/show_bug.cgi?id=727139
* uri-tester: Use gio async API to parse the patterns fileCarlos Garcia Campos2014-06-121-17/+56
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=730129
* uri-tester: don't pass strings around just to free them laterMarco Barisione2014-05-211-31/+27
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=730129
* uri-tester: don't recompile the regexes every time they are usedMarco Barisione2014-05-211-9/+32
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=730129
* uri-tester: don't use regular expressions for trivial checksMarco Barisione2014-05-211-2/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=730129
* ephy-web-view: do not clear typed address on first loadClaudio Saavedra2014-05-121-1/+7
| | | | | | | | | | | | | | | | | | | Previously, the first page loaded in a webview would be done with before the user had any chance to type an address, so it was safe to assume that any typed address could be cleared during page loads, as they would always come from previously loaded pages. Now that the process of creating a webview is different and involves spawning a web process that needs to be ready before the initial page can be loaded, it might be possible for users to type an address before this is ready. This breaks the previous assumption and needs to be dealt with, in order to avoid cleaning up typed text during the initial page load. Additionally, it makes sense to make set_address() a no-op if the given address is the same as the currently loaded. https://bugzilla.gnome.org/show_bug.cgi?id=728143
* embed: Fix crash with some password formsBastien Nocera2014-04-141-1/+2
| | | | | | | | 31bc1fe6 transformed a simple escape hatch of a comparison into an assertion. But that assertion keeps getting triggered, so it's clearly the wrong option for now. https://bugzilla.gnome.org/show_bug.cgi?id=723909
* embed: Add debug when a web page is blockedBastien Nocera2014-04-141-1/+6
| | | | | | Should help with fixing bugs in an overzealous AdBlock. https://bugzilla.gnome.org/show_bug.cgi?id=726883
* Add title parameter to ephy_shell_new_tab_full to create tabs with an ↵Carlos Garcia Campos2014-03-101-2/+6
| | | | | | | | | | initial title And use it from ephy-session so that when loading the session and not using delayed requests, you don't see all the tabs initially with "Blank Page" title. https://bugzilla.gnome.org/show_bug.cgi?id=725649
* ephy-web-view: Move embed-title property to EphyEmbedCarlos Garcia Campos2014-03-104-75/+81
| | | | | | | Since it's the embed title what it represents. The web view already has a title property inherited from WebKitWebView. https://bugzilla.gnome.org/show_bug.cgi?id=725649
* ephy-web-view: Move get_title_from_address to ephy-embed-utilsCarlos Garcia Campos2014-03-103-15/+17
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=725649
* ephy-web-view: Remove status_message memberCarlos Garcia Campos2014-03-101-15/+9
| | | | | | | The status message is actually a combination of the loading message and link message, and both are already members. https://bugzilla.gnome.org/show_bug.cgi?id=725649
* ephy-web-view: Rename set_loading_title as set_loading_messageCarlos Garcia Campos2014-03-103-58/+35
| | | | | | | | This is no longer used to set a loading title, since it's always called with a URL or NULL. Also make it static since it's only used by ephy-web-view.c. Remove the public getter since it's unused too. https://bugzilla.gnome.org/show_bug.cgi?id=725649
* ephy-web-view: Remove ephy_web_view_get_title_composite()Carlos Garcia Campos2014-03-102-36/+0
| | | | | | | | | This is currently only used to set the window title and it's not actually needed, since we don't show Loading string in title anymore, only in the status bar. This is consistent with the title box and tabs title. https://bugzilla.gnome.org/show_bug.cgi?id=725649
* overview: fix issues on the layout CSSLorenzo Tilve2014-03-051-1/+1
| | | | | | | - fix regresion that broke CSS animation when removing items - avoid user agent ul padding to affect grid centering https://bugzilla.gnome.org/show_bug.cgi?id=724652
* Fix the build with new WebKitCarlos Garcia Campos2014-03-037-8/+37
| | | | | | | | New WebKit aborts the compilation if webkit2.h and webkit-web-extension.h headers are included together. We are including the ephy-web-extension.h header from the UI process only to get the names of the dbus service, interface and path, so move those defines to its own file that can be included by both UI and web process files.
* overview: Remove the overview model from the UI processCarlos Garcia Campos2014-03-037-170/+230
| | | | | | | | | Now we query the history and snapshot services directly and the model is used only in the web process. This fixes a race condition when the overview page is created before the history query has completed leaving an empty overview. https://bugzilla.gnome.org/show_bug.cgi?id=725393
* Revert "embed-utils: Invert the logic of condition in ↵Carlos Garcia Campos2014-03-031-9/+9
| | | | | | ephy_embed_utils_address_has_web_scheme" This reverts commit 8f441f2aa17bb2597753a44bb6d20cba24f71308.
* embed-utils: Move ephy_web_view_normalize_or_autosearch_url to embed-utilsCarlos Garcia Campos2014-03-034-87/+30
| | | | | | And use it only for actually typed (or pasted) text. https://bugzilla.gnome.org/show_bug.cgi?id=725081
* embed-utils: do not try to prepend http:// to normalize a URL if it already ↵Carlos Garcia Campos2014-03-031-32/+24
| | | | | | has a web scheme https://bugzilla.gnome.org/show_bug.cgi?id=725081
* embed-utils: Add ephy_embed_utils_address_is_validCarlos Garcia Campos2014-03-034-57/+96
| | | | | | | | | | Helper method used to check if a url is valid to decide whether to load it or perform a search. It's mostly the same expression used by EphyWebView, but moved to a helper function. The regular expressions used in that expression are also moved to embed-utils and they are only compiled once instead of everytime a web view is created. https://bugzilla.gnome.org/show_bug.cgi?id=725081
* embed-utils: Invert the logic of condition in ↵Carlos Garcia Campos2014-03-031-9/+9
| | | | | | | | ephy_embed_utils_address_has_web_scheme So that we don't need to do all the string comparisons always. https://bugzilla.gnome.org/show_bug.cgi?id=725081
* embed: Remove ephy_embed_prefs_init/shutdown methodsCarlos Garcia Campos2014-02-283-13/+8
| | | | | Create the WebKitWebViewGroup object on demand when the first web view is created.
* embed: actually hide the progress bar for about: urisClaudio Saavedra2014-02-281-1/+3
| | | | | If the progressbar was already visible, we'd never really hide it. Do it now.
* Override the default background color on about:epiphanyLorenzo Tilve2014-02-271-1/+1
| | | | | | | Use the original background color on about:epiphany to fill all the page background. https://bugzilla.gnome.org/show_bug.cgi?id=725245
* overview: adding a new thumbnail after removing another oneLorenzo Tilve2014-02-251-37/+56
| | | | | | | | When the user removes an element, all instances of the overview query the history service to be updated and insert the next corresponding item. https://bugzilla.gnome.org/show_bug.cgi?id=724697
* overview: Remove the default-icon property of EphyOverviewStoreCarlos Garcia Campos2014-02-211-23/+0
| | | | | The default icon is now set in the css of the overview and it doesn't need to be saved in the store.
* about-handler: Compile the about css file as a gresourceCarlos Garcia Campos2014-02-211-57/+35
| | | | | | | And use a link to the resource in the about pages instead of including the file contents in the about page. https://bugzilla.gnome.org/show_bug.cgi?id=724862
* overview: Compile the missing thumbnail icon as a gresourceCarlos Garcia Campos2014-02-211-12/+0
| | | | | | And use it directly form the css using ephy-resource URI. https://bugzilla.gnome.org/show_bug.cgi?id=724862
* about-handler: Use ephy-resource for the incognito icon in about:incognitoCarlos Garcia Campos2014-02-211-17/+1
| | | | | | Instead of decoding the image and send it to the web process. https://bugzilla.gnome.org/show_bug.cgi?id=724862
* Add ephy-resource:// custom URI scheme implementationCarlos Garcia Campos2014-02-211-0/+30
| | | | | | | | | | | | Ideally we could use resource:// URIs since they are supported by both WebKit and libsoup, but the web process doesn't have access to the resources compiled in the UI process. And in multiprocess mode, the network process doesn't have access to the resources either. ephy-resource:// URIs are like a proxy to load gresources compiled in the UI process, the data is sent directly to the web process in single process mode or to the network process in multiprocess mode. https://bugzilla.gnome.org/show_bug.cgi?id=724862
* about-handler: Do not send encoded images to the web process in ↵Carlos Garcia Campos2014-02-211-8/+2
| | | | | | | | about:applications Pass the app icon filename instead. https://bugzilla.gnome.org/show_bug.cgi?id=724862
* about-handler: Do not send encoded images to the web process in about:webCarlos Garcia Campos2014-02-211-9/+4
| | | | | | Pass the icon filename instead. https://bugzilla.gnome.org/show_bug.cgi?id=724862
* web-extension: remove unused variablesClaudio Saavedra2014-02-192-3/+0
|
* overview: removed hard-wired thumbnail frameClaudio Saavedra2014-02-193-8/+4
|
* web-extension: Create a EphyWebExtension object and remove all the global ↵Carlos Garcia Campos2014-02-194-127/+308
| | | | variables
* web-extension: Mark EphyWEbOverview finalize method as staticCarlos Garcia Campos2014-02-191-1/+1
|
* overview: Fix a typo in the overview page titleCarlos Garcia Campos2014-02-181-1/+1
| | | | Now the title is correctly translated.
* Remove ephy_web_view_copy_back_history()Carlos Garcia Campos2014-02-182-20/+0
| | | | | It's currently unimplemented, we can bring it back eventually if we can copy the back history and it's needed.
* Notify the web extension about history changes to update the overviewCarlos Garcia Campos2014-02-189-71/+1326
| | | | | And remove the automatic refresh when an overview item is removed via javascript.
* overview: Do not send decoded snapshots to the web processCarlos Garcia Campos2014-02-184-12/+38
| | | | | Use the thumbnail path instead so that thumbnails are loaded in the web process.
* Add snapshot path to EphyOverviewStoreCarlos Garcia Campos2014-02-181-7/+1
| | | | | It stores the path were the snapshot has been saved and notifies with a signal when a new snapshot is saved in the cache.
* Remove the overview widget and use the html based one insteadCarlos Garcia Campos2014-02-188-326/+16
|
* Alternative HTML-based implementation for the overviewLorenzo Tilve2014-02-183-1/+225
| | | | | | | Provides a basic alternative HTML implementation for the overview, that can be accessed at 'about:html-overview'. https://bugzilla.gnome.org/show_bug.cgi?id=723950
View Lorry Controller Status