After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692943 - EphyEmbed shouldn't remove top widgets unconditionally
EphyEmbed shouldn't remove top widgets unconditionally
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: General
git master
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-01-31 14:09 UTC by Claudio Saavedra
Modified: 2018-03-30 16:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Claudio Saavedra 2013-01-31 14:09:33 UTC
It is not yet possible to reproduce this with master webkitgtk, but the use case is simple to understand. Take the following HTML fragment:

<div><a href="" onclick="askPermission()">Generate a Notification</a></div>

<script> 
    function askPermission(){
	Notification.requestPermission(foo);
    }

...

WebKit2 handles the permission through the WebKitWebView::policy-request signal. Epiphany's handler of this signal adds an infobox to the EphyEmbed so that the user can decide there whether to give permission or not. This is currently working for geolocation and soon we will be adding support for notifications as well.

The geolocation API doesn't count with a method to explicitly request for permission, as the one above. Instead, permission is requested automatically when a geolocation request is made. The Notification API, however, counts with the above method: Notification.requestPermission(). This method can be invoked by web developers at will, as in the fragment above.

The way this method is used in the above example causes the webpage to be reloaded while EphyWebView adds a top widget to its parent EphyEmbed. Right after the reload, however, EphyEmbed destroys the top widgets in a handler for the WebKitWebView::load-changed signal. The outcome is a infobox that pops up and dissapears in a fragment of a second.

I am not sure what the right way to deal with this is, but I think that one certain thing is that we can't just add an infobox and let EphyEmbed assume that these should be removed every time there is a WEBKIT_LOAD_COMMITTED load event.
Comment 1 Michael Catanzaro 2018-03-25 17:45:08 UTC
This is a mass NEEDINFO of all Epiphany bugs with no activity in the past three years. I'm going to be automatically closing old bugs to help us focus on current problems. If you feel this bug is still relevant with Epiphany 3.26 or newer, then please leave any comment here so that I know not to close this one.
Comment 2 Michael Catanzaro 2018-03-30 16:25:00 UTC
This is a mass-close of old bugs currently in the NEEDINFO state.

If you think this bug is still relevant, please leave a comment.