Closed
Bug 705516
Opened 13 years ago
Closed 13 years ago
Missing Favicons in the Application Menu Bar
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
VERIFIED
FIXED
mozilla11
People
(Reporter: mehmetxsahin, Assigned: spectre)
References
Details
(Keywords: regression, relnote, verified-beta, Whiteboard: [qa!])
Attachments
(4 files, 3 obsolete files)
84.66 KB,
image/png
|
Details | |
135.96 KB,
image/png
|
Details | |
233.27 KB,
image/png
|
Details | |
1.26 KB,
patch
|
smichaud
:
review+
akeybl
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0
Build ID: 20111122192043
Steps to reproduce:
OS: Mac OS 10.6.8
Firefox: Version 9 Beta
STR:
1. Open the Bookmarks menu in the Application menu
Actual results:
The Bookmarks have no favicons. (Even after visiting the pages.)
Expected results:
There should be favicons.
Confirmed with TenFourFox 9beta1 with Mac OS X 10.5.8.
Addtl. Information: Icons in the Bookmarks Toolbar are displayed. Placeholder icons (dotted rounded square) and folder icons are also displayed. Site icons in the Bookmarks Menu are missing.
Attachment #580396 -
Attachment description: screenshot bookmarks menu → screenshot bookmarks toolbar
Attachment #580397 -
Attachment description: screenshot bookmarks toolbar → screenshot bookmarks menu
Assignee | ||
Comment 4•13 years ago
|
||
History favicons show up, but only the second time the menu is opened.
Assignee | ||
Comment 5•13 years ago
|
||
Steven, do you have any ideas on this one? I'm suspecting something in toolkit/themes/pinstripe; I don't see any widget changes that would have caused this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•13 years ago
|
||
Off the top of my head I have no idea what could have caused this.
Someone please provide a regression range (using mozilla-central nightlies) -- that'd make it a lot easier to figure out.
(In reply to Steven Michaud from comment #6)
> Someone please provide a regression range (using mozilla-central nightlies)
> -- that'd make it a lot easier to figure out.
Checking ...
(In reply to Mehmet Sahin from comment #7)
> (In reply to Steven Michaud from comment #6)
> > Someone please provide a regression range (using mozilla-central nightlies)
> > -- that'd make it a lot easier to figure out.
>
> Checking ...
Regression range:
It works fine in 9.0a1 (2011-09-22) mozilla central
It is broken in 9.0a1 (2011-09-23) mozilla central
Hope it helps ...
Regards
Mehmet
Comment 9•13 years ago
|
||
Thanks, Mehmet!
I can reproduce this bug, but only once.
In other words, the first time a bookmarks menu is displayed, it sometimes is lacking its favicons. The second time I display it they're no longer missing.
I also think I've found the patch that triggered this problem -- the one for bug 573583, which turned on decode-on-draw by default.
Whoever can reproduce this, try again after setting image.mem.decodeondraw to false (in about:config) and restarting. I find doing this makes the problem go away.
I'd also like to know whether this bug happens on other platforms, like Windows and Linux.
Blocks: 573583
Comment 10•13 years ago
|
||
> and restarting
Quitting and restarting Firefox.
Reporter | ||
Comment 11•13 years ago
|
||
(In reply to Steven Michaud from comment #9)
> Whoever can reproduce this, try again after setting image.mem.decodeondraw
> to false (in about:config) and restarting. I find doing this makes the
> problem go away.
I can confirm that setting 'image.mem.decodeondraw' to 'false' fixes this issue.
Updated•13 years ago
|
Component: General → ImageLib
Product: Firefox → Core
QA Contact: general → imagelib
Comment 12•13 years ago
|
||
If this turns out to be Mac-specific, it should probably be moved to Core : Widget: Cocoa.
Comment 13•13 years ago
|
||
nsMenuItemIconX doesn't handle icons being discarded. It presumes that, once it's loaded, it's done, which is not the case since we enabled discarding for all images.
Instead of using mLoadedIcon, you could perhaps test whether aFrame == 0. Then, if we are called again for the first frame, we can handle that.
It's possible that something else is happening here, and i"m misunderstanding, but in any case this is almost certainly a Cocoa widget problem.
Component: ImageLib → Widget: Cocoa
QA Contact: imagelib → cocoa
Assignee | ||
Comment 14•13 years ago
|
||
Changing the pref also fixes it in TenFourFox. Is it worth a patch to disable it for -beta, or try to find a fix?
Comment 15•13 years ago
|
||
Upon further thought, I think what's happening is that we're actually not requesting a decode of these icons at all (that is what decode-on-draw means, fundamentally - don't decode unless requested). So if the image is already decoded, we're fine, but if it hasn't yet been decoded, either because it's been discarded or never displayed, we'll never get the icon.
Fixing this is pretty simple: in nsMenuItemIconX::LoadIcon(), around nsMenuItemIconX.mm:346, insert a request for the image to be decoded:
mIconRequest->RequestDecode();
If the image is already decoded, this is a no-op. Otherwise, it causes the image to be decoded.
I'm pretty certain comment 13 is wrong.
Comment 16•13 years ago
|
||
(In reply to Cameron Kaiser from comment #14)
> Changing the pref also fixes it in TenFourFox. Is it worth a patch to
> disable it for -beta, or try to find a fix?
I don't recommend disabling decode-on-draw, especially not this late. It'll be a memory regression when loading lots of pages in the background.
We've also started building the final beta of Firefox 9, so we're out of luck when it comes to Firefox. Cameron, I suspect TenFourFox will find great joy in the fix I outline in comment 15, though.
Assignee | ||
Comment 17•13 years ago
|
||
Yup, that works!
Patch for posterity since it does appear to affect Firefox too.
Attachment #581164 -
Flags: review?(smichaud)
Comment 18•13 years ago
|
||
Comment on attachment 581164 [details] [diff] [review]
request decoding of icons in Mac menu items
This is no good, and might result in crashes.
You need to move the call to RequestDecode() to just before "return NS_OK" (and just after "if (NS_FAILED(rv)) return rv;").
Attachment #581164 -
Flags: review?(smichaud) → review-
Assignee | ||
Comment 19•13 years ago
|
||
D'oh. I blame my cat.
Attachment #581164 -
Attachment is obsolete: true
Attachment #581463 -
Flags: review?(smichaud)
Comment 20•13 years ago
|
||
(In reply to comment #15)
> Upon further thought, I think what's happening is that we're
> actually not requesting a decode of these icons at all
This isn't true. RequestDecode() is called on all of these icons in
nsMenuItemIconX::OnStartContainer().
But nsMenuItemIconX::OnStartContainer() is called after
nsMenuItemIconX::LoadIcon(), and it may be that the icons won't get
decoded in time unless RequestDecode() is called (or also called) from
nsMenuItemIconX::LoadIcon().
In trying to debug this, I noticed that when the bug happens (and a
favicon doesn't get drawn), nsMenuItemIconX::OnStopFrame() (where the
actual drawing takes place) doesn't get called. Why these calls
should depend on the timing of calls to RequestDecode() I don't know,
but it appears that they do.
Joe, I suspect it's alright (and maybe even desirable) to call
RequestDecode() from both nsMenuItemIconX::LoadIcon() and
nsMenuItemIconX::OnStartContainer(). Do you have an opinion on this?
On a side note, I noticed that on no other platform (besides OS X) is
RequestDecode() called from widget code. Do you know if there was a
reason for this?
Comment 21•13 years ago
|
||
(In reply to Steven Michaud from comment #20)
> In trying to debug this, I noticed that when the bug happens (and a
> favicon doesn't get drawn), nsMenuItemIconX::OnStopFrame() (where the
> actual drawing takes place) doesn't get called. Why these calls
> should depend on the timing of calls to RequestDecode() I don't know,
> but it appears that they do.
I'd have to debug to know for sure.
> Joe, I suspect it's alright (and maybe even desirable) to call
> RequestDecode() from both nsMenuItemIconX::LoadIcon() and
> nsMenuItemIconX::OnStartContainer(). Do you have an opinion on this?
You shouldn't need a call in OnStartContainer if you have one in LoadIcon.
> On a side note, I noticed that on no other platform (besides OS X) is
> RequestDecode() called from widget code. Do you know if there was a
> reason for this?
None off the top of my head, no.
Comment 22•13 years ago
|
||
Comment on attachment 581463 [details] [diff] [review]
request decoding of icons in Mac menu items (v2)
Cameron, please test getting rid of the call to RequestDecode() from nsMenuItemIconX::OnStartContainer(). If you don't have any problems (I didn't), please post another patch that does this. (You should just clean out OnStartContainer(), so that it only returns NS_OK.)
Comment 23•13 years ago
|
||
A bit late, but: image.mem.decodeondraw = false reliably fixes the problem for me on all machines (OS X 10.4./10.5, G3/G4) with TenFourFox 9 beta 1.
Assignee | ||
Comment 24•13 years ago
|
||
Yup, it works without it.
Attachment #581463 -
Attachment is obsolete: true
Attachment #581463 -
Flags: review?(smichaud)
Attachment #581510 -
Flags: review?(smichaud)
Assignee | ||
Comment 25•13 years ago
|
||
(I left the check in OnStartContainer(), though, just in case)
Comment 26•13 years ago
|
||
> (I left the check in OnStartContainer(), though, just in case)
Please just get rid of it. It no longer serves any purpose.
Assignee | ||
Comment 27•13 years ago
|
||
Okay.
Attachment #581510 -
Attachment is obsolete: true
Attachment #581510 -
Flags: review?(smichaud)
Attachment #581532 -
Flags: review?(smichaud)
Updated•13 years ago
|
Attachment #581532 -
Flags: review?(smichaud) → review+
Assignee | ||
Comment 28•13 years ago
|
||
Thanks, Steven and Joe!
Check-in requested.
Status: NEW → ASSIGNED
Keywords: checkin-needed
Updated•13 years ago
|
Assignee: nobody → spectre
Comment 29•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
Assignee | ||
Comment 30•13 years ago
|
||
Comment on attachment 581532 [details] [diff] [review]
request decoding of icons in Mac menu items (v4)
It seems it's too late for beta, but asking for aurora since this should be a very minor fix to deal with an annoying possible regression.
Attachment #581532 -
Flags: approval-mozilla-aurora?
Updated•13 years ago
|
Summary: [Mac OS 10.6.8] Missing Favicons in the Application Menu Bar → Missing Favicons in the Application Menu Bar
Comment 31•13 years ago
|
||
Comment on attachment 581532 [details] [diff] [review]
request decoding of icons in Mac menu items (v4)
[Triage Comment]
Approved for Aurora. Please land on Monday 12/19 or earlier in order to make the cut-over to Beta.
Also including Cheng, as this sounds a lot like a support driver we've had a lot of issues with.
Attachment #581532 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 32•13 years ago
|
||
I'll do the aurora landing in the next hour or so.
Comment 33•13 years ago
|
||
Comment on attachment 581532 [details] [diff] [review]
request decoding of icons in Mac menu items (v4)
Landed on aurora:
http://hg.mozilla.org/releases/mozilla-aurora/rev/de25fe8ee416
Updated•13 years ago
|
status-firefox10:
--- → fixed
Comment 35•13 years ago
|
||
(In reply to Cameron Kaiser from comment #30)
> Comment on attachment 581532 [details] [diff] [review]
> request decoding of icons in Mac menu items (v4)
>
> It seems it's too late for beta, but asking for aurora since this should be
> a very minor fix to deal with an annoying possible regression.
Next time, please request tracking?
status-firefox9:
--- → affected
tracking-firefox9:
--- → ?
Comment 36•13 years ago
|
||
Any chance to get an automated test for? If not we definitely should have a manual test for it.
Updated•13 years ago
|
Comment 39•13 years ago
|
||
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0
Verified the fix based on comment #0 and comment #9.
Steps:
1. Launch Firefox
2. Go to Bookmarks>Recently Bookmarked
Result: All favicons are displayed at first try.
You need to log in
before you can comment on or make changes to this bug.
Description
•