Closed
Bug 1224785
Opened 9 years ago
Closed 8 years ago
Show the site favicon in OS X web notifications
Categories
(Toolkit Graveyard :: Notifications and Alerts, defect)
Toolkit Graveyard
Notifications and Alerts
Tracking
(firefox47 fixed)
RESOLVED
FIXED
mozilla47
Tracking | Status | |
---|---|---|
firefox47 | --- | fixed |
People
(Reporter: lina, Assigned: lina)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
No description provided.
Assignee | ||
Comment 1•9 years ago
|
||
Bug 1224785 - Show the site favicon in OS X web notifications.
Assignee | ||
Comment 2•9 years ago
|
||
https://reviewboard.mozilla.org/r/25215/#review22715 ::: widget/cocoa/OSXNotificationCenter.mm:409 (Diff revision 1) > + nsCOMPtr<nsIFaviconDataCallback> callback = new FaviconDataCallback(this, It'd be a lot cleaner if we passed the WebIDL Notification object around, instead of all these arguments. Maybe we should do that first, then rebase this patch.
Assignee | ||
Updated•9 years ago
|
Attachment #8687507 -
Flags: feedback?(mstange)
Attachment #8687507 -
Flags: feedback?(MattN+bmo)
Comment 3•9 years ago
|
||
https://reviewboard.mozilla.org/r/25215/#review22783 Did you consider putting the favicon code in the toolkit alert service instead (passing the data to the system alert service)? ::: widget/cocoa/OSXNotificationCenter.mm:389 (Diff revision 1) > + return DisplayCocoaAlert(aImageUrl, aAlertCookie, aAlertListener, > + aPrincipal, aInPrivateBrowsing, alertName, > + notification, osxni); > + } > + > + nsCOMPtr<nsIURI> pageURI; > + if (NS_WARN_IF(NS_FAILED(aPrincipal->GetURI(getter_AddRefs(pageURI))))) { > + return DisplayCocoaAlert(aImageUrl, aAlertCookie, aAlertListener, > + aPrincipal, aInPrivateBrowsing, alertName, > + notification, osxni); > + } > + > + nsCOMPtr<mozIAsyncFavicons> asyncFavicons = do_GetService( > + "@mozilla.org/browser/favicon-service;1"); > + if (!asyncFavicons) { > + return DisplayCocoaAlert(aImageUrl, aAlertCookie, aAlertListener, > + aPrincipal, aInPrivateBrowsing, alertName, > + notification, osxni); > + } > + > + nsCOMPtr<nsIFaviconDataCallback> callback = new FaviconDataCallback(this, > + aImageUrl, aAlertCookie, aAlertListener, aPrincipal, aInPrivateBrowsing, > + alertName, notification, osxni); > + return asyncFavicons->GetFaviconDataForPage(pageURI, callback); > +#else > + // Show the notification without a favicon if the Places API is disabled. > + return DisplayCocoaAlert(aImageUrl, aAlertCookie, aAlertListener, The four calls to `DisplayCocoaAlert` in this one method make me think it should be refactored.
Comment 4•9 years ago
|
||
Comment on attachment 8687507 [details] MozReview Request: Bug 1224785, Part 1 - Implement alert favicons backend. r=wchen (In reply to Kit Cambridge [:kitcambridge] from comment #2) > https://reviewboard.mozilla.org/r/25215/#review22715 > > ::: widget/cocoa/OSXNotificationCenter.mm:409 > (Diff revision 1) > > + nsCOMPtr<nsIFaviconDataCallback> callback = new FaviconDataCallback(this, > > It'd be a lot cleaner if we passed the WebIDL Notification object around, > instead of all these arguments. Maybe we should do that first, then rebase > this patch. I think if we do this in nsAlertsService.cpp is may be less messy but I agree in general that we should see if DOM peers would support passing the WebIDL Notification object around
Attachment #8687507 -
Flags: feedback?(MattN+bmo) → feedback+
Comment 5•9 years ago
|
||
This was already filed as bug 1212589 btw…
Comment 7•9 years ago
|
||
I agree that this should be refactored. Also, you need to use an nsCOMPtr instead of a raw pointer to hold on to the nsIPrincpal and nsIObserver objects. Looking at the existing code, the memory management of the osxni objects is unclear. Are we leaking them?
Updated•9 years ago
|
Attachment #8687507 -
Flags: feedback?(mstange)
Comment 8•8 years ago
|
||
Marcos Caceres once told me that at least one part of our favicon code doesn't use the highest quality icon in the .ico archive. Are pixellated icons a concern here?
Flags: needinfo?(kcambridge)
Assignee | ||
Comment 9•8 years ago
|
||
Comment on attachment 8687507 [details] MozReview Request: Bug 1224785, Part 1 - Implement alert favicons backend. r=wchen Review request updated; see interdiff: https://reviewboard.mozilla.org/r/25215/diff/1-2/
Attachment #8687507 -
Attachment description: MozReview Request: Bug 1224785 - Show the site favicon in OS X web notifications. → MozReview Request: Bug 1224785, Part 1 - Implement alert favicons backend. r?wchen
Attachment #8687507 -
Flags: feedback+ → review?(wchen)
Assignee | ||
Comment 10•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/29949/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/29949/
Attachment #8705377 -
Flags: review?(mstange)
Assignee | ||
Comment 11•8 years ago
|
||
(In reply to Andrew Overholt [:overholt] from comment #8) > Marcos Caceres once told me that at least one part of our favicon code > doesn't use the highest quality icon in the .ico archive. Are pixellated > icons a concern here? Yes. :-/ The attached screenshot shows the pixellation. Poking around with the Browser Toolbox, I see the tab bar does `<tab image="/url/to/icon">`, which gives the highest-quality icon. I'm guessing the bookmarks toolbar loads the icon from Places, so that's why it looks pixellated. Not sure if using the `moz-anno:favicon` URL for XUL alerts will be any better. Bug 492172 seems relevant. Marcos, have you found a way to get higher-quality favicons?
Flags: needinfo?(kcambridge) → needinfo?(mcaceres)
Assignee | ||
Updated•8 years ago
|
Comment 12•8 years ago
|
||
Comment on attachment 8705377 [details] MozReview Request: Bug 1224785, Part 2 - Show the site favicon in OS X notifications. r?mstange https://reviewboard.mozilla.org/r/29949/#review27027 ::: widget/cocoa/OSXNotificationCenter.mm:221 (Diff revision 1) > -NS_IMPL_ISUPPORTS(OSXNotificationCenter, nsIAlertsService, imgINotificationObserver, nsITimerCallback) > +NS_IMPL_ISUPPORTS(OSXNotificationCenter, nsIAlertsService, imgINotificationObserver, nsITimerCallback, Might as well move nsITimerCallback into the second line, too. ::: widget/cocoa/OSXNotificationCenter.mm:375 (Diff revision 1) > + [(NSObject*)notification setValue:icon forKey:@"_identityImage"]; I think you need to release "icon" after this line. Or you could autorelease it in the line where you allocate it.
Attachment #8705377 -
Flags: review?(mstange)
Comment 13•8 years ago
|
||
(In reply to Kit Cambridge [:kitcambridge] from comment #11) > Created attachment 8705380 [details] > Screen Shot 2016-01-07 at 3.49.49 PM.png > > (In reply to Andrew Overholt [:overholt] from comment #8) > > Marcos Caceres once told me that at least one part of our favicon code > > doesn't use the highest quality icon in the .ico archive. Are pixellated > > icons a concern here? Yes but that's something that should be fixed in Places (there are many bugs on this) and then this code will get the benefits for free. I don't think we should do any special work in the alert service to get better favicons and keep a single source of truth for that in the Places Favicon service. > Yes. :-/ The attached screenshot shows the pixellation. Poking around with > the Browser Toolbox, I see the tab bar does `<tab image="/url/to/icon">`, > which gives the highest-quality icon. I'm guessing the bookmarks toolbar > loads the icon from Places, so that's why it looks pixellated. Not sure if > using the `moz-anno:favicon` URL for XUL alerts will be any better. Bug > 492172 seems relevant. Please ensure that favicon patches are doing the correct thing with multi-resolution ICO files. You can test with attachment 8465124 [details] and its image (attachment 8463655 [details]) and ensure that the image shows "32" on a 2x display and "16" on a 1x display. Our image code should do this automatically now for HTML/XUL but the Cocoa code may need help with this. :Seth can help with this.
Assignee | ||
Comment 14•8 years ago
|
||
(In reply to Matthew N. [:MattN] from comment #13) > Please ensure that favicon patches are doing the correct thing with > multi-resolution ICO files. You can test with attachment 8465124 [details] > and its image (attachment 8463655 [details]) and ensure that the image shows > "32" on a 2x display and "16" on a 1x display. Our image code should do this > automatically now for HTML/XUL but the Cocoa code may need help with this. > :Seth can help with this. It's not quite right. "32" shows up for both 1x and 2x resolution. I can call `[icon setSize:NSMakeSize(16, 16)]`, but that'll force "16" on a 2x display. I see https://dxr.mozilla.org/mozilla-central/source/widget/cocoa/nsMenuItemIconX.mm loads the image, then decodes the first frame and calls `CreateNSImageFromCGImage`. Do we need to do the same here?
Flags: needinfo?(mcaceres) → needinfo?(seth)
Comment 15•8 years ago
|
||
Comment on attachment 8687507 [details] MozReview Request: Bug 1224785, Part 1 - Implement alert favicons backend. r=wchen https://reviewboard.mozilla.org/r/25215/#review28151 ::: toolkit/components/alerts/nsIAlertsService.idl:16 (Diff revision 2) > [scriptable, uuid(9e87fc34-8dbb-4b14-a724-b27be6822ec8)] uuid
Attachment #8687507 -
Flags: review?(wchen) → review+
Comment 16•8 years ago
|
||
> Marcos, have you found a way to get higher-quality favicons?
Sorry, been away... no, I couldn't find a way.
Assignee | ||
Comment 17•8 years ago
|
||
Comment on attachment 8687507 [details] MozReview Request: Bug 1224785, Part 1 - Implement alert favicons backend. r=wchen Review request updated; see interdiff: https://reviewboard.mozilla.org/r/25215/diff/2-3/
Attachment #8687507 -
Attachment description: MozReview Request: Bug 1224785, Part 1 - Implement alert favicons backend. r?wchen → MozReview Request: Bug 1224785, Part 1 - Implement alert favicons backend. r=wchen
Assignee | ||
Comment 18•8 years ago
|
||
Comment on attachment 8705377 [details] MozReview Request: Bug 1224785, Part 2 - Show the site favicon in OS X notifications. r?mstange Review request updated; see interdiff: https://reviewboard.mozilla.org/r/29949/diff/1-2/
Attachment #8705377 -
Flags: review?(mstange)
Assignee | ||
Comment 19•8 years ago
|
||
Plan discussed with :edwong is to land this patch now, and fix the 1x resolution in a follow-up bug.
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(seth)
Assignee | ||
Comment 20•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ffd1d930eddf
Comment 21•8 years ago
|
||
Comment on attachment 8705377 [details] MozReview Request: Bug 1224785, Part 2 - Show the site favicon in OS X notifications. r?mstange https://reviewboard.mozilla.org/r/29949/#review31557
Attachment #8705377 -
Flags: review?(mstange) → review+
Comment 22•8 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/d5b329a9cd6b https://hg.mozilla.org/integration/fx-team/rev/0457ade4bd4b
Comment 24•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d5b329a9cd6b https://hg.mozilla.org/mozilla-central/rev/0457ade4bd4b https://hg.mozilla.org/mozilla-central/rev/58d7cfbf806c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox47:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Updated•10 months ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•