the image-button shows the value of the name-attribute instead of the alt-attribute
Reassigning to Rod.
Assignee: karnaze → rods
The problem is the nsImageFrame is never being notified that it couldn't find the file/image.
*** Bug 10767 has been marked as a duplicate of this bug. ***
setting to M14
Target Milestone: M14
Depends on: 25360
Bug 10767 MUST be checked when this bug is verified. ckritzer: Since this is an ALT text bug, I'm taking over QA contact. If you don't want me to do this, feel free to reinstate yourself... rods: I'm a little confused as to what this bug is exactly covering... your comment of 2000-01-28 08:45 doesn't seem related to the original submission comment??? jessberger: Do you have a test page for the problem you were reporting?
setting to M15
Status: NEW → ASSIGNED
Target Milestone: M14 → M15
mass-move to M16
Target Milestone: M15 → M16
Moving out by executive order.
Target Milestone: M16 → M17
Depends on: 35506
Nominating nsbeta2. Supporting ALT well is important for accessibility. There is also legal exposure for AOL under ADA for lack of accessibility. Therefore we should try to do as well as possible for FC for both reasons.
This bug cannot be marked nsbeta2+ unless you mark Bug 35506 nsbeta2+, this bug is BLOCKED by Bug 35506. In fact, once Bug 35506 is fixed, there is a good chance that this will just work. (But I can't do any testing until then)
Severity: normal → blocker
Summary: image-button doesn't show alternative text value → [BLOCKED]image-button doesn't show alternative text value
Actually, it appears it is broken for net based images also and I just found the problem and fixed it. BUT Bug 35506 still needs to be fixed or the alt text won't show up for missing disk-based images.
Putting on [nsbeta2+][6/15] radar.
Whiteboard: Fix in my tree → [nsbeta2+][6/15]Fix in my tree
Summary: [BLOCKED]image-button doesn't show alternative text value → [BLOCKED][FIX]image-button doesn't show alternative text value
Since this probably won't make nsbeta2, nom. nsbeta3 & rtm, *strongly* recc. nsbeta3 hard-stop. I'm confused: does this really depend on bug 8979 (which has been marked Future)?
Keywords: nsbeta3, rtm
Another thing I don't understand: is this bug specific to the handling of *broken* (not found) images (as implied by rods's previous comment "The problem is the nsImageFrame is never being notified that it couldn't find the file/image."), or does it apply to unbroken, found images? Could someone please clarify the Summary? If this bug is specific to the handling of broken images, maybe we can Future this and the depending bugs (so long as we're showing *something* on broken links) since elegant handling of broken links (beyond what Nav4 did) isn't a priority for FCS.
Cleaning up status whiteboard by marking beta2 minus (6/15 has passed). IS the comment "fix in my tree" for real? This was put in the whiteboard over a month ago.... and has me confused. There are also several question by Ekrock that need clarification. Rods: Could you update this bug with some info? Thanks, Jim
Whiteboard: [nsbeta2+][6/15]Fix in my tree → [nsbeta2-]]Fix in my tree
Yes, it has been fixed that long, it was a bug dependency issue. it's now fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Verifying on build 2000-09-18-06-M18 Platforms: -Windows 98 -Linux RedHat 6.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.