RESOLVED FIXED36625
Modify NotificationPresenter::checkPermission() to pass the full source url rather than just the security origin
https://bugs.webkit.org/show_bug.cgi?id=36625
Summary Modify NotificationPresenter::checkPermission() to pass the full source url r...
Rafael Weinstein
Reported 2010-03-25 16:05:35 PDT
The chromium client needs the full URL of the requesting frame.
Attachments
Patch (6.17 KB, patch)
2010-03-25 16:13 PDT, Rafael Weinstein
no flags
Patch (8.66 KB, patch)
2010-03-25 16:47 PDT, Rafael Weinstein
no flags
Patch (8.96 KB, patch)
2010-03-25 17:01 PDT, Rafael Weinstein
no flags
Rafael Weinstein
Comment 1 2010-03-25 16:13:35 PDT
Aaron Boodman
Comment 2 2010-03-25 16:40:56 PDT
I think that you will need to fix the Windows port as well.
Rafael Weinstein
Comment 3 2010-03-25 16:47:48 PDT
Eric Seidel (no email)
Comment 4 2010-03-25 16:53:17 PDT
This is to work around a GKURL KURL difference, correct?
Rafael Weinstein
Comment 5 2010-03-25 17:01:36 PDT
Adam Barth
Comment 6 2010-03-25 17:05:10 PDT
Comment on attachment 51693 [details] Patch Ok. There might be some subtle issues if a sandboxed iframe tries to use the notification API. With this design, it might inherit the privileges of its origin. Would you be willing to file a bug about that issue and attach a test case?
Darin Fisher (:fishd, Google)
Comment 7 2010-03-26 19:55:58 PDT
(In reply to comment #4) > This is to work around a GKURL KURL difference, correct? If this is true, then can we eliminate the difference?
Darin Fisher (:fishd, Google)
Comment 8 2010-03-26 19:57:30 PDT
Comment on attachment 51693 [details] Patch > +++ b/WebKit/chromium/public/WebNotificationPresenter.h > @@ -62,7 +62,7 @@ public: > > // Checks the permission level for the given origin. > // FIXME: This should become abstract when the below is removed. > - virtual Permission checkPermission(const WebSecurityOrigin& origin) > + virtual Permission checkPermission(const WebURL& url) Doesn't this make for a two-sided commit? Can we avoid such complexity by preserving the old API in a deprecated form and then remove it via a follow-up patch?
Aaron Boodman
Comment 9 2010-03-27 10:11:29 PDT
(In reply to comment #7) > (In reply to comment #4) > > This is to work around a GKURL KURL difference, correct? > > If this is true, then can we eliminate the difference? It isn't true. Eric was getting this patch confused with something else I was talking to him about the same day. There is a difference between GURL and KURL though. See: https://bugs.webkit.org/show_bug.cgi?id=36623(In reply to comment #8) > (From update of attachment 51693 [details]) > > +++ b/WebKit/chromium/public/WebNotificationPresenter.h > > @@ -62,7 +62,7 @@ public: > > > > // Checks the permission level for the given origin. > > // FIXME: This should become abstract when the below is removed. > > - virtual Permission checkPermission(const WebSecurityOrigin& origin) > > + virtual Permission checkPermission(const WebURL& url) > > Doesn't this make for a two-sided commit? Can we avoid such complexity > by preserving the old API in a deprecated form and then remove it via > a follow-up patch? No. Note the WebSecurityOrigin signature is not used in Chromium and has a default implementation. It was a previous (aborted) attempt at this same change, and is intended to be made in three non-breaking steps. BTW, We need a name for the desired way to make webkit changes. Air-lock? Three-phase?
Darin Fisher (:fishd, Google)
Comment 10 2010-03-27 13:28:35 PDT
(In reply to comment #9) > There is a difference between GURL and KURL though. See: > > https://bugs.webkit.org/show_bug.cgi?id=36623 Ah, yes. I'm familiar with that bug. It wasn't clear to me that it related to differences between KURL and KURLGoogle. (In reply to comment #8) > No. Note the WebSecurityOrigin signature is not used in Chromium and has a > default implementation. It was a previous (aborted) attempt at this same > change, and is intended to be made in three non-breaking steps. Ah, sounds good. > BTW, We need a name for the desired way to make webkit changes. Air-lock? > Three-phase? Trifecta, Hat-trick, ... I'd vote for three-phase :)
Rafael Weinstein
Comment 11 2010-03-28 13:39:17 PDT
@abarth: I've created https://bugs.webkit.org/show_bug.cgi?id=36732 and attached a test for the sandboxing issue you identified.
WebKit Commit Bot
Comment 12 2010-03-29 18:38:10 PDT
Comment on attachment 51693 [details] Patch Clearing flags on attachment: 51693 Committed r56756: <http://trac.webkit.org/changeset/56756>
WebKit Commit Bot
Comment 13 2010-03-29 18:38:15 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.