71473 - APPLET tag contents not replaced when it can't render for block element

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Travis Wheeler]

In "applet" tag implementation, it is common to place some text between the
opening and closing applet tags. This text is ignored if Java is enabled, and
printed if java is disabled. If the text to be printed is placed between <pre>
and </pre> tags, Mozilla (and Netscape 6, for that matter) does not render the
text at all. If the pre tags are removed, the text is rendered.

Sample tag sequence:

<applet ...other attribs...>
    <pre>
   This should show up if the user has disabled Java (notice, it's between "pre"
tags), but it doesn't in Mozilla
    </pre>
</applet>


Workaround: placing another tag set (e.g. <b></b>) prior to the <pre> tag causes
Mozilla to render the preformatted text.

<applet ...other attribs...>
  <pre>
   Because of the "bold" tags above (workaround), this shows up if the user has
disabled Java (notice, it's between "pre" tags)
  </pre>
</applet>

Comment 1

[Fabian Guisset]

sending to parser. For your information, Java-implemented plugins is for
pluglets, that is, plugins that have been themselves created using the java language

Comment 2

[Boris Zbarsky [:bzbarsky]]

Is this still a problem in recent builds?

Comment 3

[Skewer]

Attachment: APPLET testcase - normal, XMP, and PRE (may crash)

Comment 4

[Skewer]

When I highlight text in the testcase, Mozilla crashes in GKCONTENT.DLL (that
may be another bug entirely). In build 2001060409 Win98, I'm seeing the
described behavior for both XMP and PRE tags within the APPLET tag. Other tags,
such as TT, behave as expected. So yes, this is still happening on recent
builds, and across different platforms as well.

Comment 5

[Keyser Sose]

Marking NEW.

Comment 6

[harishd]

Moving to more realistic target - m0.9.4!

Comment 7

[Skewer]

Crash and described behavior occurs in Win98 - OS: All.

Comment 8

[harishd]

This works:

<applet>
 <inline element>
   Text
 </inline element>
</applet>

This doesn't work:

<applet>
 <block element>
   Text
 </block element>
</applet>


NOTE: APPLET is depricated in HTML 4.x and is replaced with OBJECT. 

In any case this is a layout problem.

Comment 9

[Asko Tontti]

Also tables are not shown inside applet tags (simplified case):

  <APPLET code="MenuTree.class" codebase="/" width=160 height=680>
  <table>
  <tr><td><b>DocuPrint</b></td></tr>
  <tr><td><b>Paper</b></td></tr>
  <tr><td>Trays</td></tr>
  </table>
  </APPLET>

Because this bug Xerox's DocuPrint N24/N32/N40 printers cannot be configured
with Mozilla browser. (Java applet in the configuration page won't work with
the current JREs and when you disable Java you won't see the table due this
bug.)

Comment 10

[karnaze (gone)]

Reassigning to av.

Comment 11

[av (gone)]

Not going to make 0.9.4.

Comment 12

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 13

[Peter Lubczynski]

Sounds like a problem in nsCSSFrameConstructor::CantRenderReplaceElement()...

Comment 14

[noisefactor]

This is similar to a bug I submitted which was basically ignored
because "APPLET is deprecated in HTML 4.xx in favor of OBJECT."

I can't understand why the old layout of alternative text can't be
maintained until the status of the APPLET tag changes from deprecated to
extinct????  (Personally, I prefer APPLET to OBJECT because I don't have
to deal with ugly OBJ ID's, but I will not press the issue.)

Comment 15

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 16

[Skewer]

The testcase no longer crashes for me in Windows XP. The bug was reported on
Win98, so I won't remove the crash keyword unless a Win98 user can verify that
highlighting text does not cause a crash.

Comment 17

[rubydoo123]

setting to PL2:NA

Comment 18

[Peter Lubczynski]

I need a frame dump on the testcase with Java disabled to see what's going on. I
see text frames being created in the debugger but I don't know what's happening
with them without a frame dump from viewer. However, I don't know how to disable
Java in viewer. :(

Comment 19

[Asko Tontti]

Can't you rename Java plugin so that viewer don't find it?

Comment 20

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 21

[Mike Cowperthwaite]

Unlike <object>, <applet> is not defined as having its contents be an alternate
rendering.  It does have an 'alt' attribute for display if the applet cannot
be rendered.

The Moz1.2.1 I have installed on my Windows system doesn't display even
inline content if, for instance, Java is disabled.  It does support the 'alt'
tag in that instance.  This seems correct behavior to me.

For one browser's comparison, Opera v. 6 displays the content as the alternate
rendering; v.7 displays the 'alt' tag.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Well... we have this HasDisplayableChildren() thing in nsCSSFrameConstructor. 
But that does absolutely nothing useful, since child frames of <applet> are
never constructed (see ConstructHTMLFrame).

My suggestion would be to rip out the HasDisplayableChildren thing and just use
the alt attr (which is what we end up doing anyway).

Alternately, we need to change HasDisplayableChildren to look at the content
model, not the frame model.

Thoughts?

Comment 23

[Mats Palmgren (inactive)]

This bug is a subset of the problems I tried to fix in bug 114641.
I think the patch in that bug has bit-rotted since, but I could try and
resurrect it if anyone is interested.

Comment 24

[Mike Cowperthwaite]

I don't agree there *is* a bug here at all; with Java disabled, Mozilla renders 
<applet>s as I expect it to.  I realize some people want to re-implement 
Netscape4/IE behavior, which is certainly arguable.

Whether or not that behavior gets implemented, the crash situation described in 
comment 4 is no longer an issue.  Since Mozilla currently does not display *any* 
content of <APPLET>, the content string cannot be selected.  I'm removing the 
'crash' keyword and reducing severity; if someone can reproduce the crash 
condition with a current build, we can certainly put them back.

Comment 25

[Sylvain A.]

Mike, the ALT attribute is not an issue.

Mozilla, Netscape and Firebird actually display properly the ALT attribute from
the <APPLET..> tag (in case of Java disabled).

But they failed to render the content beetween the <APPLET>....</APPLET> tags,
if Java is disabled.

This is discribed here :
http://www.w3.org/TR/html401/struct/objects.html#h-13.4

« The content of the APPLET acts as alternate information for user agents that
don't support this element or are currently configured not to support applets.
User agents must ignore the content otherwise. »


Why is it a problem ?
---------------------

1) You cannot render some HTML inside the ALT attribute (I would like to put an
URL to redirect users).

2) I "upgraded" my <APPLET> tags to the <OBJECT> one.
It worked ! The content of <OBJECT>....</OBJECT> was properly rendered in case
Java is disabled.
But Internet Explorer failed to load applet because my web page loads TWO .jar
archives (or TWO .cab as well). This is another bug from Internet Explorer.

After hours of Google searching and workaround tries, I was forced to
"downgrade" my <OBJECT> tag to the <APPLET> one.


Conclusion
----------

You cannot have, at the same time, a web page which the applet is loaded by 2
(or more zipped archives) AND an alternate content rendered in HTML, in case
Java is not present.

Comment 26

[Boris Zbarsky [:bzbarsky]]

What should happen when both alt="" and content inside <applet> are present? 
Which "wins"?

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Considering that APPLET is deprecated and the HTML spec is hazy, it's probably
best to do whatever IE/Windows does...

Comment 28

[Boris Zbarsky [:bzbarsky]]

Agreed.  What does it do?

Comment 29

[Mats Palmgren (inactive)]

Boris, this bug will be fixed by bug 114641.  I eventually did find out what
the problem was with the last patch there, I just haven't gotten around to
submitting it...

Comment 30

[Mats Palmgren (inactive)]

Fixed by bug 11011

-> FIXED

Comment 31

[Boris Zbarsky [:bzbarsky]]

It's worth retesting again when we fix bug 1156...

Comment 32

[Boris Zbarsky [:bzbarsky]]

Please retest in tomorrow's builds?

Comment 33

[Mike Cowperthwaite]

With Fx1.6a1-1003, Java disabled, I don't see the correct behavior for any of 
the three applets in the test case -- the contained text isn't displayed.  Note 
that the testcases at bug 114641 (which have 'alt' attributes on the applets) 
aren't working either.

Comment 34

[Boris Zbarsky [:bzbarsky]]

Yeah.  Bug 1156 rebroke this...  This needs to be looked at again once bug
309528 is fixed.

Comment 35

[Boris Zbarsky [:bzbarsky]]

Re-Fixed by checkin for bug 311674.