[Webkit-unassigned] [Bug 41413] [Qt] QtWebKit needs public API for Notifications.

Sat Jul 3 22:31:36 PDT 2010

https://bugs.webkit.org/show_bug.cgi?id=41413

maheshK <mahesh.kulkarni at nokia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mahesh.kulkarni at nokia.com

--- Comment #9 from maheshK <mahesh.kulkarni at nokia.com>  2010-07-03 22:31:36 PST ---
(In reply to comment #8)
> Simon, I tested Chromium and FIreFox's behavior of prompts for permission, and both browsers show only the origin when they prompt the user for permission, regardless of what kind of permission they need (GeoLocation, appcache, notifications and so on). 
> 
> The biggest problem I see with passing QWebFrame in the API is the following test that I did using Chromium browser:
> 
> 1) Load this page:
> 
> <html>
> <script>
> function remove() {
> document.getElementById("par").innerHTML="Do not crash";
> }
> </script>
> Click this button to remove the iframe <button onclick="remove();">click me</button><br>
> <div id="par"><iframe src="http://slides.html5rocks.com/#slide12" width=800 height=800></iframe></div>
> </html>
> 
> 2) click on "Set notification premissions ..."
> 3) click on "click me".
> 
> With the proposed change, the client is now left withwith a deleted QWebFrame .

I think we would need one more api something like, QwebPage::cancelRequestForPermission() so that client can discard any UI pending for user request. 

Incase of geolocation, ChromeClient::cancelGeolocationPermissionRequestForFrame is triggered on disconnectFrame(). This still needs to be redirected to client. 

We would still end up with deleted QwebFrame client in above case until cancel request arrives and handled from client side itself

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.