Closed
Bug 71473
Opened 24 years ago
Closed 19 years ago
APPLET tag contents not replaced when it can't render for block element
Categories
(Core :: Layout, defect, P2)
Core
Layout
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: wheelert, Assigned: peterl-bugs)
References
Details
(Keywords: testcase, Whiteboard: [PL2:NA])
Attachments
(1 file)
1.10 KB,
text/html
|
Details |
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•24 years ago
|
||
sending to parser. For your information, Java-implemented plugins is for pluglets, that is, plugins that have been themselves created using the java language
Assignee: idk → harishd
Component: Java-Implemented Plugins → Parser
QA Contact: geetha.vaidyanaathan → bsharma
Comment 2•23 years ago
|
||
Is this still a problem in recent builds?
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•23 years ago
|
||
Marking NEW.
Moving to more realistic target - m0.9.4!
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Crash and described behavior occurs in Win98 - OS: All.
OS: Linux → All
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.
Assignee: harishd → karnaze
Status: ASSIGNED → NEW
Component: Parser → Layout
QA Contact: bsharma → petersen
Comment 9•23 years ago
|
||
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 12•23 years ago
|
||
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 13•23 years ago
|
||
Sounds like a problem in nsCSSFrameConstructor::CantRenderReplaceElement()...
Assignee: av → peterl
Keywords: qawanted
Hardware: PC → All
Summary: Text internal to <Applet> tags is ignored if placed between <pre> tags → APPLET tag contents not replaced when it can't render for block element
Target Milestone: mozilla1.0.1 → mozilla0.9.9
Comment 14•23 years ago
|
||
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.)
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 15•23 years ago
|
||
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 adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Comment 16•22 years ago
|
||
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.
Updated•22 years ago
|
Severity: minor → normal
Comment 17•22 years ago
|
||
setting to PL2:NA
Whiteboard: [PL2:NA]
Target Milestone: mozilla1.2alpha → mozilla1.0.2
Comment 18•22 years ago
|
||
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•22 years ago
|
||
Can't you rename Java plugin so that viewer don't find it?
Updated•22 years ago
|
Target Milestone: mozilla1.0.2 → Future
Comment 20•22 years ago
|
||
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.
Severity: normal → critical
Comment 21•22 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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.
Severity: critical → normal
Keywords: crash
Comment 25•21 years ago
|
||
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•21 years ago
|
||
What should happen when both alt="" and content inside <applet> are present? Which "wins"?
Considering that APPLET is deprecated and the HTML spec is hazy, it's probably best to do whatever IE/Windows does...
Comment 28•21 years ago
|
||
Agreed. What does it do?
Comment 29•21 years ago
|
||
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...
Depends on: 114641
Comment 30•19 years ago
|
||
Fixed by bug 11011 -> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 32•19 years ago
|
||
Please retest in tomorrow's builds?
Comment 33•19 years ago
|
||
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•19 years ago
|
||
Yeah. Bug 1156 rebroke this... This needs to be looked at again once bug 309528 is fixed.
Comment 35•19 years ago
|
||
Re-Fixed by checkin for bug 311674.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•