Closed Bug 114641 Opened 23 years ago Closed 19 years ago

Alternate <applet> content not displayed. No fallback available.

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: pbjoiner, Assigned: bzbarsky)

References

(
URL
)

Details

(Keywords: html4, testcase, Whiteboard: [HTML4-13.4])

Attachments

(6 files, 9 obsolete files)

testcase
732 bytes, text/html
Details
testcase #2
1.09 KB, text/html
Details
testcase #3
1019 bytes, text/html
Details
testcase #4
5.07 KB, text/html
Details
testcase #5, triggers the assertions in comment 32
380 bytes, text/html
Details
Patch
1.25 KB, patch
Biesinger
: review+
dbaron
: superreview+
bzbarsky
: approval1.8.1.1-
Details | Diff | Splinter Review
With Java off or a failed .class load any alternative content within the <applet> element is simply not displayed. That means there's no way to construct fallback content of any kind. The files I'm working on are behind our firewall, sorry. I've included a URL with alternative applet content.
->Layout, but maybe plugins.
Assignee: asa → attinasi
Component: Browser-General → Layout
QA Contact: doronr → petersen
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
1) The testcase on Mozilla.org has a misplaced quotation mark in the applet's alt text. 2) Why is this futured? I know there are a ton of 'more important'/crasher bugs to fix for 1.0, but this is basic HTML parsing here. </rant>
The example... http://www.mozilla.org/quality/browser/front-end/testcases/oji/test3.html ... is buggy indeed, but correct code doesn't work either. Oliver Kitzing
That doesn't work either. <applet archive="AnyApplet.jar" code="AnyClass.class" width=744 height=87> <param name=regnewframe value="YES"> <!-- Additional params left out here --> <img src="img/wellen.jpg"> </applet> The image is not shown as alternative for the applet if Java VM is deactivated as it should. Oliver Kitzing
I see the same bug running Mozilla 1.0 under Redhat 7.2. Can someone with sufficient privileges change the Platform and OS categories of this bug report to All? If you look at the cvs source for http://www.mozilla.org/quality/browser/front-end/testcases/oji/test3.html you can see that the typo is nested quotes in the ALT tag, not the missing quotes that it looks like if you try to view Page Source in Mozilla on that page. If you correct the error then you can see that this bug is that the ALT text is displayed but the other text within the applet tag is not displayed. That allows one to use the ALT tag as a workaround. I agree that this is pretty bad as bug and the workaround is not very good... Think of all the Java applets out there that have something that is supposed to be displayed if Java is not enabled in the browser. What's the right way of bringing this to the attention of the person who maintains the test case? I'll try adding his email address to the cc list on this bug.
Attached file testcase —
How do you reproduce this bug? This WFM on Windows 2000 with 20020619. 1. Load Testcase 2. Observe Java working 3. Disable Java in Prefs | Advanced 4. Reload Page 5. Alt text displayed
Peter - > 5. Alt text displayed That is the bug. The correct behavior is to display the text portion of the applet tag, not just the Alt text. To quote the test case page on http://www.mozilla.org/quality/browser/front-end/testcases/oji/test3.html : [begin quote] With Java disabled you should see the following alternate-text followed by any text and/or HTML contained inside our sample applet: [The "Jitter Text" Java Applet!] The JitterText applet is a spinoff from Sun's NervousText applet. It does a slightly better job spacing the text as it dances about, and also provides the option to display each character of the text in a random pattern of colors. Clicking on JitterText pauses its animation, and displays the text normally. Clicking again resumes the animation. [end quote]
Attached file tescase #2 (obsolete) —
Some more testcases. BTW, what's supposed to happen when you have BOTH an ALT attribute AND embedded content?
Attached file testcase #2 —
Some more testcases. BTW, what's supposed to happen when you have BOTH an ALT attribute AND embedded content?
Attachment #90613 - Attachment is obsolete: true
I'm not sure what is supposed to happen from what I've seen of the specs. Maybe someone can come up with a definitive quote from an RFC. Experimenting, I've seen some browsers display the Alt text only during loading and the embedded text after loading. Others display the Alt text during loading and both the Alt and the embedded after loading. The test page referred to here states that the expected behvaior is to display both the Alt and the embedded text, but I don't know how the shrir came up with that.
I found bug 21456, the final patch there suggest that if there is embedded content that is displayable it is taken, if not then the ALT attribute is taken. Is this bug perhaps a regression of HasDisplayableChildren?
Keywords: testcase
Whiteboard: [HTML4-13.4]
This bug is actually a regression of bug 21456, see bug 21456 comment 40. I have a patch that fixes this bug so I won't reopen the older one. Reassigning and CC-ing some people for review.
Assignee: attinasi → waterson
Keywords: patch, review
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: Future → ---
Attached patch Patch rev. 1 (obsolete) — — Splinter Review
What I did was to take the "ConstructAlternateFrame" code and move that to the end of nsCSSFrameConstructor::CantRenderReplacedElement and control wether this path should be taken with a PRBool instead. I was a bit unsure on how to destroy the applet frame so please check that bit is correct, it's the line: newFrame->Destroy(aPresContext); (Only nsCSSFrameConstructor::CantRenderReplacedElement was changed.)
It seems like there's no point going through the second codepath as well if the ALT attribute is empty. It also seems rather bizarre that APPLET takes both children and an ALT attribute for alternate content. Perhaps we should ask the HTML WG which should take priority, or whether one was a mistake? What do other implementations do for priority? Do they check whether there's something nonempty inside of the APPLET? One spelling mistake in the patch - "wether" should be "whether".
>It seems like there's no point going through the second codepath as well if the >ALT attribute is empty. I just moved this code block verbatim from one place to another. I'd rather just leave it to ConstructAlternateFrame() to decide what to do. Or did I miss your point here? >It also seems rather bizarre that APPLET takes both children and an ALT ... Regarding priority and what the spec says: read Chris Waterson's comment in bug 21456 comment 20. See also the short summary in bug 21456 comment 40. >One spelling mistake in the patch - "wether" should be "whether". Will fix the speling error - new patch coming up...
Attached patch Patch rev. 2 (obsolete) — — Splinter Review
Spelling error fixed: wether -> whether
Attachment #95825 - Attachment is obsolete: true
Comment on attachment 95890 [details] [diff] [review] Patch rev. 2 >+ if (nsHTMLAtoms::applet == tag.get() && !HasDisplayableChildren(aPresContext, newFrame)) { Two problems here: 1) One doesn't need .get() for comparisons with nsCOMPtrs anymore, so don't use it. (This happens somewhere else in the patch, too, I think.) 2) The second argument to HasDisplayableChildren should be |aFrame|, still, I think, rather than |newFrame|. After all, the child list could be multiple siblings, and HasDisplayableChildren will only check the first. It will also assert if there are no children, and you don't want that. >+ if (PR_TRUE == makeAlternateFrame) { Just |if (makeAlternateFrame) {| is better
Comment on attachment 95890 [details] [diff] [review] Patch rev. 2 Other than what I mentioned in my previous comment, this seems fine. (I still don't understand why the old code ever worked, or what regressed it.)
> 1) One doesn't need .get() for comparisons with nsCOMPtrs anymore, so don't OK, but there are a hundred or so uses of .get() in nsCSSFrameConstructor.cpp alone. Many are straight-forward comparisons like: nsHTMLAtoms::applet == tag.get() but how about: IS_TABLE_CELL(parentFrameType.get()) should that be changed as well? and how about: IsTableRelated(nsIAtom* aParentType, PRBool aIncludeSpecial) IsTableRelated(parentFrameType.get(), PR_TRUE)) should I change the signature of IsTableRelated to make the comparisons in it use nsCOMPtr::operator== rather than pointer equality? etc. Also, what about the rest of the files in mozilla/layout/html/style/src and mozilla/* in general? Wouldn't it be better to handle this .get() cleanup operation as a separate bug and that someone intimate with nsCOMPtr fix it? > 2) The second argument to HasDisplayableChildren should be |aFrame|, No, aFrame is a "ObjectFrame(applet)" with no children. What we want to use is the frame(list) that comes out of the call to ConstructFrameByDisplayType. > After all, the child list could be multiple > siblings, and HasDisplayableChildren will only check the first. Good catch. I will fix this in the upcoming patch. I will also make it use nsIFrame::IsEmpty instead of the tests it has now. > It will also assert if there are no children, and you don't want that. I don't think so. I got an empty "Inline(applet)" for "<applet></applet>" > >+ if (PR_TRUE == makeAlternateFrame) { > Just |if (makeAlternateFrame) {| is better Fixed. (I saw this in some other files so I assumed this was the style you used, it's hard at times to know which style to use since there seems to be so many in use ;-) Is there a document that describes the "the one and only official style" to use). > I still don't understand why the old code ever worked, or what regressed it. Just speculation, but I think that the "ObjectFrame(applet)" aFrame parameter probably used to have frames created for it's embedded content at some point. Maybe someone decided that this was a waste of resources since it's going to be replaced anyway?
Attached patch Patch rev. 3 (obsolete) — — Splinter Review
Attachment #95890 - Attachment is obsolete: true
Attached file testcase #3 —
> > 1) One doesn't need .get() for comparisons with nsCOMPtrs anymore, so don't > > OK, but there are a hundred or so uses of .get() in > nsCSSFrameConstructor.cpp alone. Many are straight-forward comparisons like: > nsHTMLAtoms::applet == tag.get() Proper nsCOMPtr usage is something that everyone working on Mozilla should know. Generally you should fix things like this in code that you modify, but you don't need to clean up other code (although you could choose not to do the first if it would create a visible inconsistency). See http://www.mozilla.org/projects/xpcom/nsCOMPtr.html > but how about: > IS_TABLE_CELL(parentFrameType.get()) > > should that be changed as well? and how about: Yes. The macro just expands to operator==. > IsTableRelated(nsIAtom* aParentType, PRBool aIncludeSpecial) > IsTableRelated(parentFrameType.get(), PR_TRUE)) A .get() should never have been needed there. > should I change the signature of IsTableRelated to make the comparisons in it > use nsCOMPtr::operator== rather than pointer equality? No. nsCOMPtr should be avoided in function signatures. > Also, what about the rest of the files in mozilla/layout/html/style/src and > mozilla/* in general? Just the code you're touching. > Wouldn't it be better to handle this .get() cleanup operation as a separate > bug and that someone intimate with nsCOMPtr fix it? Are you volunteering? Do you know what it's like to make and land such a change? > > >+ if (PR_TRUE == makeAlternateFrame) { > > Just |if (makeAlternateFrame) {| is better > > Fixed. (I saw this in some other files so I assumed this was the style you > used, it's hard at times to know which style to use since there seems to be > so many in use ;-) Is there a document that describes the > "the one and only official style" to use). Perhaps. But you really will just learn it from code reviews.
mats: > Wouldn't it be better to handle this .get() cleanup operation as a separate > bug and that someone intimate with nsCOMPtr fix it? It's better to fix things incrementally, and not to propagate mistakes in newly added code. There should not be a wild mix of styles in any module that's well-owned and subject to good code review. If you see superstitious overuse of .get() on nsCOMPtrs, or *no use of nsCOMPtr at all* (manual ref-counting where it is not justified), or the silly (PR_TRUE == aCondition) style, you're seeing old code that was under-reviewed, or (in the case of the silly condition style) written way back when someone who is now long-gone was actually so confused that he thought such a style was superior (because it might help novice programmers [who should not be around a C++ compiler anyway] avoid mistyping == as =, thereby mistakenly assigning PR_TRUE to aCondition -- except there's never a good reason to write boolean tests using ==, and anyway gcc would warn you about your assignment nested without extra parenthesization in a condition). /be
Attached patch Patch rev. 4 (obsolete) — — Splinter Review
OK, I've removed all uses of nsCOMPtr::get(), except for a printf where the pointer is printed. Otherwise this patch is the same as rev. 3. There is still one nsCOMPtr usage that perhaps should be cleaned up: nsCOMPtr<nsIAtom> tag; aChild->GetTag(*getter_AddRefs(tag)); PRBool listitem = tag && tag == nsXULAtoms::listitem; if (listitem) { I don't see much point in the "null test" (assuming nsXULAtoms::listitem never is NULL), how about changing it to: nsCOMPtr<nsIAtom> tag; aChild->GetTag(*getter_AddRefs(tag)); if (nsXULAtoms::listitem == tag) {
Attachment #96334 - Attachment is obsolete: true
The change suggested in comment 25 makes perfect sense.
Attached patch Patch rev. 5 (obsolete) — — Splinter Review
There were three nsCOMPtr null tests in this file - I fixed two instances of the code mentioned in comment 25 plus this one: - if (tag && (tag == nsXULAtoms::listitem || tag == nsXULAtoms::listcell)) + if (tag == nsXULAtoms::listitem || tag == nsXULAtoms::listcell) Otherwise this patch is the same as rev. 4. ==== BTW, in new code, which do you prefer: if (tag == nsXULAtoms::listitem) or if (nsXULAtoms::listitem == tag) (Currently, there is about fifty-fifty of each in nsCSSFrameConstructor.cpp)
Attachment #98288 - Attachment is obsolete: true
Comment on attachment 98290 [details] [diff] [review] Patch rev. 5 >@@ -7353,7 +7353,7 @@ > // do it now, when constructing frames. See bug 115291. > { > const nsStyleVisibility *vis; >- GetStyleData(styleContext.get(), &vis); >+ GetStyleData(styleContext, &vis); > } > > nsIFrame* lastChild = aFrameItems.lastChild; Undo this one, since a few compilers have problems with function templates and nsCOMPtrs. >@@ -10960,48 +10958,32 @@ > > > static PRBool >-HasDisplayableChildren(nsIPresContext* aPresContext, nsIFrame* aContainerFrame) >+HasDisplayableFrame(nsIPresContext* aPresContext, nsIFrame* aFrame) > { >- // Returns 'true' if there are frames within aContainerFrame that >- // could be displayed in the frame list. >- NS_PRECONDITION(aContainerFrame != nsnull, "null ptr"); >- if (! aContainerFrame) >+ NS_PRECONDITION(aFrame != nsnull, "null ptr"); >+ if (!aFrame) > return PR_FALSE; > >- nsIFrame* frame; >- aContainerFrame->FirstChild(aPresContext, nsnull, &frame); >+ nsCompatibility mode; >+ aPresContext->GetCompatibilityMode(&mode); > >- while (frame) { >- // If it's not a text frame, then assume that it's displayable. >- nsCOMPtr<nsIAtom> frameType; >- frame->GetFrameType(getter_AddRefs(frameType)); >- if (frameType.get() != nsLayoutAtoms::textFrame) >- return PR_TRUE; >+ const nsStyleText* styleText; >+ GetStyleData(aFrame, &styleText); I slightly prefer "::GetStyleData" to emphasize that it's a global function template. > >- // Get the text content... >- nsCOMPtr<nsIContent> content; >- frame->GetContent(getter_AddRefs(content)); >- >- nsCOMPtr<nsITextContent> text = do_QueryInterface(content); >- NS_ASSERTION(text != nsnull, "oops, not an nsITextContent"); >- if (! text) >+ PRBool isPre = >+ ((styleText != nsnull) && >+ ((NS_STYLE_WHITESPACE_PRE == styleText->mWhiteSpace) || >+ (NS_STYLE_WHITESPACE_MOZ_PRE_WRAP == styleText->mWhiteSpace))); The |isPre| you're passing in should technically be associated with the containing *block*, not with the frame itself. Probably just using the object frame is close enough. >+ >+ while (aFrame) { >+ PRBool empty; >+ aFrame->IsEmpty(mode, isPre, &empty); >+ if (!empty) { > return PR_TRUE; >- >- // Is it only whitespace? >- PRBool onlyWhitespace; >- text->IsOnlyWhitespace(&onlyWhitespace); >- >- // If not, then we have displayable content here. >- if (! onlyWhitespace) >- return PR_TRUE; >- >- // Otherwise, on to the next frame... >- frame->GetNextSibling(&frame); >+ } >+ aFrame->GetNextSibling(&aFrame); > } > >- // If we get here, then we've iterated through all the child frames, >- // and every one is a text frame containing whitespace. (Or, there >- // weren't any frames at all!) There is nothing to diplay. > return PR_FALSE; > } >- if (NS_SUCCEEDED(rv)) { >+ // See whether it is an APPLET with no displayable children >+ // XXX need to check nameSpaceID in these spots >+ if (nsHTMLAtoms::applet == tag && !HasDisplayableFrame(aPresContext, newFrame)) { I think you should probably put in: 1. a call to DeletingFrameSubtree 2. A call to frameManager->SetPrimaryFrameFor(content, nsnull) here in case something fails later on. (The former might even be needed in some normal cases.) This makes me realize that using IsEmpty might not be quite right, since it doesn't consider placeholder frames (consider what happens if the only child of the applet is a floating element or absolutely positioned element). I'm not quite sure what to do about this -- and I'm a little hesitant to add a fourth parameter to IsEmpty. >+ newFrame->Destroy(aPresContext); >+ makeAlternateFrame = PR_TRUE; >+ } else if (NS_SUCCEEDED(rv)) {
Attached patch Patch rev. 6 (obsolete) — — Splinter Review
> Undo this one, since a few compilers have problems with function templates > and nsCOMPtrs. Fixed > I slightly prefer "::GetStyleData" to emphasize that it's a global function > template. Fixed > The |isPre| you're passing in should technically be associated with the > containing *block*, not with the frame itself. Probably just using the object > frame is close enough. Fixed, now taking |isPre| from the ObjectFrame. > I think you should probably put in: > 1. a call to DeletingFrameSubtree > 2. A call to frameManager->SetPrimaryFrameFor(content, nsnull) Fixed (a note on DeletingFrameSubtree later) > This makes me realize that using IsEmpty might not be quite right, since it > doesn't consider placeholder frames (consider what happens if the only child > of the applet is a floating element or absolutely positioned element). > I'm not quite sure what to do about this -- and I'm a little hesitant to add > a fourth parameter to IsEmpty. Yes, to do this correctly means changes to IsEmpty (or adding a new nsIFrame method). However, I changed HasDisplayableFrame() so it checks for floaters and positioned elements when the APPLET is the parent. I'm guessing this would be the common case if it ever occurs in any real pages. Let me know if you think this last change to HasDisplayableFrame() is unnecessary and I'll revert it to the version in Patch rev. 5.
Attachment #98290 - Attachment is obsolete: true
Attached file testcase #4 —
More testcases - floaters, positioned elements, white-space:pre and stuff
Attached patch Patch rev. 6 (obsolete) — — Splinter Review
This is the real Patch rev. 6 (forgot to remove a couple of printf's)
Attachment #99224 - Attachment is obsolete: true
While testing the new patch (rev. 6), I think I've found an existing problem with DeletingFrameSubtree. In an edge case with positioned elements it triggers the following assertions: ###!!! ASSERTION: not in child list: 'frameList.ContainsFrame(aChildFrame)', file nsCSSFrameConstructor.cpp, line 1218 Break: at file nsCSSFrameConstructor.cpp, line 1218 ###!!! ASSERTION: didn't find frame to delete: 'result', file nsAbsoluteContainingBlock.cpp, line 134 This is from the DeletingFrameSubtree call I added before doing newFrame->Destroy(aPresContext);
If I add "position:relative" to the APPLET style then the assertions dissappear.
This bug is a duplicate of Bug 71473. Somewhat different behavior is reported in an old version there: the claim is that if <applet>'s content is inline, it is rendered as an alternate, but not if the content is block/replaced. My current Moz 1.2.1 on Windows displays the 'alt' tag, not the content, if Java is disabled. I posted over there that I think, looking at the spec, that this should be considered the correct behavior. However, if it's changed, I don't think that's a big deal.
Summary: Alternative <applet> content not displayed. No fallback available. → Alternate <applet> content not displayed. No fallback available.
Keywords: html4
Blocks: 71473
Attached patch Patch rev. 7 (obsolete) — — Splinter Review
This fixes bug 71473 as well. nsBlockFrame::IsEmpty() had changed since the last time and it cannot be used since the width/height attributes are almost always present for APPLET and thus it would never be considered "empty" if we used it. The reason for the assertions mentioned in comment 32 was that for embedded alternate content that is positioned *but empty* we have to add the frames to the proper out-of-flow list before we can remove them since DeletingFrameSubtree() explicitly test that the frame is on correct list.
Attachment #99226 - Attachment is obsolete: true
Attachment #136651 - Flags: review?(dbaron)
Summary: Alternate <applet> content not displayed. No fallback available. → [FIX] Alternate <applet> content not displayed. No fallback available.
Is this patch still current? If not, could you attach a new one. I'm not quite sure why I left this in my queue so long -- I think i was thinking that the HTML spec question I asked in comment 15 was unresolved. (Or is it still unresolved?)
Assignee: waterson → mats.palmgren
Note that I think what we should do here is just show the alternate content, if any, and the alt text if there is no alternate content. That could be implemented pretty easily with the :empty selector and the :-moz-broken pseudo-class I'm working on, if it were not for <param> elements; those probably shouldn't count as alternate content, right?
Depends on: moz-broken
Attachment #136651 - Attachment is obsolete: true
Attachment #136651 - Flags: review?(dbaron)
Assignee: mats.palmgren → nobody
QA Contact: chrispetersen → layout
Summary: [FIX] Alternate <applet> content not displayed. No fallback available. → Alternate <applet> content not displayed. No fallback available.
No longer blocks: 71473
Depends on: 309528
(In reply to comment #6) > If you look at the cvs source for > http://www.mozilla.org/quality/browser/front-end/testcases/oji/test3.html you > can see that the typo is nested quotes in the ALT tag, not the missing quotes > that it looks like if you try to view Page Source in Mozilla on that page. > > If you correct the error then you can see that this bug is that the ALT text is > displayed but the other text within the applet tag is not displayed. > What's the right way of bringing this to the attention of the person who > maintains the test case? I'll try adding his email address to the cc list on > this bug. While searching for a duplicate of bug 310126, I stumbled across this bug. I corrected the testcase (nested quotes) of that webpage.
*** Bug 310126 has been marked as a duplicate of this bug. ***
with the current firefox release (1.07), and the corrected test page, it still doesn't work for me. Also doesn't work in mozilla 1.7.11 that is, the "applet below" box is empty, and the box below that, showing what you should see, is not duplicated. BTW, nemesis Internet Explorer doesn't display the "alt" tag but does, correctly, display the html embedded in the applet body.
Depends on: 311674
Depends on: 309067
Attached patch Patch — — Splinter Review
Now that bug 309067 is fixed, this fixes the rmaining issues in the testcases on this bug...
Attachment #199753 - Flags: superreview?(dbaron)
Attachment #199753 - Flags: review?(cbiesinger)
Attachment #199753 - Flags: superreview?(dbaron) → superreview+
Comment on attachment 199753 [details] [diff] [review] Patch r=biesi. this selector does ignore whitespace, right?
Attachment #199753 - Flags: review?(cbiesinger) → review+
Correct. This matches if the only children are whitespace, comments, or tags with the given localname and the same namespace as the parent.
Assignee: nobody → bzbarsky
Fixed, as far as I can tell.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
> we should (...) just show the alternate content, if > any, and the alt text if there is no alternate content. Boris, what is supposed to be shown, rendered if the embedded content is empty (<span></span>) and not positioned like for Applet 2 in attachment 96335 [details]? Just asking. The alt attribute is not rendered in such case. Using Seamonkey 1.1a rv:1.9a1 build 2005102013 under XP Pro SP2 here.
It's hard to tell what _should_ be rendered in any given case.... None of this is exactly specified. ;) What we do is the following: 1) If the applet has fallback content (i.e. kids that are not whitespace, comments, or param) render that. 2) If the applet has no fallback content but has an alt attribute, render that.
*** Bug 327183 has been marked as a duplicate of this bug. ***
Camino 1.0.3 and Firfox 2.0 do not pass any tests that should show content between applet tags. The content between <applet>...</applet> is never rendered when Java is disabled. Because of this I think this bug should be re-opened.
Comment on attachment 199753 [details] [diff] [review] Patch It's true that testcase #2 (attachment 90614 [details]) doesn't show embedded content for the 1st or 3rd applets, with Java disabled, for Fx 2.0 and 1.5. Seamonkey 1.1a-0821 likewise. However, Seamonkey 1.5a-0925 works as expected. This fix apparently went into the trunk after the 1.8 branch and wasn't backported for 1.8.1. I'd guess it's fixed on Firefox trunk (3.0 development) as well. I'll try a request for 1.8.1.1, since it's simple maybe someone will accept it. Since it's a simple HTML patch, you could integrate into your local build or put it into userContent.css.
Attachment #199753 - Flags: approval1.8.1.1?
Comment on attachment 199753 [details] [diff] [review] Patch This fix depends on a lot of trunk architecture work that simply is not going on on branch. Please look at the dependency lists of bugs before nominating.
Attachment #199753 - Flags: approval1.8.1.1? → approval1.8.1.1-
Matthew, the bug is fixed on trunk for Gecko 1.9, as indicated by the target milestone. Firefox 2 is based on Gecko 1.8.1. So no, the bug should not be reopened.
Just updating this bugfile.. Today, WCAG 2.0 CR was released. We can read: Techniques for WCAG 2.0 H35: Providing text alternatives on applet elements http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H35.html "IE (6?) will display the body text of the applet element and not the alt attribute. Firefox (1.5?) and Opera will display the alt attribute but not the body text." but when trying this test http://www.mozilla.org/quality/browser/front-end/testcases/oji/test3.html with java support is disabled, Firefox 2.0.0.14 rv:1.8.1.14 build 20080404 renders both nested body text in the applet and alt attribute value.
> when trying this test > http://www.mozilla.org/quality/browser/front-end/testcases/oji/test3.html > with java support is disabled, Firefox 2.0.0.14 rv:1.8.1.14 build 20080404 > renders both nested body text in the applet and alt attribute value. Updated link: http://www-archive.mozilla.org/quality/browser/front-end/testcases/oji/test3.html with java support is disabled, Firefox 52.0.2 renders both nested body text in the applet and alt attribute value.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: