Closed Bug 135902 Opened 23 years ago Closed 21 years ago

Alternate text and Type has wrong value

Categories

(SeaMonkey :: Page Info, defect)

Product:
SeaMonkey
Component:
Page Info
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: aha, Assigned: db48x)

References

(
URL
)

Details

2002040503/Win2K Repro: 1. open link on image http://1.im.cz/s/ibmx.gif 2. open Page Info | Media 3. click on image row 4. look at Alternate Text and Type items Actual: AT: The image "http://1.im.cz/s/ibmx.gif" cannot be displayed, because it contains errors. Type: Unknown Expected: AT: Not Specified Type: GIF (Image is fully displayed
Um... That alternate text is correct. The HTML document we generate for that image has that as the ALT text. "Type" would usually list "Image", no? Not sure whether we shold even enable page info for non-document pages...
Boris: Alternate text is IMHO incorrect. Is it true, that page created internally by Mozilla has this text in it's content (see below), but Page Info is displayed only for image object (look at General tab in Page Info - Type: image/gif - not text/html). Internaly created page for image: <html> <body><p><img src="http://1.im.cz/s/ibmx.gif" alt="The image “http://1.im.cz/s/ibmx.gif” cannot be displayed, because it contains errors."></p></body> </html> Why is text '... cannot be displayed ...' when Mozilla displays image fine? I'm wrong with expected type in second part of bug report, type should be 'image/gif' (not 'GIF'), but no 'Not Specified'. > Not sure whether we shold even enable page info for non-document pages... Be sure that Page Info have to be enabled for all content (information like a Source, Size, Modified, Expires are same for all objects comming via HTTP). Daniel's Page Info is nearly perfect and dissabling it in some cases will be big lost =)
> Be sure that Page Info have to be enabled for all content (information like a Source, Size, Modified, Expires are same for all objects comming via HTTP). It's called "Page Info", not "Images and Other Objects Info". "Properties" might be a good place for doing this.
Just my two cents: Actual 'Element Properties' dialog for images is just kind of joke of Mozilla developers, it's usable only for common user. Daniel's 'Page Info' is providing now much better work for webdevelopers. If is more correct to rename Daniel's work from 'Page Info' to 'Content Info', just do it. But don't remove/disable features of Page Info just for wrong chosen name in old NN (NN4.x - Page Info, NN3.x & NN2.x - Document Info, NN1.x - hasn't anything similar). Maybe is bug wrongly generated ALT value of internally created page for image - what do you think?
> Actual 'Element Properties' dialog for images is just kind of joke It shouldn't be. It should contain useful information for the element in its context. If it doesn't then that is a bug. > If is more correct to rename Daniel's work from 'Page Info' to 'Content Info', > just do it. But 'Page Info' gives information about pages -- not individual items. For example, 'Render mode' is useless on an image. Who cares if its Quirks or Standards compliance mode? The 'Forms' and 'Links' tabs are completely useless, etc. > But don't remove/disable features of Page Info We can't remove or disable anything that we haven't yet implemented. And we _should_ remove features of Page Info in favor of moving it to a better place where appropriate. More accurately, we should disable Page Info in certain contexts where Element/Image/Object Properties make more sense. Again if the Properties dialog doesn't give useful information, that is not a Page Info bug. File a bug to make Properties do the right thing (I'm quite positive there already are several of those bugs lying around though). > Maybe is bug wrongly generated ALT value of internally created page for > image - what do you think? No. That alternate text is very reasonable given the fact that if an image fails to load, we should let the user know there was an error. 'The image "foo" cannot be displayed, because it contains errors.' is a very feasible alternate text for an image in this case. I can't think of any other time where that would be appropriate text, but there is nothing wrong with us using that since it's a meaningful alternate in the event the image fails to load.
> But 'Page Info' gives information about pages -- not individual items. IMHO 'Page Info' gives information about content and if individual items exist, also about content's individual items. See below... > For example, 'Render mode' is useless on an image. Who cares if its Quirks > or Standards compliance mode? The 'Forms' and 'Links' tabs are completely > useless, etc. There are many pages without links, forms or medias. For these pages are tabs Forms, Links or Medias useless too, but nobody disable them. But Security tab or some information on General tab (size, chaching, MIME type etc.) are always _usefull_ for any displayed content (TXT file, any image). BTW Page Info | Security is opened for any content by clicking on lock icon in browser's right down corner. > No. That alternate text is very reasonable given the fact that if an image > fails to load, we should let the user know there was an error. 'The > image "foo" cannot be displayed, because it contains errors.' is a very > feasible alternate text for an image in this case. Did you try this? Actually it isn't work (2002040503/Win2K) - for user isn't ALT of any broken image actually accessible. ALT isn't displayed as tooltip or in replacement of image. Is there any bug about it? BTW Element properties for broken image are also buggy - 24px and 24px =(
So... one other possibility. Properties and Page info could use getting merged anyway, imo... So one option is to make the properties dialog _useful_. Then on a standalone image page bring up the properties dialog instead of the main page info. Here useful would mean "supporting the same functionality as the media tab or more". This would fix a number of issues: 1) The fact that render mode does not apply to images 2) The fact that encoding does not apply to images (in the sense of character encoding) (caveat. What about svg? We may want to keep this one...) 3) The fact that for images you want all the info on the front tab instead of hidden in the Media tab 4) The fact that for an image document alt text is our internal thing and the user/developer could really not care less about it. And likely a few other issues. From a technical perspective, this would just involve some refactoring of pageInfo.js and including part of the code in the image properties XUL, then a function that runs when the user opens page info that determines which dialog to actually open.... Thoughts?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ah, the blurry line betwween the html document and the image the user thought he was loading :)
> IMHO 'Page Info' gives information about content and if individual items exist, > also about content's individual items. That's almost correct. It gives information about content and if certain individual items exist _within_ the content, also about those items. Images for example cannot contain other items. It is just one element. Therefore element properties is more appropriate in this case. > There are many pages without links, forms or medias. However they are fully capable of containing links, forms, or other media. That is saying they could have them but don't. On the contrary, images cannot contain other images. Forms cannot contain other forms, etc. > But Security tab or some information on General tab (size, chaching, MIME type etc.) are always _usefull_ I never said they weren't. Would they be any less useful if they were displayed on the Properties dialog in this context? > BTW Page Info | Security is opened for any content by clicking on lock icon Well, that too is a bug IMO -- I feel that the security tab should be separate from page Info. > Did you try this? Actually it isn't work. Yes I have already seen it in action on several images. There were errors loading the image and all I got was that message. I thought it was very useful. I agree with what Boris said. That seems to be what I was getting at.
I agree with Boris too, so could you Boris change Summary of this bug? Few notes to Christopher's last comment: > On the contrary, images cannot contain other images. Mozilla is now supporting subformat of Windows Bitmap for icons (.ICO). Icons usually contains several images with different dimensions and color-depth. Animated GIFs also containt several images. IMHO isn't important to support this feature now, but it's pretty feature for future. > ... Would they be any less useful if they were displayed > on the Properties dialog in this context? Yep. Properties could be reached only via mouse click (what's absolutely correct in context of HTML document containg many images, objects etc.), but it's slow-paced for single object content as plain text document, image etc. (what is accessibility problem). But user could reach Page Info always with keyboard and mouse.
I was trying to debug this page: http://www2.canisius.edu/~graciem/mozilla.html which had some PNG loading problems. I confirmed with telnet that the type was set to text/html, which explained those problems, but if the Media tab had the Type field properly set, it would have been easier. (and possible for non-CLI users) The requester suggested: Type: GIF But I think it should be: Type: image/gif or whatever the HTTP server said it was. Since Mozilla is able to display the PNG's anyway, there's some part of Mozilla that's second-guessing the headers. Maybe its opinion should also be listed, like Type: text/html (PNG)
*** Bug 152705 has been marked as a duplicate of this bug. ***
Depends on: 195492
Product: Browser → Seamonkey
just chekcked in, marking bug 19492 and it's dependants fixed
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.