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

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Layout
RESOLVED FIXED
16 years ago
2 months ago

People

(Reporter: Paul B. Joiner, Assigned: bz)

Tracking

({html4, testcase})

Trunk
mozilla1.9alpha1
html4, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [HTML4-13.4], URL)

Attachments

(6 attachments, 9 obsolete attachments)

732 bytes, text/html
Details
1.09 KB, text/html
Details
1019 bytes, text/html
Details
5.07 KB, text/html
Details
380 bytes, text/html
Details
1.25 KB, patch
Biesinger
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
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

Updated

16 years ago
Target Milestone: --- → Future

Comment 2

15 years ago
Right! Even ...

http://www.mozilla.org/quality/browser/front-end/testcases/oji/test3.html

...fails!

Oliver Kitzing

Comment 3

15 years ago
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>

Comment 4

15 years ago
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

Comment 5

15 years ago
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

Comment 6

15 years ago
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.

Comment 7

15 years ago
Created attachment 89814 [details]
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

Comment 8

15 years ago
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]

Comment 9

15 years ago
Created attachment 90613 [details]
tescase #2

Some more testcases. BTW, what's supposed to happen when you have BOTH an ALT
attribute AND embedded content?
Created attachment 90614 [details]
testcase #2

Some more testcases. BTW, what's supposed to happen when you have BOTH an ALT
attribute AND embedded content?

Updated

15 years ago
Attachment #90613 - Attachment is obsolete: true

Comment 11

15 years ago
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 → ---
Created attachment 95825 [details] [diff] [review]
Patch rev. 1

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...
Created attachment 95890 [details] [diff] [review]
Patch rev. 2

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?
Created attachment 96334 [details] [diff] [review]
Patch rev. 3
Attachment #95890 - Attachment is obsolete: true
Created attachment 96335 [details]
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
Created attachment 98288 [details] [diff] [review]
Patch rev. 4

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.
Created attachment 98290 [details] [diff] [review]
Patch rev. 5

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)) {
Created attachment 99224 [details] [diff] [review]
Patch rev. 6

> 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
Created attachment 99225 [details]
testcase #4

More testcases - floaters, positioned elements, white-space:pre and stuff
Created attachment 99226 [details] [diff] [review]
Patch rev. 6

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);
Created attachment 99229 [details]
testcase #5, triggers the assertions in comment 32

If I add "position:relative" to the APPLET style then the assertions
dissappear.

Comment 34

15 years ago
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.

Updated

14 years ago
Summary: Alternative <applet> content not displayed. No fallback available. → Alternate <applet> content not displayed. No fallback available.

Updated

14 years ago
Keywords: html4

Updated

14 years ago
Blocks: 71473
Created attachment 136651 [details] [diff] [review]
Patch rev. 7

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.

Updated

14 years ago
Attachment #99226 - Attachment is obsolete: true

Updated

14 years ago
Attachment #136651 - Flags: review?(dbaron)

Updated

14 years ago
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: 11011
Depends on: 1156

Updated

12 years ago
Attachment #136651 - Attachment is obsolete: true
Attachment #136651 - Flags: review?(dbaron)

Updated

12 years ago
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.

Updated

12 years ago
No longer blocks: 71473
Depends on: 309528

Comment 38

12 years ago
(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.

Comment 39

12 years ago
*** Bug 310126 has been marked as a duplicate of this bug. ***

Comment 40

12 years ago
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
Created attachment 199753 [details] [diff] [review]
Patch

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
Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha

Comment 45

12 years ago
> 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. ***

Comment 48

11 years ago
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 49

11 years ago
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.

Comment 52

9 years ago
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.

Comment 53

2 months ago
> 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.