309528 - fix fallback for <embed>/<applet>

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

Currently, <embed> does not falls back to anything at all, now that bug 1156
landed. <applet> falls back to its contents.

that's probably not correct. as for <applet>, the examples in
http://www.w3.org/TR/html4/struct/objects.html#h-13.4 seem to contradict the
part that mentions the "alt" attribute...

Comment 1

[Boris Zbarsky [:bzbarsky]]

For applet, the HTML spec says:

  alt (alternate text)

and

  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.

So both are alternate content, somehow.  What I implemented in 11011 was using
the alt text if there are no kids in the applet.  But see discussion in bug
309067 for where I think we should head with this.

Comment 2

[Mike Cowperthwaite]

(In reply to comment #0)
> <applet> falls back to its contents.

Not any more, per reopened bug 71473.

I'm a little confused: Before the fallback was completely (re?)broken (from the 
bug 1156 patch), how was the <applet> fallback broken (post-11011) such that you 
included it in this bug?  Does this bug now supercede bug 114641?  Is this a 
meta bug?


(In reply to comment #1)
> For applet ... [w]hat I implemented in 11011 was using the alt text if
> there are no kids in the applet.  But see discussion in bug 309067 for
> where I think we should head with this.

I only vaguely understand that bug's discussion, but it appears that approach 
would allow a pair of CSS rules for an applet's alt rendering, one of which 
selects on the 'alt' attribute (if available) and the other of which selects on 
the non-empty, non-<param> content -- and the order/specificity of the rules 
determines which gets shown.  Is that more or less what you're thinking of?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Not any more, per reopened bug 71473.

"Not in all cases", rather.

> how was the <applet> fallback broken

This bugs was filed after 1156 was fixed.

> Does this bug now supercede bug 114641?

It blocks it.  That is, once this bug is fixed we should see what, if anything,
remains to be done for 114641.

> would allow a pair of CSS rules for an applet's alt rendering

Well, only one rule.  That is, if an applet has no non-param kids, show its alt
attribute.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

yes, this bug is filed specifically to fix the regression that bug 1156 caused.

Comment 5

[Eli Friedman]

As near as I can tell, embed elements can't contain anything, and bug 114641
should have fixed applets.  What's the issue here?

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

can't they can have an alt attribute?


hmm, per
http://devedge-temp.mozilla.org/library/manuals/2002/plugin/1.0/intro.html they
can't... so, this is a non-issue?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm... Yeah, we sorta have <embed> fall back to contents, which is what we used
to do.  And that should work, I think.

OK.  So if we fall back properly for applet, this is probably fixed.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

marking so, though isn't what we used to do to always show the null plugin?

Comment 9

[Boris Zbarsky [:bzbarsky]]

I think we still do for applet, actually.  Bug 114641 is only fixed if Java is
disabled, I believe (which is the state the bug was filed on).  If Java is
enabled, we show the null plugin for applets.

Should we reopen this?

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

well, ok, but what is the desired behaviour here? There's the two contradicting
issues of a) let the user know about missing plugins and b) respect the author's
fallback content

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

if things are working like they always have, I think I don't want to own this bug :)

Comment 12

[Boris Zbarsky [:bzbarsky]]

We should be doing the same thing we do for <object> -- showing the yellow bar
but not the puzzle piece placeholder.  At least in Firefox.  In seamonkey we
should stop using the default plugin and use a setup like what Firefox does.  ;)

Comment 13

[Anne (:annevk)]

For <embed> there's <noembed>. <embed> itself is an empty element in most browsers like <br> etc.

Comment 14

[John Schoenick [:johns]]

<embed> cannot possess alternate content as it is treated as empty element. Fallback should work with <applet> properly now, but we don't currently honor applet's "alt" param

Comment 15

[Benjamin Smedberg]

And we're not going to.