Add support for the notification API

[GoogleCodeExporter]

The notification API is not currently supported. In order to add support:

1. Set enableNotifications(true) in browser_webkit_init.h
2. Provide an implementation of WebKit::WebNotificationPresenter similar to 
notification_presenter[.h|.cc] in test_shell.
3. Return that implementation from 
BrowserWebViewDelegate::notificationPresenter().

Original issue reported on code.google.com by magreenb...@gmail.com on 24 Jan 2011 at 9:10

[GoogleCodeExporter]

Original comment by magreenb...@gmail.com on 28 Jan 2011 at 6:24

[GoogleCodeExporter]

Marshal - 

Here is a path to implement the notifications.  (We needed this for a project 
that makes external notification windows.)
I made 3 more callbacks in handler:
  HandleBeforeNotification
  HandleNotificationPermissionRequest
and
  HandleNotificationDisplay

I added a simple test implementation to cefclient.cpp and cefclient_win.cpp.  
(One developer is porting the test to the Mac.  He is working on the resource 
loading.  We hope to have that in a couple of days.)

The test is on the bottom of the "tests" menu.  In cefclient to keep from 
making new UI, I added some JavaScript functions, an used a confirm dialog for 
the test for the prompt dialog.   (This is not the way to implement a real 
notification prompt, but it gave a  cross platform test without any new UI.)
For the notifications it makes little popup browser windows, and it does not 
try to position them.  (Again OK for quick testing, but not what is wanted for 
real notifications.)

Unrelated changes.  One of our developers was worried about the #if 
defined(_win32), so I added
 #include "build/build_config.h"
into cef.h, and changed the related conditional includes.  (Let me know if that 
causes any problem.)

    - Sincerely   Russell Richards

Original comment by Fe3...@gmail.com on 1 Mar 2011 at 8:34

Attachments:

• cef_WebkitNotificationsWithCrossPlatFixes.patch
• Notification.png

[GoogleCodeExporter]

Hi Russell,

Thanks for the patch. I've attached a version updated to CEF revision 195. A 
few comments:

1. A CefBrowser reference is being leaked after displaying the notifications 
test in cefclient (hitting the ASSERT at libcef_dll:64 on exit).

2. In notification_impl.cc its probably not safe to access the 
WebKit::WebNotification instance on threads other than the UI thread. Is there 
a valid use case for keeping a reference to a CefNotification object outside 
the callback scope? In not, we should invalidate the CefNotification object 
after executing the callback. Look at the CefDOM*Impl classes for an example of 
how to implement this.

3. cef_handler_NotificationDisplayType_t should be called something like 
cef_handler_notification_type_t for naming consistency.

4. I wonder if it's necessary to have three separate notification callbacks. It 
seems that returning false from BrowserNotificationPresenter::show() would 
suffice to indicate that notifications are disabled or that a specific 
notification is disallowed/canceled. This would also eliminate the need for the 
new CefBrowser method. What do you think?

5. You can use CefParseURL instead of implementing your own URL parsing in the 
GetDomain method.

6. Be careful about coding style inconsistencies.

7. I'm OK with using Chromium's OS_* macros but we can only include 
"build/build_config.h" if we're building CEF. For client applications we need 
to provide the definitions from CEF's include directory. We do something 
similar for "base/tuple.h" from cef_runnable.h.

Original comment by magreenb...@gmail.com on 2 Mar 2011 at 1:36

Attachments:

• cef_notification_r195.patch

[GoogleCodeExporter]

Marshall - Thanks for the prompt feedback.

>> 2. In notification_impl.cc its probably not safe to access the 
WebKit::WebNotification instance on threads other than the UI thread. Is there 
a valid use case for keeping a reference to a CefNotification object outside 
the callback scope?

Yes, all of the Dispatch…Event functions must be called based on UI events 
that happen after the “Show” call (Like user click, or user close).  All of 
those have UI thread testing – see  
void CefNotificationImpl::DispatchDisplayEvent()

>>4. I wonder if it's necessary to have three separate notification callbacks. 
It seems that returning false from BrowserNotificationPresenter::show() would 
suffice to indicate that notifications are disabled or that a specific 
notification is disallowed/canceled. This would also eliminate the need for the 
new CefBrowser method. What do you think?

Unfortunately the checkPermission call on the NotificationPresenter does not 
supply a WebKit::WebNotification.  So the check in HandleBeforeNotification 
needs to happen before HandleNotificationDisplay.

Also a checkPermission that returns PermissionNotAllowed does not automatically 
prompt the user, so I can't combine HandleBeforeNotification, and 
HandleNotificationPermissionRequest; because the 
HandleNotificationPermissionRequest may never happen.  The checkPermission  
result goes back to the web page, and then the web page can call 
window.webkitNotifications.requestPermission or it can give up.

CefHandler::HandleNotificationPermissionRequest should really start 
non-blocking UI, that will call 
CefBrowser::NotificationPermissionRequestComplete when the user clicks on 
button to allow the web page.
The user should to be allowed to keep using the web page without responding to 
the notification request prompt.  (I'll change the test to non-blocking.)

>>7. I'm OK with using Chromium's OS_* macros but we can only include 
"build/build_config.h" if we're building CEF. For client applications we need 
to provide the definitions from CEF's include directory. We do something 
similar for "base/tuple.h" from cef_runnable.h.

I'll take that back out, we will bring "build/build_config.h" into one of our 
project specific files.

I'll move up to 195, correct the other things and send you a new patch soon.  
Thanks!  (A reference leak – embarrassing; I get right on that.) 

Original comment by Fe3...@gmail.com on 2 Mar 2011 at 3:57

[GoogleCodeExporter]

>>1. A CefBrowser reference is being leaked after displaying the notifications 
test in cefclient (hitting the ASSERT at libcef_dll:64 on exit).

I took the CefBrowser reference out of the ClientV8NotificationHandler. The 
CefBrowser releases now.

>> 2. In notification_impl.cc its probably not safe to access the 
WebKit::WebNotification instance on threads other than the UI thread. Is there 
a valid use case for keeping a reference to a CefNotification object outside 
the callback scope? In not, we should invalidate the CefNotification object 
after executing the callback. Look at the CefDOM*Impl classes for an example of 
how to implement this.

The CefNotification (and their underlying WebKit::WebNotification) are needed 
for the Dispatch…Events.  WebKit handles this in its own odd way, and I got 
that wrong last time.  

The BrowserNotificationPresenter::objectDestroyed will be called by WebKit 
before the object is released.  BrowserNotificationPresenter::objectDestroyed 
now calls CefNotificationImpl::WebkitObjectDestroying in that I make sure that 
the WebKit::WebNotification.reset is called.

>>3. cef_handler_NotificationDisplayType_t should be called something like 
cef_handler_notification_type_t for naming consistency.

corrected

>>5. You can use CefParseURL instead of implementing your own URL parsing in 
the GetDomain method.

Yes, I removed GetDomain.   (Do you have function to Escape parameter strings, 
or Entitize text for markup?  I didn’t find that, so I left those functions.)

>>6. Be careful about coding style inconsistencies.

Line ends?  I found a couple of files with the wrong line ending.  Corrected.  

>>7. … "build/build_config.h" 
I reverted that.  We will add "build/build_config.h" into our own project.

#2 was the big thing.  I added in a map to tie each WebNotificationPrivate to 
one and only one CefNotificationImpl. The map is used to find the matching 
CefNotificationImpl and call the reset() method of the WebKit::WebNotification.

Original comment by Fe3...@gmail.com on 3 Mar 2011 at 8:39

Attachments:

• cef_WebkitNotificationsWithCrossPlatFixes2.patch
• Notification.png

[GoogleCodeExporter]

cefclient.rc was mergec incorrectly in the patch I removed.  Here is a 
corrected patch.

Original comment by Fe3...@gmail.com on 3 Mar 2011 at 9:39

Attachments:

• cef_WebkitNotificationsWithCrossPlatFixes2.patch

[GoogleCodeExporter]

When checking the callbacks, see the way the WebKit tester handles it with the 
PostTask to DeferredDisplayDispatch, in the WebKit::WebNotificationPresenter in 
test_shell.  (That is a case where they have to hang onto the WebNotification& 
past the end of "show".

Original comment by Fe3...@gmail.com on 7 Mar 2011 at 9:42

[GoogleCodeExporter]

Caught a crash today.  Some of the CefNotificationImpl assign a CefString from 
a WebKit::WebCString.  In those cases it must check to see of the WebCString is 
!isEmpty.

Assigning form .data() of an WebCString results in the use of an uninitialized 
pointer.
Corrected the use of WebCString in notification_impl.cc

Original comment by Fe3...@gmail.com on 7 Mar 2011 at 10:48

Attachments:

• cef_WebkitNotificationsV2.patch

[GoogleCodeExporter]

Some comments based on the most recent patch file:

1. The WebKit::WebNotification object associated with CefNotificationImpl needs 
to always be accessed and deleted on the UI thread. See the V8 or DOM classes 
for an examples of how to enforce this.

2. Use base::LazyInstance instead of a static NotificationMap instance. See 
simple_clipboard_impl.cc for an example.

3. Rename HandleBeforeNotification to HandleNotificationPermissionCheck.

4. Can there be more than one WebKit::WebNotificationPermissionCallback per 
browser instance? Perhaps instead of attaching it to the CefBrowser we can 
create a CefNotificationPermissionCallback object and pass it as an argument to 
HandleNorificationPermissionRequest.

5. You're clearing the PermissionRequest when the page is reloaded. What about 
existing CefNotification objects? If they're not still valid then we need to 
clear/detach all notification-related objects on reload.

Original comment by magreenb...@gmail.com on 8 Mar 2011 at 9:50

[GoogleCodeExporter]

Ignore #5, I see that it's happening with WebkitObjectDestroying.

Original comment by magreenb...@gmail.com on 8 Mar 2011 at 9:55

[GoogleCodeExporter]

>>4. Can there be more than one WebKit::WebNotificationPermissionCallback per 
browser instance? Perhaps instead of attaching it to the CefBrowser we can 
create a CefNotificationPermissionCallback object and pass it as an argument to 
HandleNorificationPermissionRequest.

Since the notification permission is by host, it would have to be a website 
with frames where 2 different frames request notifications, but having a 
CefNotificationPermissionCallback is more flexible anyway.  (The client's UI 
may be a window unrelated to the browser; it may be a better to have an object 
that isn't the browser.)

The problem is in WebNotificationPermissionCallback.  Its destructor is hidden, 
and there is only permissionRequestComplete(), there is nothing to call if the 
user wants to ignore the request.

I'll make the Browser hold a list of CefNotificationPermissionCallback which it 
will release on navigate like it did for the current 
WebKit::WebNotificationPermissionCallback.  This way if the user fails to show 
UI for the CefNotificationPermissionCallback it will get cleaned up at a safe 
time that will not generate a re-prompt.

(This change will take a bit.  I get right on the others.)

Original comment by Fe3...@gmail.com on 9 Mar 2011 at 3:54

[GoogleCodeExporter]

>> I'll make the Browser hold a list of CefNotificationPermissionCallback which 
it 
>> will release on navigate

It would be better to use UIT_AddFrameObject and associate the notification 
objects with the main WebFrame (WebView::mainFrame()). Objects associated with 
a WebFrame are currently cleaned up before the frame is closed (which happens 
immediately before new navigation).

Original comment by magreenb...@gmail.com on 9 Mar 2011 at 4:03

[GoogleCodeExporter]

>>It would be better to use UIT_AddFrameObject and associate the notification 
objects with the main WebFrame (WebView::mainFrame()). Objects associated with 
a WebFrame are currently cleaned up before the frame is closed (which happens 
immediately before new navigation).

Thanks - yes that is a much better way.

Original comment by Fe3...@gmail.com on 9 Mar 2011 at 5:03

[GoogleCodeExporter]

>>1. The WebKit::WebNotification object associated with CefNotificationImpl 
needs to always be accessed and deleted on the UI thread. See the V8 or DOM 
classes for an examples of how to enforce this.

I didn't use quite the same mechanism as the V8.  (I didn't want to make yet an 
other wrapper around the WebKit::WebNotification for the tracker wrapper.)  But 
I was able to convert the WebKit::WebNotification member to a 
WebKit::WebNotification*, and then delete it this way:
void UIT_DeleteNotification( WebKit::WebNotification* pNotification )
{
  // Note the WebKit::WebNotification destructor calls reset()
  delete pNotification; 
}
...
  if ( notification_ ) {
    if (CefThread::CurrentlyOn(CefThread::UI)) {
      UIT_DeleteNotification(notification_);
    } else {
      CefThread::PostTask(CefThread::UI, FROM_HERE, NewRunnableFunction(
        UIT_DeleteNotification, notification_));
    }
    notification_ = NULL;

>> 2. Use base::LazyInstance instead of a static NotificationMap instance. See 
simple_clipboard_impl.cc for an example.

Converted.  And the change in #1 let me convert the map from using 
WebKit::WebNotification objects and object copying to using 
WebKit::WebNotification*

>>3. Rename HandleBeforeNotification to HandleNotificationPermissionCheck.
Changed.

>>4. Can there be more than one WebKit::WebNotificationPermissionCallback per 
browser instance? Perhaps instead of attaching it to the CefBrowser we can 
create a CefNotificationPermissionCallback object and pass it as an argument to 
HandleNorificationPermissionRequest.

Changed, but the "Notifications" test is just using a global for the 
CefNotificationPermissionCallback, with each new request, the test page would 
ignore the previous request, and prompt only for only the most recent one.

Original comment by Fe3...@gmail.com on 10 Mar 2011 at 9:36

Attachments:

• cef_WebkitNotificationsV3.patch
• Notification.png

[GoogleCodeExporter]

>>4.
>>Changed, but the "Notifications" test is just using a global for the 
CefNotificationPermissionCallback, with each new request, the test page would 
ignore the previous request, and prompt only for only the most recent one.

I made that sound like a bug.  Really it is just a limit in the tester UI, 
which only supports one NotificationPermissionCheck UI display at a time.  The 
CEF library has no such limit.  

But even the UI test can be used on a page that does 2 permission checks.  
First answer the one that shows in the UI, then refresh the page.  The 
remaining permission check should then appear.

Original comment by Fe3...@gmail.com on 16 Mar 2011 at 1:21

[GoogleCodeExporter]

From comment #9 and #10
>>>5. You're clearing the PermissionRequest when the page is reloaded. What 
about existing CefNotification objects? If they're not still valid then we need 
to clear/detach all notification-related objects on reload.

>>Ignore #5, I see that it's happening with WebkitObjectDestroying.

Well, it turns out that the BrowserNotificationPresenter::objectDestroyed isn't 
called when the script context is released.  So I had to add in the 
UIT_AddFrameObject / Tracker, to release the WebKit::WebNotification* when the 
page navigated away.

(The tester closes the notifications when the page navigated, I ran into this 
issue in my App, which wants to leave the notification windows open.)

Original comment by Fe3...@gmail.com on 25 Mar 2011 at 8:56

Attachments:

• cef_WebkitNotificationsV4.patch
• Notification.png

[GoogleCodeExporter]

This updates the patch cef_webkitNotificationsV4 to Cef rev. 212.
  1) We now have CloseBrowser, so I replaced the 
m_Browser->GetMainFrame()->ExecuteJavaScript( "window.close()" ...
  2) The std::list of ClientNotificationHandler was giving an error in debug mode when the last item was deleted (.erase).  I removed the std::list, there is now a simple single linked list of ClientNotificationHandler off of m_NotificationHandlerHead
  3) Some corrections to the testing web page "notifications.html"

Original comment by Fe3...@gmail.com on 29 Mar 2011 at 8:34

Attachments:

• cef_WebkitNotificationsV4_updated.patch
• Notification.png

[GoogleCodeExporter]

1) Updated to Cef 218.
2) 2 Mac string fixes.  (Uses the CefString constructor instead of assignment 
when wchar_t is not 16 bits.)  - I now have a Mac to build on too.

Original comment by Fe3...@gmail.com on 15 Apr 2011 at 9:10

Attachments:

• cef_WebkitNotificationsV5.patch

[GoogleCodeExporter]

Thanks for keeping the patch up to date. I'm planning to land this 
functionality using a new CefNotificationHandler interface after issue 218 
(which breaks CefHandler into separate interfaces) is complete.

Original comment by magreenb...@gmail.com on 18 Apr 2011 at 2:18

[GoogleCodeExporter]

>>Comment 19
Thanks for the information, yes changing it to CefNotificationHandler after 
CefHandler is split up sounds good.  (Sorry for the delay, I was out on 
vacation last week.)

Original comment by Fe3...@gmail.com on 25 Apr 2011 at 8:50

[GoogleCodeExporter]

The changes described in comment #19 have been committed as revision 235.

Original comment by magreenb...@gmail.com on 20 May 2011 at 3:17

[GoogleCodeExporter]

To be clear, revision 235 doesn't include the notification support. Can you 
update your patch to use a new CefNotificationHandler interface? Thanks.

Original comment by magreenb...@gmail.com on 20 May 2011 at 3:20

[GoogleCodeExporter]

>>Can you update your patch to use a new CefNotificationHandler interface? 
Thanks.
I will, but I may not be able to do it this week; I'll give a better estimate 
after our planning meeting this afternoon.

Original comment by Fe3...@gmail.com on 23 May 2011 at 1:31

[GoogleCodeExporter]

>>I'll give a better estimate after our planning meeting this afternoon.
Just finished this weeks planning.  We will have someone do that update this 
week.

Original comment by Fe3...@gmail.com on 23 May 2011 at 8:17

[GoogleCodeExporter]

Finally here is a patch updated to CEF rev.251.  My thanks to Alex who did most 
of the work for updating our project!

In the process of testing the patch we found a bug in 
CefNotificationImpl::Equals in the previous patch.  That is corrected this new 
patch. 

Alex divided the patch into new files, and patches to existing files.  So I 
have attached 2 patch files. (In Windows CR/LF format.)

Original comment by Fe3...@gmail.com on 7 Jun 2011 at 9:02

Attachments:

• notifications-251.20110607.01.new.patch
• notifications-251.20110607.01.upd.patch
• Notification.png

[GoogleCodeExporter]

Thanks for updating the patch. Some comments:

1. Remove CEF_NOTIFICATION and ClientV8NotificationHandler from cef.h. Put them 
in the cefclient application if necessary.

2. Change CefNotification::Equals to:
virtual bool IsSame(CefRefPtr<CefNotification> that)
to be consistent with other classes in CEF.

3. CefNotificationHandler methods should be named On*() instead of Handle*(). 
Use void return type for OnNotificationPermissionRequest() because the bool 
return value isn't used.

4. The WebNotification iconURL(), title() and body() methods all require that 
the notification is not HTML. The url() method requires that the notification 
is HTML. The interface exposed via CefNotification should be consistent with 
these requirements, meaning that the comments for these methods should state 
this requirement and the implementations in notification_impl.cc should 
DCHECK() this requirement.

5. Values like URLs, title, body, etc from WebNotification don't appear to 
change after the WebNotification object is created. Instead of requiring these 
values to be retrieved on the UI thread you should instead copy the values into 
CefNotificationImpl local members so they can be retrieved on any thread.

6. Methods in class declarations should match the ordering in the associated 
interface. The "Show()" declaration in browser_impl.h should be immediately 
after the "CloseDevTools()" declaration.

7. Remove the OLD_WAY code and fix the TODO in BrowserNotificationPresenter.

8. In client_handler.h put the notification helper methods in the protected 
section and the member variables at the end of the class declaration.

9. Implement ClientNotificationHandler like ClientPopupHandler. Put it in 
separate source files and don't extend ClientHandler.

10. "(struct _cef_notification_t*)(self)" casts in notification_cpptoc.cc 
shouldn't be necessary.

11. Remove extraneous "//" in notification_handler_cpptoc.cc lines 27 and 28.

12. The "DCHECK(self)" check is missing in client_cpptoc.cc 
client_get_notification_handler.

13. Style problems:
A. "if ( condition )" should be "if (condition)".
B. Member variables should be all lowercase with underscores (change 
|cefNotification_| to |cef_notification_|).
C. Use 2 spaces instead of tabs (notification_impl.h has tabs, perhaps other 
files as well).
D. When commands span multiple lines the 2nd line should be indented 4 spaces 
(for example browser_navigation_presenter.cc line 33).

Original comment by magreenb...@gmail.com on 8 Jun 2011 at 3:15

[GoogleCodeExporter]

Sorry this so so long, other things have been given a higher priority.  (I 
don't have much tome to look at this any more.)

>>1. Remove CEF_NOTIFICATION and ClientV8NotificationHandler from cef.h. Put 
them in the cefclient application if necessary.
Sorry, that was for out project, it should not have gone into the patch to CEF. 
 (If that is undefined I make stub 
classes in our project.)

>>2. Change CefNotification::Equals to:
>>virtual bool IsSame(CefRefPtr<CefNotification> that)
>>to be consistent with other classes in CEF.
Changed

>>3. CefNotificationHandler methods should be named On*() instead of Handle*(). 
>>Use void return type for OnNotificationPermissionRequest() because the bool 
return value isn't used.
Changed

>>4. The WebNotification iconURL(), title() and body() methods all require that 
the notification is not HTML. 
>>The url() method requires that the notification is HTML. The interface 
exposed via CefNotification should be consistent with these requirements, 
>>meaning that the comments for these methods should state this requirement and 
the implementations in notification_impl.cc should DCHECK() this requirement.
I added a DCHECK() macros.  Before the caching of the string data, WebKit was 
asserting on any access of the plain text
properties from a HTML notification, or access of URL property from a plain 
text notification.
Returning either the Body, or the URL in GetBody seems silly.  I removed that; 
now 
the user must call GetBody or GetSourceURL depending on the notification type.

>>5. Values like URLs, title, body, etc from WebNotification don't appear to 
change after the WebNotification object is created. 
>>Instead of requiring these values to be retrieved on the UI thread you should 
instead copy the values into CefNotificationImpl local members so they can be 
retrieved on any thread.
The values will change if the notification is replaced by its replaceId.
I did not want the extra string copies (my app may have hundreds of 
notifications), but returning the empty string for 
non-ui requests was not right, so I added the string caching.

>>7. Remove the OLD_WAY code and fix the TODO in BrowserNotificationPresenter.
Removed.

>>8. In client_handler.h put the notification helper methods in the protected 
section and the member variables at the end of the class declaration.
InitNotificationBinding moved, but with the separation of ClientHandler and 
ClientNotificationHandler
DropNotification is now called off the g_handler.

>>9. Implement ClientNotificationHandler like ClientPopupHandler. 
>>Put it in separate source files and don't extend ClientHandler.
Moved into its own file.  I changed ClientNotificationHandler to use the global 
g_handler where passthrough to the ClientHandler was needed.

>>10. "(struct _cef_notification_t*)(self)" casts in notification_cpptoc.cc 
shouldn't be necessary.
Const issues; CefCppToC::Get does not accept a "const struct 
_cef_notification_t" it does not know we are 
only going to only call a const function.

>>11. Remove extraneous "//" in notification_handler_cpptoc.cc lines 27 and 28.
Removed.

>>12. The "DCHECK(self)" check is missing in client_cpptoc.cc 
client_get_notification_handler.
Added.

>>13. Style problems:
>>A. "if ( condition )" should be "if (condition)".
I see the same thing with function calls.  Spaces after '(' and  before ')' 
removed.

>>B. Member variables should be all lowercase with underscores (change 
|cefNotification_| to |cef_notification_|).
cefNotification_, and the new CefNotificationImpl data caching members 
converted.

>>C. Use 2 spaces instead of tabs (notification_impl.h has tabs, perhaps other 
files as well).
I searched for \t but only replaced the ones in this patch.

>>D. When commands span multiple lines the 2nd line should be indented 4 spaces 
(for example browser_navigation_presenter.cc line 33).
Converted.
In the headers (especially cef.h) the parameters try to align relative to the 
"("  In the the headers for this patch  where the function name + 1 parameter 
was over 80 characters. I converted to the 4 space indent.

Original comment by Fe3...@gmail.com on 28 Jun 2011 at 1:34

Attachments:

• notifications-254.20110617.06.new.patch
• notifications-254.20110617.06.upd.patch
• Notification.png

[GoogleCodeExporter]

One of the other developer (Alex) found some issues:
  1) I dropped the Macintosh side of the project.
    Re-added.
  2)Splitting ClientHandler and ClientNotificationHandler broke the loading of the icon.  (Only Client handler has the resource load override.)
    Fixed.
  3)More formatting changes.
Thanks Alex!

Original comment by Fe3...@gmail.com on 3 Jul 2011 at 8:06

Attachments:

• notifications-259.20110630.09.new.patch
• notifications-259.20110630.09.upd.patch
• Notification.png

[GoogleCodeExporter]

Issue 351 has been merged into this issue.

Original comment by magreenb...@gmail.com on 26 Sep 2011 at 9:34

[GoogleCodeExporter]

Marshall, I've updated notification patch files for rev.462. Can you, please, 
take a look?

Thanks!

Original comment by azasyp...@gmail.com on 6 Jan 2012 at 8:39

Attachments:

• notifications-462.20120106.01.new.patch
• notifications-462.20120106.01.upd.patch
• notification.png

[GoogleCodeExporter]

Thanks for updating the patch!  I haven't been able to look at it for a long 
time.  (Wow has it bee 6 months?)  I'm really looking forward to upgrading to 
the current CEF and using web workers too.

Original comment by Fe3...@gmail.com on 10 Jan 2012 at 4:19

[GoogleCodeExporter]

Heads-up, I'm cleaning up this patch to the latest code style. Would be really 
nice to get this into CEF.

Original comment by gusver...@gmail.com on 20 Jan 2012 at 2:45

[GoogleCodeExporter]

Attached is an updated pair of patches to r475. 

The previous patches were updated to the changes since r462 and run through the 
check_style tool. I fixed the flagged style issues except for a few (use of 
'long', and a miss-interpretation of function pointer prototype as a function 
call in a few places.)

Thanks for taking a look.

Original comment by gusver...@gmail.com on 27 Jan 2012 at 8:04

Attachments:

• notifications-cef475.new.patch
• notifications-cef475.upd.patch

[GoogleCodeExporter]

A bit of questions, what does "USING_CEF_SHARED" means in files such as 
notification_ctocpp.h ? Where it was been defined?

Appreciate for your replay :)

Pz

Original comment by pengzuo...@gmail.com on 8 Feb 2012 at 6:18

[GoogleCodeExporter]

I’ve found it in cef.gyp, but still don't know what is the macro for ?

Original comment by pengzuo...@gmail.com on 8 Feb 2012 at 6:32

[GoogleCodeExporter]

The short story on USING_CEF_SHARED is that you need to define it if you are 
"using the shared libcef.dll". It is used in cef_export.h to set the DLL import 
declaration and also used to guard the case where you try to include a header 
meant for use from within the CEF DLL.

Original comment by gusver...@gmail.com on 8 Feb 2012 at 6:47

[GoogleCodeExporter]

Thank you for your replay, and when will the patch be applied in CEF release?

Original comment by pengzuo...@gmail.com on 9 Feb 2012 at 2:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

After applied the patches, it seems that 
http://beakkon.com/tutorial/html5/desktop-notification still can't run 
appropriately in CEF. I couldn't find the allow/deny dialog. 

Original comment by pengzuo...@gmail.com on 10 Feb 2012 at 9:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes, the patch does not build in UI for the allow/deny. You receive the event, 
then you can show your own UI, or determine if the notification should show 
some other way.  Feel free to copy UI from the notification test page in the 
patch.

Original comment by Fe3...@gmail.com on 18 Mar 2012 at 3:52

[GoogleCodeExporter]

Any chance of an updated patch that works on the latest CEF3 source? Some of 
the patched files no longer exist and without knowing their original intent 
it's not possible  for me to reliably do it myself.

Original comment by andybrow...@gmail.com on 5 Oct 2012 at 9:10

[GoogleCodeExporter]

The project Gus and I are working on, hasn't moved to CEF3 yet. I want to move 
to CEF3 soon, but for me it is at best November before I'll have time.

I'll try to do a short writeup of the patch's structure in the next week or so.

Original comment by Fe3...@gmail.com on 5 Oct 2012 at 7:41

[GoogleCodeExporter]

CEF1 has entered bug-fix-only maintenance mode. See 
http://magpcss.org/ceforum/viewtopic.php?f=10&t=10647 for details. If this 
issue applies to the current version of CEF3 please create a new issue.

Original comment by magreenb...@gmail.com on 11 Oct 2013 at 1:50

• Changed state: WontFix