<rdar://problem/10912432>
Created attachment 130715 [details] Patch
The patch only deprecates ondisplay() if ENABLE(LEGACY_NOTIFICATIONS) is false, but does change the tests to use onshow().
*** Bug 78144 has been marked as a duplicate of this bug. ***
Comment on attachment 130715 [details] Patch Attachment 130715 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11861111 New failing tests: fast/notifications/notifications-double-show.html fast/notifications/notifications-with-permission.html fast/notifications/notifications-display-close-events.html
Comment on attachment 130715 [details] Patch Attachment 130715 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11866111 New failing tests: fast/notifications/notifications-double-show.html fast/notifications/notifications-with-permission.html fast/notifications/notifications-display-close-events.html
Created attachment 130790 [details] Patch Attempt to fix cr bot
Created attachment 131183 [details] Patch
The current spec states that the proper name of the callback when the notification is queued or presented is onshow(), not ondisplay(): http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html
Created attachment 131738 [details] Patch
What are you going to deal with ondisplay and onshow in the test files?
(In reply to comment #10) > What are you going to deal with ondisplay and onshow in the test files? There is no support right now for notifications on the mac, so I've opted at this point to leave these tests alone. Once we add support (bug 77969), I will have to duplicate the tests using the new API (bug 81048).
(In reply to comment #11) > (In reply to comment #10) > > What are you going to deal with ondisplay and onshow in the test files? > > There is no support right now for notifications on the mac, so I've opted at this point to leave these tests alone. Once we add support (bug 77969), I will have to duplicate the tests using the new API (bug 81048). Then we will have to maintain 2 sets of tests that different port needs to choose among them. For now, I do not know if there is any better solution for this. We can come to this later.
Committed r110899: <http://trac.webkit.org/changeset/110899>