Closed
Bug 526534
Opened 15 years ago
Closed 15 years ago
Page Info does not detect multiple instances of the same image on a page if no alt text is provided or the alt text is the same
Categories
(Firefox :: Page Info Window, defect)
Firefox
Page Info Window
Tracking
()
RESOLVED
FIXED
Firefox 3.7a1
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta3-fixed |
People
(Reporter: mozilla.bugs, Assigned: mozilla.bugs)
References
Details
Attachments
(2 files, 5 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dao
:
review+
beltzner
:
approval1.9.2+
|
Details | Diff | Splinter Review |
When images with the same url and no alt text or no differing alt text appear on a page, the function that populates the tree list misses the later instances of that image. When "View Image Info" selects the image, it searches for the imageElement which isn't in the list, and loads the first image in the tree instead of the correct image. We can load the image that has the same url (though we would need to pass that as an argument or something), but it may be scaled to different size than the original image, as I have encountered before; so height and width data for web developers and other users would be meaningless--and perhaps latently so. On the other hand, there are some sites that might have an image repeated dozens or hundreds of times, and each of them would be shown in the tree view, which probably isn't a bad thing, but it's worth thinking about. Dao: What do you think is the best and most reasonable way to fix this?
Comment 2•15 years ago
|
||
(In reply to comment #0) > On the other hand, there are some sites that might have an image repeated > dozens or hundreds of times, and each of them would be shown in the tree view, > which probably isn't a bad thing, but it's worth thinking about. Having hundreds of rows for the same image (common situation for images used as background) made the media tab very hard to use. See bug 201264.
Assignee | ||
Comment 4•15 years ago
|
||
(In reply to comment #2) > Having hundreds of rows for the same image (common situation for images used as > background) made the media tab very hard to use. See bug 201264. That's what I was afraid of. I just don't know how to work around this and how to reconcile the need for some users to get the correct sizing and alt-text data they need from an image without having an overpopulated list. Perhaps we need a solution that searches for the imageURL in the tree (returning the correct image) but lists information about the imageElement and properly scales it.
![]() |
||
Comment 5•15 years ago
|
||
I filed the other bug Bug 526721 - "Page Info" does not detect of images in a document,there are same url,same alt and different scale
Updated•15 years ago
|
OS: Windows Vista → All
Hardware: x86 → All
Assignee | ||
Comment 8•15 years ago
|
||
Assigning to me.
Assignee: nobody → mozilla.bugs
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•15 years ago
|
||
This patch just adds a check to addImage that the image either be a new one in the tree (the original behavior) or the gImageElement.
Attachment #410987 -
Flags: review?(dao)
Updated•15 years ago
|
Attachment #410987 -
Flags: review?(dao) → review-
Comment 10•15 years ago
|
||
Comment on attachment 410987 [details] [diff] [review] Patch that ensure gImageElement in image tree Below there's code that counts duplicate images. That needs to be taken care of as well.
Assignee | ||
Comment 11•15 years ago
|
||
(In reply to comment #10) > Below there's code that counts duplicate images. That needs to be taken care of > as well. What is the most elegant way to do that?
Assignee | ||
Comment 12•15 years ago
|
||
How do we want the counter to behave? Do we want it count the gImageElement as part of the total of the image that it would part of by default (if it wasn't be specially selected) in addition? I'm not sure what we want to change it to.
Comment 13•15 years ago
|
||
If gImageHash[url][type][alt] already existed, we need to count that as a duplicate, which means to increase the counter by one.
Assignee | ||
Comment 15•15 years ago
|
||
(In reply to comment #13) > If gImageHash[url][type][alt] already existed, we need to count that as a > duplicate, which means to increase the counter by one. That's what I thought you meant, I just wanted to make sure.
Attachment #410987 -
Attachment is obsolete: true
Attachment #411208 -
Flags: review?(dao)
![]() |
||
Comment 16•15 years ago
|
||
(In reply to comment #15) > Created an attachment (id=411208) [details] > Patch v 1.1 This patch do not solve Bug 526721.
Updated•15 years ago
|
Attachment #411208 -
Flags: review?(dao) → review-
Comment 17•15 years ago
|
||
Comment on attachment 411208 [details] [diff] [review] Patch v 1.1 >- if (!gImageHash[url][type].hasOwnProperty(alt)) { >- gImageHash[url][type][alt] = gImageView.data.length; >+ if (!gImageHash[url][type].hasOwnProperty(alt) || elem == gImageElement) { >+ if (gImageHash[url][type].hasOwnProperty(alt)) { >+ var i = gImageHash[url][type][alt]; >+ gImageView.data[i][COL_IMAGE_COUNT]++; >+ } This doesn't work as expected, as gImageView.addRow will be called regardless. I think all you need to do is to insert this in the last else branch: if (elem == gImageElement) gImageView.data[i][COL_IMAGE_NODE] = elem;
Comment 18•15 years ago
|
||
You should be able to modify browser_bug517902.js to cover this bug by adding something like <img src='about:logo?b' height=200 width=250 alt=2>.
Assignee | ||
Comment 19•15 years ago
|
||
This adds that last line to the final else branch, and it adds that new image tag to the browser test.
Attachment #411208 -
Attachment is obsolete: true
Attachment #411252 -
Flags: review?(dao)
Comment 20•15 years ago
|
||
Comment on attachment 411252 [details] [diff] [review] Patch v 1.2 >- if (!gImageHash[url][type].hasOwnProperty(alt)) { >+ if (!gImageHash[url][type].hasOwnProperty(alt) || elem == gImageElement) { because of that change, you'll never reach this: > } > else { > var i = gImageHash[url][type][alt]; > gImageView.data[i][COL_IMAGE_COUNT]++; >+ if (elem == gImageElement) >+ gImageView.data[i][COL_IMAGE_NODE] = elem; > } > content.location = > "data:text/html," + > "<img src='about:logo?a' height=200 width=250>" + > "<img src='about:logo?b' height=200 width=250 alt=1>" + >- "<img src='about:logo?b' height=100 width=150 alt=2 id='test-image'>"; >+ "<img src='about:logo?b' height=100 width=150 alt=2 id='test-image'>" + >+ "<img src='about:logo?b' height=200 width=250 alt=2>"; This passes even without this bug being fixed, doesn't it?
Attachment #411252 -
Flags: review?(dao) → review-
Assignee | ||
Comment 21•15 years ago
|
||
Here is a patch that fails the browser-chrome test if this patch is absent, and the new block of code only increments the count value of another image if the selected image is gImageElement and a duplicate of another. I have tested it, and it returns the correct count totals.
Attachment #411252 -
Attachment is obsolete: true
Attachment #411283 -
Flags: review?(dao)
Comment 22•15 years ago
|
||
Comment on attachment 411283 [details] [diff] [review] Patch v 1.3 That still populates gImageView.data with a new row. Was there a problem with the second chunk of the previous patch without the first chunk?
Attachment #411283 -
Flags: review?(dao) → review-
Assignee | ||
Comment 23•15 years ago
|
||
This patch checks if the image is already in the tree, and if it is, the tree entry is updated to point at gImageElement, otherwise a new row is created.
Attachment #411283 -
Attachment is obsolete: true
Attachment #411341 -
Flags: review?(dao)
Comment 24•15 years ago
|
||
Was there a problem with the second chunk of attachment 411252 [details] [diff] [review] without the first chunk?
Assignee | ||
Comment 25•15 years ago
|
||
This simple patch works for all the cases I've seen except for the one in Bug 526721. I would opt for having this fixed and the other bug reopened.
Attachment #411341 -
Attachment is obsolete: true
Attachment #411627 -
Flags: review?(dao)
Attachment #411341 -
Flags: review?(dao)
![]() |
||
Comment 26•15 years ago
|
||
(In reply to comment #25) > Created an attachment (id=411627) [details] > Patch v 1.5 > > This simple patch works for all the cases In the testcase Created an attachment (id=410276) >Additional Image that makes the bug more visible: icon >No alt text on either image: icon1 icon2 >Same alt text on each image: icon1 icon2 "Voew Page Info" of icon1 works, but icon2 does not work.
Updated•15 years ago
|
Attachment #411627 -
Flags: review?(dao) → review+
Comment 28•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/2eb351cc47d3
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
Assignee | ||
Updated•15 years ago
|
Attachment #411627 -
Flags: approval1.9.2?
Comment 29•15 years ago
|
||
Comment on attachment 411627 [details] [diff] [review] Patch v 1.5 a192=beltzner, thanks for the test!
Updated•15 years ago
|
Keywords: checkin-needed
Comment 30•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/3d2c81810e78
status1.9.2:
--- → final-fixed
Keywords: checkin-needed
Comment 31•15 years ago
|
||
Comment on attachment 411627 [details] [diff] [review] Patch v 1.5 (whoops, forgot to flip the flag)
Attachment #411627 -
Flags: approval1.9.2? → approval1.9.2+
You need to log in
before you can comment on or make changes to this bug.
Description
•