Closed Bug 88297 Opened 23 years ago Closed 21 years ago

ChromeTooltipListener should return ALT text when TITLE is not available

Categories

(Core Graveyard :: Embedding: APIs, defect)

Product:
Core Graveyard
Component:
Embedding: APIs
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 25537

People

(Reporter: DebugWeyers, Assigned: adamlock)

References

Details

(Keywords: compat, topembed, Whiteboard: WONTFIX ? -- non standards compliant)

Attachments

(3 files)

Patch to ChromeTooltipListener that displays ALT attributes when TITLE attributes are not found
3.05 KB, patch
Details | Diff | Splinter Review
A second patch that creates a bool on nsIWebBrowserSetup to allow for ALT tooltips display, includes minor changes to DocShell
8.33 KB, patch
Details | Diff | Splinter Review
A fix of the last patch to confine changes to embedding module. Stores mAllowAltTooltips member on nsWebBrowser.
7.04 KB, patch
Details | Diff | Splinter Review
I am working on an embedding client and the current nsIToolTipListener callbacks only pass along TITLE attributes. The expected behavior is that a mouseover on an image or link displays the TITLE attribute, but, if no title is available, displays the ALT attribute (if any). This behavior is evidenced in (and expected by) innumerable banner ads and web graphics. Steps to reproduce: Using an embedded client (mfcembed, winembed, etc.), move the mouse over an image with an alt tag and hover. Expected result: A tooltip pops up and displays the contents of the alt tag. Actual result: No tooltip is displayed. The current implementation of this functionality is in nsDocShellTreeOwner. {h,cpp}. The class ChromeTooltipListener has a callback (sToolTipCallback) that checks for a TITLE attribute via FindTitleText(). I propose simply adding an OR statement to this check so that failure to find TITLE text will result in a check for ALT text. If either is found, it is passed down the line to the tooltip listeners via ShowTooltip.
This function has been proposed and rejected many times before. There is a clearly delineated distinction in function between alt and title attributes; alt attributes are to be used when the user agent *cannot* render the specified content and displayed inline, while title elements provide additional information which can be displayed in tooltips. See bug 69877 and bug 25537 for discussion of this. Displaying the value of the alt attribute in a tooltip is considered a broken and non-standards-compliant behavior and a deliberate decision has been made not to do so. This behavior should (IMO, and probably in the opinion of the official standards-compliance team) also extend to other Gecko-based clients. QA, please WONTFIX.
Since its already been rejected many times, marking WONTFIX...
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
I'm reopening this bug. I'm sure this could be made a pref via nsIWebBrowserSetup that allows either behaviour. The default would be the correct behaviour with the pref allowing the more IE/Netscape 4.x behaviour.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Also note that this bug is specifically for embedders who want to modify the behaviour of how their tooltips are displayed. It does not affect Mozilla the application which carries on doing the right thing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
I attached a proposed patch implementing things as per Adam's suggestion. Added bool to nsIWebBrowserSetup::SETUP_ALLOW_ALT_TOOLTIPS which sets a member on the docshell (the default of which is false, to maintain expected browser behavior). sTooltipCallback in the ChromeTooltipListener now checks this bool before checking for ALT text to display. I wasn't quite certain if there was a better way to get ahold of the docshell from the ChromeTooltipListener. But I just wanted to get things moving on this patch.
Alex, It would be better to store mAllowAltTooltips in the nsWebBrowser class and leave nsDocShell alone. This confines the non-standard ALT behaviour to embedding and is easier as well because the chrome listener already has a pointer to mWebBrowser so it could use that to directly examine the value of mAllowAltTooltips.
We should not be using ALT for tooltips, ever. ALT is for alternate text. Letting authors know that it is for tooltips sends the wrong message and leads them to create pages that are unusable on non-graphical browsers. See http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html for more information. I recommend that this bug be resolved as WONTFIX.
See bug 1995 for the original discussion of this issue.
I think we all understand what the standard is and what the correct use of the ALT attribute is. However, the fact remains that thousands, if not hundreds of thousands, of web sites already exist that will show the ALT attribute as a tooltip if the a TITLE attribute is not available. This is because MSIE and previous releases of Netscape Navigator both implemented it. To close this bug as WONTFIX is unacceptable to embeddors. Mozilla won't display the ALT tags as tooltips, nor will NS Navigator (unless either choose to do so). Allowing embeddors the option to display them is a good idea. Navigator (and mozilla) will be able to claim standards compliance by not showing ALT attrs as tooltips, but to the end user it will simply appear to be another bug....because IE does it and Nav does not. That won't help grow marketshare. Even Netscape's home page is guilty of putting "Click here!" ALT attrs over advertisements. At this point, showing ALT attrs is pretty much an expected behavior, mostly due to site developers who don't know any better, and use IE for testing. Embeddors should have the option.
If you want to embed an engine that disregards the standards in order to take over the web, go embed IE, not Mozilla. (My personal opinion only, I guess.) (I also don't see the evidence that there are large numbers of sites that depend on this. Even if they do, tooltips aren't that important since the user rarely notices them.)
Whiteboard: WONTFIX ? -- non standards compliant
My ActiveX control is one embedding example that would like to have a switch to loosen the tooltip behaviour. As stated before, the default would be to only use TITLE tags and the embedder would have to explicitly enable ALT tag tooltips.
Why do we need to bloat the code with a series of prefs where the default is "do X right" and the pref can be changed to "do X wrong"?
I think one of the problems here is that Mozilla has a "quirks" mode. If there were no quirks mode at all, it'd be very easy to say that everything should conform to the standard, and evangelism should take care of any web pages that cause problems. But because of quirks mode, I suspect most people feel that requests like this one should at least fit somewhere into the browser. Ultimately, doesn't the fact that this request comes up again and again (and again) say something?
Quirks mode should be (and generally is, although some quirks have slipped in that shouldn't have) limited to those problems where we have serious problems on significant numbers of pages if we didn't implement the quirk. I don't see evidence that this qualifies (not very serious, and not many pages). Could you quantify "again and again"?
Dbaron, a quick search shows these bugs for the same issue: 25537 47575 66282 67093 74241 74376 78575 79996. Your definition may be different than mine, but this fits "again and again" for me :) One reason I would like to see this implemented is that, when writing an HTML page, I currently have to provide both ALT and TITLE to get a tooltip to show up on an image, because a good number of people still use Netscape 4.x. If I omit the ALT text, then NS4x users don't see a tooltip, but Mozilla and IE users do. If I omit TITLE, then NS4x, IE, and Opera users see a tooltip, but Mozilla users don't. I'd hate to tell people to use IE, and Mozilla is still not at that stage that I'd recommend it to, say, my parents or my less technically proficient friends. Maybe the question I should ask is: do you have a suggestion of how I can get an image to display a tooltip on all *relevant* browsers (IE, NS4x, Mozilla, Opera) without using ALT at all?
Out of all those bugs you mentioned and a number of other bugs you didn't mention that were marked duplicates of those bugs, there were only three cases other than this bug where people disagreed after learning why we behave the way we do (bug 61222, bug 67093, and bug 74241). So most of those bugs were the result of people who were uninformed but agreed with our behavior once informed of our reasons.
Dbaron, the reporter simply stayed silent in some of the bugs, like bug 25537, bug 47575, bug 66282, and bug 74376. I respectfully suggest that this is not the same as agreement :) Certainly when I reported this, I finally just shut up because it didn't matter if I felt there was good reason for the request, it was obvious I could not convince the "powers that be" Again, I would really like to know if anyone can suggest a way to make all the current, relevant browsers display an image tooltip without using ALT. If not, then I suggest that until and unless you can wipe Netscape 4.x off the market completely, there will be people expecting this behavior from their browser. Finally, reading over the W3C specs for IMG and ALT (as hixie has suggested in some of the other bugs), I don't see anything to suggest that the ALT text *cannot* be used for a tooltip. It simply says that the ALT text is required for non-visual browsers, but does not explicitly prohibit using it for an additional display.
> Certainly when I reported this, I finally just shut up > because it didn't matter if I felt there was good reason for the request, it > was obvious I could not convince the "powers that be" Even if that's the case, it still seems like the people who want ALT attributes displayed as tooltips are a minority. (Notice the various people who have argued against it.) > Again, I would really like to know if anyone can suggest a way to make all the > current, relevant browsers display an image tooltip without using ALT. If > not, then I suggest that until and unless you can wipe Netscape 4.x off the > market completely, there will be people expecting this behavior from their > browser. If we start displaying ALT attributes, then people will expect us to continue doing so after Netscape 4.x is off the market, since there will be more pages than there are now that "depend" on ALT. (I quoted "depend" since tooltips are unlikely to help most users figure out how to use web page interfaces.) > Finally, reading over the W3C specs for IMG and ALT (as hixie has suggested in > some of the other bugs), I don't see anything to suggest that the ALT text > *cannot* be used for a tooltip. It simply says that the ALT text is required > for non-visual browsers, but does not explicitly prohibit using it for an > additional display. As I've said before (in other discussions), I think my desk is a conformant HTML 4.0 user-agent since it does not behave differently in an observable macroscopic way when I tap different SGML-equivalent documents on it in morse code. While displaying ALT attributes as tooltips is not against the letter of the spec it is very strongly against the spirit of the spec, since ALT attributes are intended to be used to provide alternative text for when the image cannot be displayed (which means that displaying both text and image would be redundant). If we continue to teach authors that ALT attributes are for tooltips we will contribute to making the web unusable for blind people and people with slow connections in other parts of the world. For lack of an HTML standards-compliance module owner for Mozilla, taking the initiative and marking INVALID.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
This is a feature that is requested in embedding and that I personally need. Therefore I am reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
That you say it's "requested in embedding" scares me a lot. I guess the standards compliance folks can just start making changes to embedding interfaces too, right? :-)
standards compliance folks are welcome (as is _anyone_) to suggest modifications to interfaces "UNDER_REVIEW" or "FROZEN". IMHO, this boils down to the "quirks mode" slipperly slope. We slipped a looong time ago. It's an option w/ the "standard" behavior as the default.
This issue is much more fundamental than anything in quirks mode. It's about whether Mozilla is going to be yet another graphical web browser that encourages authors to write pages only for similar browsers, or whether it will help move towards some of the original intentions of the Web. If we have yet another browser that displays ALT text as tooltips, it will discourage authors from using correct ALT text because they will see it appear as tooltips and it will encourage authors to use inappropriate ALT text so that it will appear as a tooltip. This gets down to the reasons why I started working on the Mozilla project in the first place -- the promise of something better for the Web than the browsers before it. I'm having trouble thinking of why I should continue to work on the project if we give up on that. Every time I comment on this bug I get angry because I have the feeling I'm losing everything for which I've worked so hard over the past three years.
Looks good, r=adamlock@netscape.com
David, welcome to the eternal dilemma :-). I share the same pain (try building a networking library based on specs and rfcs :-)). The balance between "the right thing" and "the market place" is obviously hard. I'm personally coming at this dilemma from the necko side where time after time after time, we've had to deviate from specs and standards. It's to the point now that I don't even bother looking at specs for verification that I'm already familiar with :-(. Several years ago mozilla had to decide whether or not it was going to have to deviate from standards to make a viable (measured in terms of marketshare) product. That decision wound up conceeding quirks mode, a networking lib that isn't "spec", and obviously a variety of other things that aren't "perfect." Day-to-day all I can hope for is that the majority of what I do is standards compliant :-/.
I think this really ought to go to the newsgroups. I think this comes down to an issue of whether mozilla.org will arbitrarily accept patches that allow the browser to deviate from standards. The answer to that question is important to mozilla.org's legitimacy as a promoter of Web standards. It is clear that "tooltip" text is not consistent with the notion of "alternate content" as specified for the application of the ALT attribute. Thus the only "gain" from this patch is promotion of the Wrong Thing. (And changing OS to All, as this will surely affect everyone.)
OS: Windows 2000 → All
Keywords: topembed
My problem with this isn't so much that we have places where we're forced to compromise standards compliance to have a browser that actually browses, but that we're creating inconsistency between the standards compliance of Mozilla- the-browser-and-other-good-stuff, and browsers that use Gecko. This is all the more so because Mozilla isn't supposed to be an end-user product (or so I keep hearing)-that's the job of Netscape, Beonex, the embedders, etc. Gecko should have a consistent level of standards compliance, whether it's in Mozilla, Netscape, Beonex, or anything else-otherwise web designers will just have to resort to weirder and more obfuscated browser-sniffing hacks to work around the different quirks introduced by different Gecko-based browsers. If embedders feel strongly about this particular quirk, it should be brought in front of the entire Mozilla community for discussion, and, if their arguments are compelling enough, it should be added to quirks mode for the entire browser. What should NOT be happening is a balkanization of the layout engine caused by prefs like this. I heartily agree with the suggestion that this be brought to newsgroups-this is a major policy issue, and it shouldn't be quietly slipped into the tree without warning or discussion.
> standards compliance folks are welcome (as is _anyone_) to suggest modifications > to interfaces "UNDER_REVIEW" or "FROZEN". There's a big difference between suggesting changes and trying to slip them in without anyone noticing.
c'mon. who's trying to "slip" anything in? that's pretty hard to do in open-source even if someone wanted to. again, balance is key here. we can't go through review of _every_ modification that goes into the tree. that would ultimately boil down to voting on mods which is a sure way to grind things to a halt. I'm doing the best I can to ensure that mods to embedding related interfaces get public exposure for review. I send mail to .embedding/.porkjockeys _everytime_ there's a scheduled API review. I've offered up temporary badges to non-NS folks who want to physically attend. There's a 800 number for _anyone_ that wants to dial in, etc. I'm sorry if you feel things are being "slipped" in.
> I'm sorry if you feel things are being "slipped" in. I said that I thought you were *trying* to slip them in. If choess hadn't mentioned the existence of this bug to me, there would have been no controversy and I probably would have found out sometime after it landed, as would everyone else who was involved in the original decision.
Judson: what I find most serious about this bug is that a major policy decision is being made, implicitly, without any airing. The problem is not that major changes to embedding are not sufficiently open; the problem is that we will potentially have embedded clients with a different level of standards compliance than Mozilla *on the same page*. Showing "alt" attributes in tooltips is hardly the most popular "4.x did it the wrong way and we want you to do it the wrong way" issue; this relatively minor embedding change opens a major can of worms in allowing embedders to do things "the wrong way". Please, whatever you may think of the arguments for whether or not this is standards-compliant behavior, don't set up the potential for different levels of compliance in "Mozilla" Gecko and embedded Gecko; from a web designer's perspective, this is a disaster in the making.
Adam: I'm curious. Why do you feel that "This is a feature that is requested in embedding and that [you] personally need."? Feel free to e-mail me directly at ianh@netscape.com if the reasons are AOL-confidential.
Keywords: compat
My ActiveX control is meant to be a drop-in replacement for the IE control so I would like the tooltip behaviour to be the same. I have also received emails and seen enough talk of tooltips in the npm groups to know there will be other embedders who want it too.
Would you also like the CSS rendering to be the same?
choess: I couldn't agree more w/ the point you're making. Mozilla is indeed the standard to be used by embeddors, if Mozilla goes off course (on it's own or by embedding forces pulling on it), everyone goes off course :-/. The trick is balancing these forces; sometimes it's easy (most of the time), sometimes it's not. I wish I had a real response :-/.
Alright, this "bug" has been troubling my sleep and digestion for days, and I'll be away from the network for a while, so let me give here my full Reasons Why This Should Not Be Checked In. 1) We should not be showing "alt" text in tooltips. From the HTML 4.01 spec: "For user agents that cannot display images, forms, or applets, this attribute specifies alternate text." In other words, displaying the contents of the "alt" attribute when we've successfully loaded the image is decisively wrong. 2) To be very blunt (forgive me; as I said, I'm tired and cranky), I think the arguments we've seen here, "To close this bug ... is unacceptable to embeddors[sic]," "I would like the tooltip behavior ... to be the same as IE," are, quite frankly, complete BS. It's not as if, say, all the links on the page stop working because someone forgot to close the "head" element; one small, auxiliary feature (the tooltip) "breaks" in the sense that you have to include tooltip text in two attributes, not one. (While I'd rather not see people duplicating "alt" and "title" attributes when that behavior is inappropriate, some web authors have other priorities; that's their lookout, not mine). I submit that any "bug" which can so easily be worked around by authors is *NOT* essential to "fix". Rant over, the more important arguments, I think, are: 3) Why is it that this is somehow essential for embedding and not for non-embedded products (Netscape, Beonex, etc.)? All of them are browsing the same web, on the same types of machines and operating systems-if this is really necessary, it should be brought back up for discussion and be entered into Quirks Mode in layout so that everything behaves uniformly. 4) Continuing on this theme, does it justify forking our standards support? If we commit to this, we open the door for Gecko-embedding browsers having different levels of standards compliance from Mozilla/Netscape/Beonex, etc. and one another, creating a compatibility nightmare for web designers trying to keep up. 5) Why is this, and not other backwards-compatibility-breaking issues, such a problem for embedders. Anyone embedding Gecko has already accepted our non-support for "layer" &etc., as well as document.all (to name two off the top of my head); I realize this is a terrible thing to say in front of customers, but maybe if it's essential that you have more backwards compatibility than enough to keep the page from destroying itself (quirks mode), you should look into embedding another HTML renderer. This pretty much sums up my arguments: I'm sorry I haven't been more objective and polite about this, but I'm tired of arguing an issue I thought had been decently laid to rest long ago. Please, PLEASE, consider some alternative to this; I know I've said this over and over, but this has much broader effects that just a minor embedding change, or a behavior only a few standards-compliance people care about. And to the embedding folks: thanks for all your work. I know I bitterly disagree with you about this bug, but I do appreciate what you've done to make Gecko more useful. Please WONTFIX this bug...but keep up the good work! :)
Some community sites in Sweden (for example www.lunarstorm.se) uses this feautre/bug and it's really annoying that mozilla doesn't have this. While this is not standard the fact is still that alot of webpages uses this in some way or another to provide information. I do agree it is not correct way of doing things but I still think this feature/bug should be added atleast as a option. As we all know alot of people are using the IE browser and many webdesigners are using IE only to test the work they do we have to be flexible to allow such stupidity to exist.. else people like myself will have to use Netscape 4/IE on alot of sites out there and not mozilla :/
Fix is checked in... Only kidding, marking WONTFIX.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Adam, your restraint is very much appreciated. I won't have access to the newsgroups for a few days, but when I get back, I'm going to propose that we: 1) Add material on alt/title tooltips to ekrock's standards compliance page. 2) Accept "tooltips don't work on this page"-type bugs as Evangelism bugs, so people aren't just getting turned away without help when this occurs.
VERIFIED WONTFIX.
Status: RESOLVED → VERIFIED
I've been asked (for the record) to paste in the following email message I sent that summarized my arguments: > [...] Saying the "standard got dictated before we had a chance to rebut" is wrong. TITLE has been available for some elements since HTML 3.2 (early 1997) and for all elements since HTML 4.0 (late 1997). ALT has been clearly defined as for alternate text since HTML 2.0 (November 1995, the first standardized HTML spec). It's just a question of whether we're going to propagate a mistake made in Navigator 4.x into the future (see below). > [...] This isn't just some silly standards-compliance nit. This is one of the central points of making the web accessible to users other than those with good vision who have high-bandwidth connections over which they can load images. The trend of putting ALT in tooltips started with Netscape 4.x, and MSIE followed, although it additionally (and preferentially) used TITLE, which is appropriate for tooltips. If we continue to use ALT for tooltips it will ruin the use of ALT for alternate text which is key to the accessibility of the web, since: * Authors who want to use ALT text correctly will remove it when they see that it's causing tooltips (that don't give any additional information once you see the image) to appear in our browser. (Note that application of the ADA (Americans with Disabilities Act) to the Web, which is starting to happen, may force many authors to provide correct ALT text whether they want to or not.) * Authors who want tooltips will write ALT text (rather than TITLE text) that is not appropriate for alternate text for the images and will cause pages to appear as nonsense to blind users or users who aren't loading or can't load images MSIE for Windows has *already* been known to follow our lead on important standards-compliance issues when we take the first (hard) step and break some existing pages. IE6 will have a stricter CSS parser, greatly improving interoperability of CSS implementations. I'd guess we've had at least 10 bugs filed on the strictness of our CSS parser -- considering the numbers of users filing bugs it really isn't that many. I fully expect IE to follow our lead on this one as well if we take this step and keep our behavior as is. However, if we don't, it will be to the harm of the web at large.
Is it possible to make this a quirks mode only thing? After all quirks mode doesn't follow standards but tries to emulate NS4.
The goal of quirks mode is not to emulate NS4. That would require *tons* of quirks. The goal of quirks mode is to deviate from standards when (and only when) not doing so would make us unable to handle real web pages correctly. Also see my comments above, which apply equally to quirks mode.
*** Bug 109410 has been marked as a duplicate of this bug. ***
+1 vote to display ALT text as tooltip, when TITLE is not available
Just a thought, in case anyone is still paying attention to this bug. Maybe there is some way to emulate this behavior without making any core changes to Mozilla. Like adding some javascript hook that runs after each page load to walk the DOM tree and set the tooltip for each image object to the ALT value. Seems like a lot of controversial features could be implemented in this sort of non-intrusive way.
well if you insist that you want to see alt as tooltip, see http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en
Yeah, I use that plugin for Mozilla. Gets around the diamond mine anals on the Mozilla project. Highly recommend it.
Except that 80%-90% of the Mozilla users even does not know that such popupalt plugin exists. And they will simply say: Mozilla is ****! It even can not display the tooltip, what Internet Explorer displays correctly. Users don't know about standards, nor they bother about it. They will simply uninstall Mozilla, and say their friends, Mozilla is a ****! Period. Mozilla will be never widely successful, until it will not have built-in support for traditional feature, like ALT tooltip display (when TITLE is not available).
Though I agree Mozilla should show Alt attributes as a Tooltip at least as an option, I disagree with your arguments WebMaster33. 1) Users don't know about standards, nor they bother about it. Well Mozilla is for developers. I hope they know about standards. If they're a developer, Mozilla may be their introduction to standards (clearly a goal of the authors), and if they don't like standards, then they indeed will not use Mozilla - and its authors won't miss such users. Netscape 7 on the other hand is quite different. As it's intended for the masses, I agree, those users should not be forced into a standards-anal experience. 2) Mozilla is a ****! I doubt that. I care about Mozilla's feature set because it's my favorite browser. Presumably the same is the case for you, and the other more than 100 users commenting on this bug and its Dupes. And with the Alt Plugin (easy to install thanks to Mozilla's sweet XPI architecture), it's near-perfect. 3) 80%-90% of the Mozilla users even does not know that such popupalt plugin exists. Well, if it is important to them, they can find this bug and, with sufficient patience, the link to the Alt Plugin. However, it did take me a long time to realize Mozilla was consistently not recognizing the Alt attribute. I had assumed the browser was broken, or that it was a feature meant for later. This is a lacking feature anyone new to Mozilla would expect, and if the anal people running this boat seriously won't include Alt Tooltips into the main codebase, they should at least include a warning in the Readme. that this feature isn't implemented, and where to get the Plugin to resolve the issue.
Answer to Comment #52: 1) Mozilla is for developers No. Mozilla is not just for developers! Mozilla is for any user, who want a small, fast browser, with fine features! 2) >>Mozilla is a ****! I DID NOT say that!!! I said, users who don't know why ALT is not displayed will say that... >I had assumed the browser was broken, or that it >was a feature meant for later. You just proved the statement I said, that people would think: Mozilla is a ****. You thought it's broken. It's the same. Even IE has the option to turn ON/OFF ALT tooltip displaying: Accessibility/Always expand ALT text for images. By default it's turned OFF. It would be so easy to have implemented as option in Mozilla, too. And if would be turned OFF by default, similarly like in IE, it would not hurt anybody, but those users like me, who misses this feature would get their small missed feature. Mozilla would support this way a traditional feature. Optionally. I can't believe that a turned off feature would disturb Mozilla developers so much, that they don't want to implement it.
Reopening to mark as a dup of bug 25537.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
*** This bug has been marked as a duplicate of 25537 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → DUPLICATE
Request for a specific implementation of #25337. Verifying duplicate.
Status: RESOLVED → VERIFIED
By the way, there's an error in the first patch that duplicates FindTitleText() as FindAltText() changing instances of "title" to "alt". It also duplicates the part checking the XLink namespace if there's no title found in the root namespace. While there is an 'xlink:title', there is no 'xlink:alt', so the XLink check in FindAltText() wastes cycles to no purpose.
*** Bug 230064 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: