InformAction Forums

If just the code attribute is used, the url should be for the class (which can be specified without the .class extension) If the archive attribute is used then I guess it should a jar url "jar:<url to archive1.jar>!/Class1.class"

Currently, in either case, the url of the containing page is shown. Also the height of the placeholder for the above embeds (no size specified) is 100%, should probably be min height.

Looks like a bug in Gecko's content policy call. Investigating, thanks...

Worked around in latest development build.

Giorgio Maone wrote:Worked around in latest development build.

Fx 6.0b4, NS 2.1.2.6rc2

1. For just code: you are not including the .class extension. It can be omitted from the attribute, but since you're showing the actual resource url, it should have the extension.
2. For archive & code: you are ignoring the archive, just showing the code (without the extension), the helpful/correct thing would be to show the real url of the blocked resource. For

   Code: Select all

   <embed type="application/x-java-applet" archive="SwingSet2.jar" code="SwingSet2Applet"></embed>
   

   it would be:

   Code: Select all

   jar:file:///C:/Program Files/Java/jdk1.7.0/demo/plugin/jfc/SwingSet2/SwingSet2.jar!/SwingSet2Applet.class
   

3. placeholder oddities (example embed above): the visible placeholder rectangle is ("min width" x 100%), the clickable placeholder area is (100% x 100%), expected: both the rectangle and clickable area to be ("min width" x "min height")

al_9x wrote: For just code: you are not including the .class extension. It can be omitted from the attribute, but since you're showing the actual resource url, it should have the extension.

No it shouldn't. I'm mimicking what Gecko does for <APPLET> here, and I'm not going to introduce yet another inconsistency for cosmetic reasons. Furthermore, at the stage where content policies run we cannot guarantee this (or any other) to be "the actual resource URL" anyway, see below. So better having an uniform "key" string to identify the object to unlock which behaves consistently across <APPLET>, <OBJECT> and <EMBED> (from a security standpoint, the really important part is just scheme://host:port/) than something different and equally imprecise.

al_9x wrote: For archive & code: you are ignoring the archive,

Quite the opposite, I'm considering all the possibilities, which you seem to be ignoring

al_9x wrote: just showing the code (without the extension), the helpful/correct thing would be to show the real url of the blocked resource. For

Code: Select all

<embed type="application/x-java-applet" archive="SwingSet2.jar" code="SwingSet2Applet"></embed>

it would be:

Code: Select all

jar:file:///C:/Program Files/Java/jdk1.7.0/demo/plugin/jfc/SwingSet2/SwingSet2.jar!/SwingSet2Applet.class

Generally wrong. There's no guarantee at all that SwingSet2Applet.class will be loaded from SwingSet.jar.
The class specified in the code attribute can be loaded from anywhere in the applet classpath, which include the system classpath, the codebase URL (resolved against the document URL if relative, and defaulting to the document URL if absent) and any jar listed in the archive attribute. Yes, the jars can be many and even from different hosts, comma-separated in <APPLET> and <EMBED>, space-separated in <OBJECT> (just to add more inconsistencies).

Therefore, given the following code: there are at least 4 different locations where Main.class may be loaded from.
I choose to add "archive awareness" on top of Gecko (which lacks it completely), by checking and notifying the URLs of just one jar for each scheme://host:port different from the codebase, and use the same URL built by Gecko in the <APPLET> case ("$codebase/$class", which may or may not be accurate but serves its "key" purpose) as the class URL for <EMBED>, which otherwise would show the raw codebase with no further specification. Notice that JAR enumeration has a bug in rc2 which prevents more than one external archive URL (absolute, from a different origin than codebase) to be considered. This is fixed in rc3.

al_9x wrote:placeholder oddities (example embed above): the visible placeholder rectangle is ("min width" x 100%), the clickable placeholder area is (100% x 100%), expected: both the rectangle and clickable area to be ("min width" x "min height")

As I said in another thread, I'm not going to touch code that is already heavily changed in the NSA development line to fix cosmetic bugs. Too risky and not worth the effort.

Giorgio Maone wrote:

al_9x wrote: For just code: you are not including the .class extension. It can be omitted from the attribute, but since you're showing the actual resource url, it should have the extension.

No it shouldn't. I'm mimicking what Gecko does for <APPLET> here

If the idea is for the url to be a key, then it makes sense to canonicalize the classname, since class1 and class1.class are equivalent (are they not?) If they are, it should all be Class1 or Class1.class but not mixed, I think including the extension is better, since the actual url will have it.
For the above page, the blocked objects menu shows two keys and allowing Clock activates the first two applets but not the third.

I'm not going to canonicalize class URLs, because if I did I should do the same for <APPLET> elements, adding yet another unneeded complexity.