Closed Bug 57015 Opened 25 years ago Closed 25 years ago

chrome images should not be affected by necko load attributes.

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Other
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 56599

People

(Reporter: hyatt, Assigned: hyatt)

Details

Platform: Win98 Go to the bottom of the thread pane in mailnews using the modern skin. Start paging up by clicking in the blank space above the thumb. Every 3-4 screens you page, all of the mailnews folder images will reload. It's as if they've been flushed out of the image cache. This is obviously suboptimal cache behavior, since I'm not loading any new images. I have only seen this on Win98. It hurts tree scrolling performance that this is happening.
Keywords: rtm
Adding tor.
Summary: Images paged out of chrome cache for no reason → Chrome images paged out of image cache for no reason
Wow, on the trunk Win98 this is even worse. It happens for me 100%, every time I page up. For the record, it may be that the images are in the cache. If they are in the image cache, though, there's still a bug here, because if they are in the cache, the images seem to notify layout asynchronously. If the bits are there and ready, they should be given to layout immediately and not asynchronously, since you'll waste time generating extra reflows when the image comes in later.
This makes dragging the thumb in mailnews very difficult on Win98.
Hyatt: We don't pin images in the imgcache, since the code doing that caused the "Mystery of the Disappearing Chrome". But (as we discussed) this sounds related to the other bug you opened (#56599). I'm closing this one as a dupe of #56599. -pn *** This bug has been marked as a duplicate of 56599 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
I'm reopening and changing the summary to reflect a more focused description of the problem.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Chrome images paged out of image cache for no reason → chrome images should not be affected by necko load attributes.
Target Milestone: --- → M18
See patch attached to bug #56599. It also fixes this bug.
Assignee: pnunn → hyatt
Status: REOPENED → NEW
Status: NEW → ASSIGNED
*** This bug has been marked as a duplicate of 56599 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
No this isn't a duplicate. Chrome needs to be handled differently. My current guess is it is in the same load group as the web page.... but I haven't had time to verify. -pn
Chrome images belong to the load group associated with the document in which they are found. With the exception of scrollbars in Web pages, this means that all chrome URLs are in their own load group that is associated with the XUL document. Anyway, a chrome URL can be found in any load group. A Web page can load a chrome URL image, and we should still use the image cache and not perform validation. So the load group can't be used to resolve this problem.
Status: REOPENED → ASSIGNED
Is comparing the url the only way we can identify a chrome image? How can I tell I have a chrome image? Who issues the requests? XUL pages? -p
*** This bug has been marked as a duplicate of 56599 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Verified duplicate
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.