902375 - Firefox 23: The Load of a local java applet (*jar) fails silently

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[trackfirefox]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130730113002

Steps to reproduce:

A local web application intended to be an off-line DVD, uses a local java applet.
Up to version 22 it worked fine.

The html is:
<applet width="960" height="425" archive="jclic.jar" codebase="../jclic/" code="JClicApplet">
<param value="application/x-java-applet;version=1.4" name="type">
<param value="false" name="scriptable">
<param value="cap1-03J.jclic.zip" name="activityPack">
</applet>

Trying to set codebase to a full path: "/...../jclic"
and a full url: "file:///...../jclic" 

both still fail.

The error happens both in Mac OS and Windows with Version 23


Actual results:

The applet is not loaded.
No error is shown.
Java v is not invoked.


Expected results:

The applet loaded.

Comment 1

[Scoobidiver (away)]

We need a testcase as an attachment and eventually a regression range using mozregression (see https://github.com/mozilla/mozregression).

Comment 2

[trackfirefox]

Attachment: testcase. unzip and open ./html/index.html

A Test case for the problem.
Unzip and open ./html/index.html.
The applet being loaded is in ./jclic/jclic.jar

Comment 3

[trackfirefox]

Hi!

Thanks Scoobidiver!

About mozregression, I'm affraid I'm not being able to correctly install (and use).
I'm not familiar with Mozilla development workflows.

What I can tell is:
It works correctly with release 22.0, Mac OS X and Windows
It fails with release 23.0 (today August 7, 2013), both Mac OS X and Windows.

Many thanks in advance.
Dino

Comment 4

[Scoobidiver (away)]

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b48e06621dc9&tochange=dcbbfcdf7bb4
It's likely a regression from bug 888834 or bug 406541 .

Comment 5

[Benjamin Smedberg]

I believe that this is by design. Our same-origin policy for sites loaded from file: is that they may only access files in their directory and subdirectories. The codebase="../jclic/" indicates that this is trying to load Java from a parent directory. That is specifically what we were fixing.

See https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs for background. If you flip the security.fileuri.strict_origin_policy pref to `false`, does that cause your Java to load? If so I expect that this is WONTFIX, but I'll let johns double-check me here.

Comment 6

[trackfirefox]

Attachment: test case 2. java in a subdirectory

Comment 7

[trackfirefox]

Hi Benjamin!

Thanks for your work!

First, I confirm that with security.fileuri.strict_origin_policy pref to `false`
it works.

We don't like the final user has to change the settings, so
we can rearrange to find the java in a subdirectory.
But we have prepared a second test case with this approach
(java in a subdirectory and security.fileuri.strict_origin_policy = true).
No success:
It does not load the java.

I have attached this second test case (case2.zip).

Please confirm us if you reproduce the same behaviour.

Many thanks again!

Dino.

Comment 8

[Scoobidiver (away)]

The regression range for the second testcase is still the same.

Comment 9

[bhavana bajaj [:bajaj]]

needinfo on John to help with comment #5 and understand if this is a valid bug ?

Comment 10

[John Schoenick [:johns]]

The case where codebases outside of the current directory are blocked is intentional -- however, the case where subdirectories do not work properly is not :(

Comment 11

[John Schoenick [:johns]]

Attachment: Actually use the optional parameter added explicitly for this purpose

Sigh. Fail. Most of the code in 406541 was to split out NS_RelaxStrictFileOrigin to allow adding the aAllowDirectoryTarget parameter. If only the added security check actually called it...

I added this to the tests for bug 406541, which haven't landed yet.

Comment 12

[John Schoenick [:johns]]

Attachment: Strict file origin policy - handle case where the target is the parent directory of the source

Bonus edge case found while looking at this - the strict file origin logic might fail if the target of an operation is the parent directory of the given file, and aAllowDirectoryTarget = true. (with allowDirectoryTarget a file should be able to target its own directory)

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 787154 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source

Can you assert that if NS_SUCCEEDED(rv) && allowed for the Equals() call (basically an else for the if you have there) then aAllowDirectoryTarget is true?

r=me with that

Comment 15

[John Schoenick [:johns]]

Attachment: Strict file origin policy - handle case where the target is the parent directory of the source. r=bz

Comment 16

[John Schoenick [:johns]]

Comment on attachment 793159 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz

addressed review comments

Comment 17

[John Schoenick [:johns]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c4007e82f13b
https://hg.mozilla.org/integration/mozilla-inbound/rev/8258b8c636a9

Comment 18

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/8258b8c636a9
https://hg.mozilla.org/mozilla-central/rev/c4007e82f13b

Comment 19

[Ivo Anjo]

I don't know what the procedure for backports is on mozilla, but could this be backported to at least FF 24, since it is going to be an ESR release?

Comment 20

[John Schoenick [:johns]]

Comment on attachment 787153 [details] [diff] [review]
Actually use the optional parameter added explicitly for this purpose

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
406541

User impact if declined:
Local (file://) pages that use Java don't work properly in some cases

Testing completed (on m-c, etc.):
On m-c

Risk to taking this patch (and alternatives if risky):
Very low, these changes only affect java applets on file URIs.

String or IDL/UUID changes made by this patch:
None

Comment 21

[John Schoenick [:johns]]

Comment on attachment 793159 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz

see comment 20

Comment 22

[John Schoenick [:johns]]

Tests for this will land with the 406541 tests

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f6a238e848d3
https://hg.mozilla.org/releases/mozilla-aurora/rev/1554a8d1eb6e

https://hg.mozilla.org/releases/mozilla-beta/rev/19d4d4a86051
https://hg.mozilla.org/releases/mozilla-beta/rev/243498415456

Comment 24

[trackfirefox]

Hi All!

Just to confirm...

With Nightly 26.0a1 (2013-08-23), my testcase works correctly.

I will check with aurora and beta.

Thanks!!

Comment 25

[Ioana (away)]

Verified as fixed on Firefox 24 beta 6 (20130826142034) - Windows 7 64bit, Ubuntu 13.04 32bit and Mac OSX 10.7.5.

The applet in the first testcase doesn't load - as specified by design.
The applet in the second testcase loads fine.

Comment 26

[Ioana (away)]

Also verified on Firefox 25:
Mac OS X 10.8.4 - 20130912004004
Ubuntu 13.04 - 20130911004006
Windows 7 - 20130912004004

Comment 27

[Bogdan Maris, Desktop Test Engineering]

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0

Verified as fixed on latest Aurora 26.0a2 (buildID: 20131010004002).